Unfortunately, https://forum.opnsense.org/index.php?msg=262791 seems to apply to 26.1 as much as to the 25 series. I have now tried to switch from dnsmasq (which has another bug with SAs, to be reported separately) back to radvd and KEA for DHCPv6, plugging in a carp.d hook script to only let radvd run on the respective master.
This seems stable for my desktop devices, but Android devices, though they consistently get a SLAAC pair of addresses, fail to connect.
Is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 supposed to apply to 26.1 kernels? Has the whole patch set been reverted or is it supposed to be fixed?
> Is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 supposed to apply to 26.1 kernels? Has the whole patch set been reverted or is it supposed to be fixed?
We do not really know and they made it clear they really do not care.
I still think FreeBSD users suffer more from this than OPNsense users ever did.
Cheers,
Franco
Quote from: franco on March 16, 2026, 08:27:53 AMWe do not really know and they made it clear they really do not care.
I'm sure you don't say that lightly but it reads a bit nonchalantly in text. Is there reassurance for users w.r.t upstream support? 😅
> Is there reassurance for users w.r.t upstream support?
Basically all of upstream support is hinged in the fact that nobody is obligated to give upstream support.
They made this VERY clear and it's their and their user's loss.
https://forum.opnsense.org/index.php?topic=50102.0
Cheers,
Franco
@OPNenthu you can try to open another issue on the FreeBSD bug tracker. For that to have any chance of success, though, you would need to reproduce the issue on a plain FreeBSD system without any additions, specifically not OPNsense.
Basically what FreeBSD said the last time this went sideways and then ignored a report by a user for months. I simply have my doubts this will improve by asking more of users yet again.
Cheers,
Franco
Thanks, @franco for the additional context. I have to admit that wading through the FreeBSD bug report linked above was ... painful ... and does not inspire a lot of confidence in future upstream behavior.
While I could probably try to reproduce on a standard FreeBSD kernel (assuming I could just take the OPNsense generated radvd and pf configs and run them on stock FreeBSD), it would be a major time investment for something that has been bugging me for nearly a year but hasn't been a major personal blocker. And reading the bug report, it might be wasted time anyway if upstream doesn't seem to care much about IPv6 stability with pf. With my current home setup (assuming it doesn't turn up any other unexpected surprises), I can fully use IPv6 locally (ULA) and globally (PD assignment to OPNsense, identity association for VLAN interfaces, radvd with hacky master/backup script, kea) from my Linux desktops/laptops and locally run services. Android clients for now fall back to IPv4-only, which is not terrible and - importantly - is not currently noticed by other members of the household, but still bugs my sense of proper networking setup. If I get another long evening to dedicate to this, I might write up a small post on the setup and all the components coming together.
However, for our university student lab setup, this might become a major blocker for some lab scenarios - especially as the packet dropping is erratic and unpredictable and fairly impossible to debug for students. We'll have to think about some of those and how best to deal with IPv6 in teaching setups. We've been using OPNsense as our main example in student labs due to the great UI and nice integration of components (thanks to the whole team for all the work!) for years, and I'd hate to have to move some of them over to VyOS or OpenWRT. The students would hate the change even more, I'm sure :)
@patrick @franco Thanks- I picked up on another subtle hint into the upstream mindset in a video (https://www.youtube.com/watch?v=JtSg6ylDALo) I was watching to learn about packet flow through the stack. At the segment starting 00:03:40, there's a comment about the "support policy" if multiple firewalls are enabled. I guess that could be aimed at OPNsense since we use ipfw for shaping.
@rmayr Although I haven't noticed our Androids not able to get online, I do now wonder if they're falling back to IPv4 and I'm just not aware. I see F/W and Unbound logs where sometimes the v4 address is used and sometimes the v6, but I thought it might be an artifact of Happy Eyeballs. Something to dig into at some point, but as you say, no one in the house is complaining.
As a learner of sorts, I totally agree OPNsense is an excellent learning platform.
Basically we use https://github.com/opnsense/src/commit/cd9f3dd75849f to match OpenBSD after a number of incomplete backports from OpenBSD to FreeBSD.
Internally, someone from FreeBSD said to me this is not considered correct so it's "naturally" refused. It's also a bit confusing since the initial security report that started this downward trend was only for FreeBSD and not for OpenBSD and not even all OpenBSD commits are equal in this if you follow the FreeBSD argument.
Now, I do not know if OPNsense has all corner cases covered (and OpenBSD for that matter), but I do agree that going back to the drawing board to report this properly and fix it is a huge time sink and unclear if someone even acts on this data afterwards.
One way to "fix" this for educational purposes is to turn off state tracking for the ICMP rules for better or worse, but basically just going back to where the code was before all of this started and try statetype set to "sloppy" or "none" to see if this improves the behaviour:
https://github.com/opnsense/core/blob/5b07e0917484b90d0e9411c5e2c4f8ed5a07b8c7/src/etc/inc/filter.lib.inc#L242
We can consider making this configurable if it has a real world benefit.
"Others" have theorised the solution lies in sysctl knobs as you can see from https://redmine.pfsense.org/issues/16146 but it really all boils down to be careful what you sponsored for. ;)
Cheers,
Franco
There were previously (maybe ongoing?) issues with IPv6 fragmentation as well, and that video also briefly touches on some of the challenges and work done in FreeBSD to support that for pf. The gist is that IPv6 packets have to be collected and assembled before passing on to pf in order to assure correct inspection and state tracking (and to avoid potential attacks). That effort apparently wasn't smooth by the author's own admission. I don't fault him but I worry about the state of things because we have several GH issues in OPNsense with related observations around icmpv6 and packet loss.
I risk conflating unrelated things, though. </>
I suppose we'll see soon enough how FreeBSD 15.1 performs in OPNsense 26.7.
Cheers,
Franco
Quote from: rmayr on March 16, 2026, 12:23:53 AMThis seems stable for my desktop devices, but Android devices, though they consistently get a SLAAC pair of addresses, fail to connect.
Are you sure it hasn't to do with Android's energy saving behaviour? Android >=15 ignores IPv6 if RA lifetime is below a certain threshold (e.g. 180 seconds).
Quote from: glasi on March 16, 2026, 02:07:58 PMQuote from: rmayr on March 16, 2026, 12:23:53 AMThis seems stable for my desktop devices, but Android devices, though they consistently get a SLAAC pair of addresses, fail to connect.
Are you sure it hasn't to do with Android's energy saving behaviour? Android >=15 ignores IPv6 if RA lifetime is below a certain threshold (e.g. 180 seconds).
Wow, now I feel slightly stupid in that I hadn't learned of this change beforehand. Indeed, setting RA lifetime from 120s to 300s makes my test Android devices set a default route again. One weird aspect is that the Android device picks up and sets its two random SLAAC addresses perfectly well with a lifetime of 120s. It just doesn't seem to set the default route.
(Context: I am using values much lower than the default 1800s because of ongoing debugging with IPv6 handover when the firewalls switch master/backup CARP roles.)
But now I'm back to the behavior of "it works for a few minutes, and then it breaks in an irregular manner, causing network connections from the Android devices to fail or become extremely slow". So, to keep my other members of the household happy, I'm intentionally setting the lifetimes back to 120s and therefore letting Android devices fall back to IPv4-only for the time being. I will continue debugging.
Thanks for the pointer! I learned something new today.
Quote from: franco on March 16, 2026, 12:43:10 PMOne way to "fix" this for educational purposes is to turn off state tracking for the ICMP rules for better or worse, but basically just going back to where the code was before all of this started and try statetype set to "sloppy" or "none" to see if this improves the behaviour:
https://github.com/opnsense/core/blob/5b07e0917484b90d0e9411c5e2c4f8ed5a07b8c7/src/etc/inc/filter.lib.inc#L242
We can consider making this configurable if it has a real world benefit.
Please don't forget to comment on this...
Quote from: franco on March 18, 2026, 07:29:21 AMQuote from: franco on March 16, 2026, 12:43:10 PMOne way to "fix" this for educational purposes is to turn off state tracking for the ICMP rules for better or worse, but basically just going back to where the code was before all of this started and try statetype set to "sloppy" or "none" to see if this improves the behaviour:
https://github.com/opnsense/core/blob/5b07e0917484b90d0e9411c5e2c4f8ed5a07b8c7/src/etc/inc/filter.lib.inc#L242
We can consider making this configurable if it has a real world benefit.
Please don't forget to comment on this...
Not forgotten, it's on my TODO list to try it as soon as I find the next time slot for in-depth debugging :)
In the meantime, I have disabled all forms of IGMP/MLD snooping on switch(es) and access points that are in-path just to reduce other potential sources of errors (though for the network traces I posted before, RAs and NDs never seem to have been the problem).
I am trying it with "sloppy" right now, but am not sure if the problem really is limited to only ICMP6. As before, It's (also) TCPv6 SYN packets that are sent (unicast) to the OPNsense LAN Ethernet MAC address with a target IPv6 address on the WAN side.
Same high-level behaviour still: After some time being connected on the WiFi, trying to reload https://test-ipv6.com simply times out with "No IPv6 address detected" and those TCP SYN packets never receiving a reply. I can see the SYN packets on the LAN side of OPNsense:
22:32:09.825963 fa:17:c7:f8:dd:85 > ca:00:00:00:64:01, ethertype IPv6 (0x86dd), length 94: <myprefix>:2d9:c3d6:1433:ee1.37430 > 2a01:7e03::f03c:94ff:fed0:11a6.443: Flags [S], seq 1969279674, win 65535, options [mss 1432,sackOK,TS val 2090357468 ecr 0,nop,wscale 8], length 0
22:32:10.379084 fa:17:c7:f8:dd:85 > ca:00:00:00:64:01, ethertype IPv6 (0x86dd), length 94: <myprefix>:2d9:c3d6:1433:ee1.22000 > 2a01:4f8:13b:1643::2.443: Flags [S], seq 1286341450, win 65535, options [mss 1432,sackOK,TS val 2535439579 ecr 0,nop,wscale 8], length 0
going out on WAN (pppoe0) and immediately being answered from the WAN side:
22:32:09.826029 AF IPv6 (28), length 84: <myprefix>:2d9:c3d6:1433:ee1.37430 > 2a01:7e03::f03c:94ff:fed0:11a6.443: Flags [S], seq 1969279674, win 65535, options [mss 1432,sackOK,TS val 2090357468 ecr 0,nop,wscale 8], length 0
22:32:09.996886 AF IPv6 (28), length 84: 2a01:7e03::f03c:94ff:fed0:11a6.443 > <myprefix>:2d9:c3d6:1433:ee1.37430: Flags [S.], seq 2081477611, ack 1969279675, win 58996, options [mss 8440,sackOK,TS val 3773941169 ecr 2090357468,nop,wscale 7], length 0
22:32:10.379114 AF IPv6 (28), length 84: <myprefix>:2d9:c3d6:1433:ee1.22000 > 2a01:4f8:13b:1643::2.443: Flags [S], seq 1286341450, win 65535, options [mss 1432,sackOK,TS val 2535439579 ecr 0,nop,wscale 8], length 0
22:32:10.398194 AF IPv6 (28), length 84: 2a01:4f8:13b:1643::2.443 > <myprefix>:2d9:c3d6:1433:ee1.22000: Flags [S.], seq 2319345901, ack 1286341451, win 65178, options [mss 1290,sackOK,TS val 782819494 ecr 2535404002,nop,wscale 7], length 0
But those replies never make it back to the LAN interface. A few seconds later, I get a block entry in the filter log, for a different packet than the one that was silently dropped, though:
WAN In 2026-03-22T22:32:44 TCP [2a01:4f8:13b:1643::2]:443 [<myprefix>:2d9:c3d6:1433:ee1]:52302 block Default deny / state violation rule
And that's what's really confusing me: None of that ever happens with other Linux clients on the same LAN, and if I reconnect the Android client to get a new SLAAC address, it immediately works again (for a short time). Which part of the pf state tracking logic goes out of whack here, and why only for Android clients?
Hi everyone, I'm not sure if this will help with disconnections on Android devices, but it also happens with iOS devices. A post mentioned that the solution to the disconnections was to extend the lifetime.
Extend the default RDNSS advertisement lifetime to work around RDNSS expiry bug on macOS / iOS
https://blog.infected.systems/posts/2024-12-18-working-around-macos-and-ios-rdnss-expiry-bug/
I'm a bit puzzled by this. Why does a device waking from sleep after hours or even days assume nothing changed and not immediately renegotiate just everything about its network environment? Even if it's wifi and the SSID is the same I could close the lid of my Macbook in our office in Karlsruhe and reopen it in our office in Frankfurt.
Quote from: Patrick M. Hausen on March 23, 2026, 12:33:30 AMI'm a bit puzzled by this.
You are not the only one... LOL! :)
But there have been many topics about this lately and there seems to be something weird going on when the right "timing values" are not used.
Since I can't test it for now I will just keep reading as much as I can about it and hope things will get sorted by the time I get to use IPv6 here!
This happens to me with iPhones. The default Lifetime configuration in rad.conf is enabled. When the iPhone has been in sleep mode for 40 minutes and then wakes up, it's disconnected from the Wi-Fi network.
The lifetime must be set to a value at least 3 times the value of MaxRtrAdvInterval (which is defined in RFC 4861 as a maximum of 1800 seconds). There is no maximum value defined in the RFC for an RDNSS lifetime. Therefore, for those who care, as long as we set our RDNSS lifetime to more than 5400 seconds, we can guarantee that we are within the specifications of RFC 8106.
Is there a way to set this on Dnsmasq? I'm reading that it sets the RDNSS lifetime to the RA lifetime, but I don't see a specific option for it.
We have an older generation iPad here that sometimes fails to connect on wakeup (not consistent), but it does still show the IPv4 DNS in Settings when this happens so I"m not sure it's the same bug. It only recovers with a device restart.
Can't configure AdvRDNSSLifetime in Dnsmasq Opnsense?
I can change the RA lifetime on a range but I think I cannot independently change the RDNSS lifetime. Could be wrong.
I don't know if it can be changed, can it be done manual
Recursive DNS Server (RDNSS) lifetime in Router Advertisements (RAs) is automatically managed based on the shortest lifetime of the preferred address on the interface. While RDNSS support adheres to RFC 8106, Dnsmasq does not provide a direct configuration option to set an explicit RDNSS lifetime value.
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014753.html
Does this mean it's tied to the DHCPv6 lease time rather than the RA lifetime? I'm not sure how to interpret it.
Hi everyone, I don't know how Dnsmasq works configuring pltime is not the same as configuring RDNSS
In opnsense, dnsmasq can be used in conjunction with radvd and used explicitly.
interface vlan123 {
RDNSS 2001:db8:cafe:beef::1 {
AdvRDNSSLifetime 604800;
};
};
The problem is that on many devices, when lifetime RDNSS is not configured, the IPv6 DNS disappears, and with an IPv4 and IPv6 connection, the device will only have IPv4 DNS.
It is also recommended to configure in interface, preferred and valid lifetime to avoid disconnections.
interface igc1 {
prefix 2a01:xxxx:xxxx:xxxx::/64 {
preferred lifetime 86400
valid lifetime 108000
}
}
dns {
lifetime 604800
nameserver {
2a01:xxxx:xxxx:xxxx::1
}
search {
home.arpa
}
}
Quote from: Patrick M. Hausen on March 23, 2026, 12:33:30 AMI'm a bit puzzled by this.
Android trying to reach a GUA from a link-local source address is the level of competence we're dealing with here.
Cheers,
Franco
Quote from: franco on March 23, 2026, 01:53:37 PMQuote from: Patrick M. Hausen on March 23, 2026, 12:33:30 AMI'm a bit puzzled by this.
Android trying to reach a GUA from a link-local source address is the level of competence we're dealing with here.
Cheers,
Franco
In my tcpdumps above, I replaced my GUA prefix as supplied by the ISP through PD with <myprefix>. This doesn't refer to the ULA range I use (which is also on the respective VLANs, but does not seem to interfere in the behaviour I am seeing).
Another small data point: "Disable interface scrub" does not seem to change anything when turned on.
I'm going to try enabling IPv6 SLAAC for Android clients on one of our guest/lab WiFi segments at our university institute to see if I can reproduce the problems there as well. It has a complicated, but different OPNsense base setup, so we might learn something from the differences.
I'm not sure if the issue(s) reported here are the same or related to the issue I had, but just in case: I bought a Motorola Edge 70 (in case the model matters), which runs Android 16. I quickly noticed that after a few minutes (sometimes longer) IPv6 connectivity stopped working (like visiting ipv6-test.com, or ping6 www.google.com from termux). This would work after rebooting, or switching airplane mode off/on, or turning WLAN off for a while and then back on.
I'm still on Opnsense 25.7 (need to find the time to upgrade w/o causing disturbance at home..), and was using the standard RA daemon (and DNSMASQ for DHCP). I tried all sorts of combinations of RA lifetimes, etc. but couldn't get it to work reliably. I then switched to dnsmasq (defined an IPv6 range and enabled "ra-statless", tried also with "ra-names" and with "slaac"). and it still didn't work reliably.
Out of desperation I then enabled ra-advrouter (and only that mode), and suddenly (OK, I restarted the phone yet again, just to make sure I started with a clean state) IPv6 has been working reliably for about 24h, including short and long sleep/doze periods.
I'm by no means an IPv6 expert, and I still have to read RFC 3775 sections 7.2 and 7.3, but maybe this can serve as a workaround to other users of Android 16 affected by this, and (maybe) some expert might be able to explain why this works.
Thanks.
[EDIT] Nope. It didn't work. I wrote too soon, because minutes after posting this IPv6 stopped working again. I leave it here in case it can (somehow) help and/or somebody has suggestions.