search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.22k stars 718 forks source link

Firewall Shaper causes IPv6 address loss on WAN #7342

Open meyergru opened 5 months ago

meyergru commented 5 months ago

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug

If one uses the traffic shaper like described here: https://maltechx.de/en/2021/03/opnsense-setup-traffic-shaping-and-reduce-bufferbloat/ and elsewhere, the IPv6 address of the WAN interfaces gets lost when an outbound congestion occurs. IPv4 works fine.

This is especially problematic with dynamic IPv6 prefixes and CG-NAT / DS-Lite. The german ISP Deutsche Glasfaser is a prominent example of this.

To Reproduce

There are multiple reports of this behaviour on the OpnSense forums:

https://forum.opnsense.org/index.php?topic=27247.0 https://forum.opnsense.org/index.php?topic=39624.0 https://forum.opnsense.org/index.php?topic=32912

Expected behavior

The IPv6 connectivity should not be disturbed by traffic shaping.

Describe alternatives you considered

In two of the threads, a potential workaround is to use specific IPv6 ranges for the source of the rules, which is impossible with dynamic IPv6 prefixes, though.

Relevant log files

See links...

Environment

OPNsense 22.x to 24.1.4

Wireheadbe commented 4 months ago

I have shaping working on both my WAN links - and both have IPv6 enabled. The only difference between my rules and the rules in the guide, is that I do not have a mask set on the queue, and only use direction on the rule.

Could you test what that does?

prolix-oc commented 2 months ago

Since @Wireheadbe's question was posed and did not receive an answer, I will follow up since this issue seemingly gets no activity (for a rather large issue if I can say so):

Just so you can rule out any hardware issues...

Hardware setup:

You simply turn on any ip protocol based shaping rules. Leaving it to ipv4 works and obtains a DHCPv6 address from the ISP. Leaving it to tcp and udp in paired rulings for both directions works [UPDATE: it does not. ICMP is technically TCP traffic too, and I forgot that fact when I attempted to re-obtain a lease]. Any time ip is left on, it includes the shaping of ICMPv6 and ICMP packets, which fragment the response from the gateway.

My running theory is that the packets are getting fragmented by the shaper and not reassembled correctly. This much I can confirm by seeing the solicit packets missing bytelengths in the system logs, then restarting the solicit process to get a valid packet.

The most obvious answer to this would simply exclude ALL ICMP traffic from the shaper when using the ip protocol. We all know not to disable ICMP at this point, right? If this is too much of an overreach for the devs (for some reason I can't begin to imagine), just adding an advanced option to "exclude ICMPv4 and v6 traffic" option would solve this too.

Let me know if I just said a lot of nothing, but this isn't my first rodeo fighting ICMP solicit issues with traffic shaping on opnSense. For some reason on my previous pfSense install, that was never an issue.

Gruni22 commented 3 weeks ago

I have shaping working on both my WAN links - and both have IPv6 enabled. The only difference between my rules and the rules in the guide, is that I do not have a mask set on the queue, and only use direction on the rule.

Could you test what that does?

I also tried to enable traffic shaping according the instructions linked above, which lead to immediate outage of IPv6 Internet. Trying without "mask" on the queue, IPv6 remains online so far. Future will show, if it is stable.