For a recent fresh OPNsense installation I decided to go with Dnsmasq from scratch. My setup is a PPPoE dual stack WAN connection, getting a /48 IPv6 Prefix and IPv6 gateway works fine. The LAN Interface IPv6 is using Track Interface with the WAN interface as parent and Allow manual adjustment of DHCPv6 and RA checked.
In Dnsmasq I have configured a IPv4 DHCP range, a IPv6 DHCP range (LAN Interface / :: / LAN Constructor / ra-stateless + ra-names / default 60 Interval / default 1200 Lifetime / default 86400 Lease time) and Router Advertisements in checked in Dnsmasq/General, all according to the docs: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv6-and-router-advertisements. For both IPv4 and IPv6 I have also configured a DHCP Option/Option6 with a DNS4/DNS6 server address (which is on the LAN, outside OPNsense). Services/Router Advertisements (radvd) and ISC DCHPv4+6 are all disabled.
IPv4 connectivity works fine as expected. IPv6 doesn't.
All clients get IPv6 GUAs and routing looks ok. (netstat -r -n -6). The configured DNS4/DNS6 server addresses are set and all DNS requests are received in the DNS server and are answered accordingly.
IPv6 connectivity however is very unstable. Although the numbers are good, some clients do not have IPv6 connectivity at all from the start, others have it at first but drop it later. Apps and websites fail to load content, 0/10 on test-ipv6.com and all IPv6 related showing red on ip6.biz.
As this happens on all sorts of devices (Android, iOS, Linux, MacOS, Windows11), both wired and wireless I finally narrowed it down to Dnsmasq RA.
After removing the Dnsmasq IPv6 DHCP range, turning off RA in Dnsmasq/General and enabling Services/Router Advertisements (Assisted / Advertise Default Gateway checked / default 200 min / default 600 max) all is fine again for all clients.
Before hinting at a Dnsmasq RA bug, could it relate to anything (mis)configured?
For the record:
OPNsense 25.1.8_1-amd64
FreeBSD 14.2-RELEASE-p3
Dnsmasq 2.91,1
radvd 2.20
I run the exact same also with PPPoE Dual Stack (Deutsche Telekom) and also with pretty much the same configuration you lined out above and don't have any issues I noticed (yet).
If IPv6 connectivity drops, can you check if the clients deprecate prefixes too early, or drop their IPv6 default route?
You can also check if the Router Advertisements contain the correct prefixes by doing a packet capture with Wireshark on the clients.
Maybe the switches you use do weird things with Router Advertisements before they reach the clients?
I had incredibly flakey IPV6 performance with a PPPoE connection. In the end, changing the WAN MTU fixed it completely.
For Windows, I used this to determine what the MTU should be https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router (https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router)
Thanks for thinking along!
Network hardware is not the cause as IPv6 connectivity works fine with radvd doing AR. I did suspect my Access Point configuration (multicast/igmp) at one point, but then it turned out that wired devices were also affected.
My WAN MTU is left blank (default). It says: Calculated PPP MTU: 1492. According to the Netgear test it should be 1490. According to my ISP it should be 1500. I doubt this is the culprit either as the default setting works fine with radvd doing AR.
Both Dnsmasq and radvd broadcast the correct prefix (and both /64), the client GUAs are accordingly in both setups. I will definitely investigate the RA of both radvd and Dnsmasq in more detail. Early deprecation of prefixes sounds interesting to check as well.
So, on my OPNsense box, I'm running dual PPPoE connections. When I enable Router Advertisements (RAs) via dnsmasq, clients seem to get their IPv6 addresses just fine. However, in actual use, IPv6 frequently drops or just won't connect. But if I disable the dnsmasq RAs and switch to Services: Router Advertisements (which is basically radvd), then everything works perfectly fine.