clients loosing ipv6 internet now and then

[dMopp]

See title. It is fixable by restarting dhcpdv6. Internet access is back immediately after restarting the the ISC DHCP v6. This issue is new with the current release.

For now iam using from to restart the dhcp every hour … :/

[cloudz]

I've been struggling with IPv6 since the 24.7.1 update. High latency spikes, drops but never had to restart the DHCPv6 daemon tho. Just rolled back to 24.7_9 in a hope that fixes my issues.

@OPNsense team : something is terribly wrong in the IPv6 implementation in 24.7.1, just can't put my finger on it. Next to RRD stopping graphing on interface issues.

[dMopp]

I bet its not opnsense, its a BSD issue ... :|

[doktornotor]

Next to RRD stopping graphing on interface issues.

See https://github.com/opnsense/core/issues/7753#issuecomment-2282723192

As for the original topic of the thread, DHCPv6 is absolutely not required for IPv6 to work, no information here to debug any issues.

[dMopp]

Next to RRD stopping graphing on interface issues.

See https://github.com/opnsense/core/issues/7753#issuecomment-2282723192

As for the original topic of the thread, DHCPv6 is absolutely not required for IPv6 to work, no information here to debug any issues.

What kind of information do you need, except that a restart of dhcpv6 fixing the issue ?

[cloudz]

Next to RRD stopping graphing on interface issues.

See https://github.com/opnsense/core/issues/7753#issuecomment-2282723192

As for the original topic of the thread, DHCPv6 is absolutely not required for IPv6 to work, no information here to debug any issues.

I think restarting DHCPv6 triggers something else to be restarted or repopulated. It might be the quick fix to an underlying problem. For me it's intermittent drops of up to 10 seconds - it looks like at those moments the devices on my lan don't have either a route or an IPv6 address. It shows because I use Uptime Kuma extensively to monitor servers inside and outside of my network -- and IPv6 keeps dropping since last week when I updated.

[doktornotor]

You have posted zero information about your IPv6 configuration, about the clients, info in the logs or whatever else. I would strongly suggest going back to basics:

1/ Disable the DHCPv6 nonsense altogether for all IPv6-enabled interfaces.
2/ Under router advertisement, set it to Unmanaged for all IPv6-enabled interfaces.

Now, go test again.

https://docs.opnsense.org/manual/radvd.html

[cloudz]

Why? It works perfectly fine in 24.7 with the exact same config and it has been since a long time. It doesn't in 24.7.1

I use DHCPv6 with static leases for 2 subnets with managed RA, others have it set to unmanaged and rely on the ISP. On my client devices DHCPv6 works well. I don't have android or IoT devices on those subnets. I need it for audit and logging reasons.

I rolled back and no more issues. Stable connections all around.

[doktornotor]

Ok, good luck, have better ways to waste my time with.

[dMopp]

Clients doesnt matter. Windows, Linux, macOS, iOS. All loosing IPv6 WAN Access. (OPNsense itself still has working IPv6 WAN)

OPNsense is configured like that:

PPPoE --> DHCPv6 over IPv4
Multiple VLANs, configured as Track Interface. RA is configured as Assisted. (except the SERVER VLAN, there iam using static IPV6 + Managed RA.)

I will NOT disable DHCPv6 because its used for static mappings AND was working before the latest update. Somehow there was a bug introduced with the lastest update and IAM reporting it here to seek for assistance. Disabling something which is required in MY setup, is, like my regular restart, not solving the issue, but putting some glue on an underlying issue.

Iam able to provide any kind of information iam asked for. I will also NOT roll back, even if this would fix my issue, because if so, i cant test some patches the devs might provide to fix the actual issue. (my regular restart is fine for now)

[doktornotor]

All loosing IPv6 WAN Access. (OPNsense itself still has working IPv6 WAN)

Wonderful, finally some relevant info. Now, perhaps look at the logs and see what's going on at the time when the clients "lose IPv6 internet". Defining more precisely what does mean would help as well, such as whether the name resolution does not work, or ping via IP address does not work as well, or whatever.

As someone else noted above, restarting dhcpv6 merely triggers some action related to IPv6 that fixes things for you.

looks like at those moments the devices on my lan don't have either a route or an IPv6 address

hence my suggestion to get the damned DHCP out of the way to narrow down the issue. But then again, that issue might have nothing to do with your issues. This thread becoming a place for random complaints about IPv6 not working in completely different setups will not be very productive, I'm afraid.

[dMopp]

I started just for my issue. Resolving works as well. At least on opnsense. Clients even can’t reach the firewall over ipv6. I might find some time later on to trigger the issue again, for the weekend I will my workaround in place

[doktornotor]

Clients even can’t reach the firewall over ipv6.

Reach how? Using the hostname? The GUA LAN IP? WAN IP? Some ULA? The link-local IP? Test all relevant of them. Post the ifconfig / ip a s / whatever output and route info from the client when it does not work. The routing firewall logs. Give people something to work with, the normal networking issues debugging sort of stuff!

Repeating "it's broken and worked before, it sucks" is not useful but pure waste of time.

[sjm]

Well... I can confirm some weird IPv6 connectivity issues too.

Please note: the ping was ran on the OPNsense box itself, but the results look like exactly the same if I try it from the internal network.

My IPv6 WAN connectivity just breaks somehow occasionally.

Here I was running IPv6 ping to my cloud vm every 3 seconds, with ping -n6 -i 3 -c 200 xxx.yyy.zzz

and when checking the results, every now and then I can see this kind of weirdness:

Code: [Select]

16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=96 hlim=55 time=6.646 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=97 hlim=55 time=6.628 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=105 hlim=55 time=2126.610 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=106 hlim=55 time=6.617 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=107 hlim=55 time=6.510 ms
...
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=113 hlim=55 time=6.544 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=114 hlim=55 time=6.614 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=119 hlim=55 time=2084.833 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=120 hlim=55 time=6.610 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=121 hlim=55 time=6.538 ms
...
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=154 hlim=55 time=6.656 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=155 hlim=55 time=15.322 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=156 hlim=55 time=6.651 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=162 hlim=55 time=19.360 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=163 hlim=55 time=7.046 ms
16 bytes from 2a01:4f9:xxx:zzz::1, icmp_seq=164 hlim=55 time=6.548 ms

so... a bit randomly, total IPv6 blackout is observed for roughly 20 seconds.

Meanwhile, just for comparison, I have an OpenWrt box connected to the same WAN vlan and it does not exhibit this kind of IPv6 packet loss. So IMO problems in operator side are more or less ruled out and my OPNsense has something weird going on.

Futhermore, this problem began exactly after I upgraded to OPNsense 24.7.1.

If anyone has any good hints what to look after with tcpdump, I am all ears (and eyes).

BR, -sjm

[sjm]

The intermittent IPv6 connectivity breaks look like they happen at more or less random intervals. At least I cannot find any clear pattern. Usually there will be one or two breaks in a 10-15 minute period, but it can also run almost 30 minutes flawlessly.

I have a ping monitoring running on my raspi4 with Telegraf, monitoring 3 separate external IPv6 addresses.
Meanwhile, the IPv4 addresses in the same monitoring system are working just fine.

After OPNsense 24.7.1 upgrade, it looks like this.

https://imgur.com/a/ipv6-ping-loss-1WBVHcN

BR, -sjm