Yet another post about IPv6 connectivity loss after upgrading OPNsense

[Mintaka]

Having used OPNsense for five years without any major issues, I have witnessed for myself a sharp downturn in OPNsense update reliability over the last six months or so.  To now be in the situation where I am extremely apprehensive to upgrade my OPNsense router firmware - my main entry point onto the internet - due to recent upgrades breaking things is not a great place to find myself.

An upgrade towards the end of the 21.7 release simply broke IPv6.  Many people have reported this across many different forums, but with seemingly no reliable fix available.  Trying the various suggestions that usually involved rolling back individual packages or patching and recompiling source code proved to be a futile and time wasting exercise.  Only a fresh install to 22.7.0 resulted in restoration of IPv6 connectivity after several months for me.

Lo and behold, after enjoying a couple of months of stability with 22.7.x, the upgrade to 22.7.4 has broken IPv6 again.  Diagnosing the situation shows that:

• IPv4 connectivity is working flawlessly everywhere.
• IPv6 connectivity is working flawlessly from the OPNsense terminal - external hosts connectivity, DNS resolution, IPv6 address assignment, traceroutes to public IPv6 addresses, etc
• Publicly routable temporary IPv6 addresses within my assigned /48 are being successfully assigned to my LAN clients.
• Link-local IPv6 addresses are working within my LAN and local clients can ping each other.
• All clients on my LAN receive default IPv6 gateways - a fe80: and a 2a02: address belonging to the OPNsense host - both addresses are pingable by all LAN clients.
• Traceroutes from my LAN clients to any public internet IPv6 address all fail after the first hop to the OPNsense host.
• Temporarily relaxing firewall rules to allow the free flow of all IPv6 packets has no effect.

Short of re-installing 22.7.0 and not updating it, does anyone have a more sensible suggestion of what to diagnose next?

Thanks.

[Drauku]

I noticed a very similar issue, as I see many others have as well.

I do not necessarily use IPv6, so I disabled it on all interfaces and everything seems to work for me now.

This is certainly something that is a critical issue though.

[Koloa]

I've only started using OPNsense in the last month or two, so, I do not have the historical experience that you do.

However, I experienced exactly the same symptoms that you describe.  I have a native IPv6 provider, and, previous network equipment all worked flawlessly.  When I started with the Deciso OPNsense appliance in-line on my fibre connection to The World, IPv4 worked, but, IPv6 failed miserably.

The first symptom of this was in getting OPNsense updated itself.  Updates were crawling, and there were hundreds to perform.  Eventually I found a suggestion in this forum about ticking the "prefer IPv4 even if IPv6 is available" option, enabled it, and within a few minutes everything wooshed along.

In my case, the solution for devices in my LAN was to make some tweaks to the tunables in OPNsense.

In specific, I had to:

• Set net.inet6.icmp6.nd6_onlink_ns_rfc4861 to "1"
• Set net.inet6.ip6.accept_rtadv to "0"

Ironically, this solution came from a pfSense forum, and was called out as recommended for my specific provider.

Once I did this, and restarted, IPv6 was working correctly and natively on my LAN/WAN setup.  I have not yet unticked the "prefer IPv4" box yet, but hope to in the next few days.

I don't think this will necessarily help you, but my symptoms were exactly the same as yours until I made these changes.

[efahl]

Doing some reading on those tunables, I interpret the comments in the second paragraph of https://docs.freebsd.org/en/books/developers-handbook/ipv6/#_stateless_address_autoconfiguration_on_hosts as saying "accept_rtadv=0" for routers and "1" for hosts is appropriate.  My guess is that OPNsense should ship with default setting of 0.

On nd6_onlink_ns_rfc4861, I found this cryptic commit to DragonflyBSD, but nothing to justify it.  (There are a lot of posts saying "you need to set it to 1 for ISP xxx", again with no explanations offered.)

https://commits.dragonflybsd.narkive.com/sHTVVGIp/git-inet6-set-net-inet6-icmp6-nd6-onlink-ns-rfc4861-to-1-by-default

edit: fix typo

[sot3]

Lo and behold, after enjoying a couple of months of stability with 22.7.x, the upgrade to 22.7.4 has broken IPv6 again.  Diagnosing the situation shows that <snip>

Thanks for posting.  I don't visit this forum often but I'm in the same situation and that's why I'm here today; glad to hear it's not just me. 

[franco]

accept_rtadv=1 has been hardcoded for years and some instances even require a SLAAC address to operate correctly if you want a reachable WAN address from the outside especially when DHCPv6 does not offer an address to the reqesting interface.

I'm unsure why SLAAC breaks your WAN so that should be investigated first. Is this a DHCPv6 or PPPoE setup (or both). PPPoE IPv6 can overlap with selected IPv6 functionality if the ISP does not offer proper SLAAC or DHCPv6 at the same time.


Cheers,
Franco

[sot3]

It doesn't sound like the WAN is broken.  Bullet #2 from OP indicates that IPv6 is working from the router.

In my case (which matches OP's description), I'm DHCPv6 and the router has the same IPv6 address that it's had for months or more, and I can 'ping -6 google.com' from there.  The clients on the internal network also have their same addresses but cannot 'ping -6' outside of the local network anymore.  A quick visit to ipv6-test.com confirms that there is no ipv6 from the client.

Update: as luck would have it, it's working now.  I did make some changes yesterday to try and resolve it (including setting accept_rtadv=0 and restarting) but it was still broken when I left it.  I'll try to find out what happened.

[hescominsoon]

i've posted about ipv6 issues as well.  if i run opnsense in live mode..ipv6 works flawlessly.  the instant i install it and boot to the local disk on the same hardware ipv6 simply stops working..no idea what's going on...

[sot3]

I'm just as puzzled.  Mine's broken again and I didn't change anything.