IPv6 connectivity loss on 24.1.10

[Ben S]

Thank you for this quick fix, I'm trying 24.1.10_1 now.

Last night I did:

Code: [Select]

opnsense-revert -r 24.1.9 dhcp6c
opnsense-revert -r 24.1.9 opnsense
And _one_ of these did resolve the problem, it was late and I didn't have time to do them separately and confirm which one.

I'm not sure though if mine is the same problem - just because when IPv6 is working well, the DHCP replies all seem to come from a link-local address, so not sure if/how the GUA fix here is relevant.  Still, I'll wait and see.

Thanks
Ben

[franco]

It depends... improving IPv6 is like playing whac-a-mole. Best to make sure all packages are on the latest version (see health audit) and then reassess.


Cheers,
Franco

[Ben S]

Unfortunately it's still not working for me.  Same as yesterday - I see a log entry saying the DHCPv6 packet is being allowed outbound, but I don't see it being sent in tcpdump on the WAN interface.

What can I do to diagnose this further?  I don't understand why the packet is being apparently allowed, but not actually sent (unless tcpdump is lying to me).

Thanks
Ben

[franco]

Suricata IPS mode running or Zenarmor? Few keep reporting that IPv6 (both WAN and LAN) can be impeded by it, but I honestly don't know why.


Cheers,
Franco

[Ben S]

I'm running neither of those - nothing complicated at all here really.  Aside from usual firewall/NAT I run unbound and an OpenVPN client (the latter of which I have disabled - can't see how it would affect this, but who knows).

[Ben S]

I've done:

Code: [Select]

opnsense-revert  -r 24.1.9 dhcp6c
(and rebooted) to narrow down where the problem might be, will see how that goes.

[franco]

24.1.9 is the worst one. The baseline is 24.1.8 and 24.1.10 should work according to other qualified reports.

I understand that IPv6 seems to have issues, but I doubt a bit that all the things going on are related to just OPNsense. Half the issues are on the ISP side, intermittent or otherwise.


Cheers,
Franco

[Ben S]

Interesting.  I never had a problem on 24.1.9, at least not 9_4.

Well for me it looks like the previous command has resolved the problem - at least after 30 minutes, the first renewal has worked ok.  I'll let it run a bit longer and see how this goes.

From a read of the diffs I am confused how the behaviour has changed.

[franco]

It hasn't much. There are two bugs that have now been fixed as of 24.1.10_1

o dhcp6c was not renewing its IA-NA (introduced in 24.1.9)
o the DHCPv6 WAN requirements rule was cleaned up some servers seem to send from a GUA instead of a link-local which doesn't make a lot of sense as it complicates the way IPv6 is acquired probably using the temporary SLAAC address (introduced in 24.1.10)

The problem with all this is my main IPv6 setup doesn't show a considerable amount of the side effects that exist out there in the world so while all this is tested it doesn't matter much without worldwide community coverage. I'm confident about a number of other IPv6 changes in the past weeks which brings our IPv6 connectivity into a state that haven't seen elsewhere so what we see as breakage is a sign of moving this forward considerably. If anyone wants to think otherwise that's ok too. I could really use some help so all free energy is welcome.

And then again during testing I see the wildest intermittent issues, sometimes in response to re-requests happening frequently where the ISP just refuses to answer for a while.


Cheers,
Franco

[meyergru]

Same problem here. 24.1.9 ran fine, problems with 24.1.10 after a while on dhcpv6 renewal. With that version, the GUA prefixes were gone after renewal.

Then I saw 24.1.10_1 was out, installed and rebooted, same behaviour.

Then did "opnsense-revert -r 24.1.9 opnsense" and voila - problem is gone.

ISP is Deutsche Glasfaser, no IA-NA, only IA-PD. Strange thing is, I have 3 machines with that ISP, only two of which show this behaviour. Because of CG-NAT, the problem is hard to diagnose from remote when IPv6 connectivity is lost.

I certainly know of the IPv6 improvements that are about to come with 24.7 and will probably stay on 24.1.9 until then.

[franco]

24.1.10_1 needs a filter reload (and 24.1.10 a reboot if you want to be sure).


Cheers,
Franco

[Ben S]

Worth mentioning that I'm also in the no address, prefix-only camp.

I'm happy to help diagnose in any way I can - the problem seems to be fairly consistent here, and it's not a remote router with problematic access.

[franco]

> Worth mentioning that I'm also in the no address, prefix-only camp.

In that case the dhcp6c changes should be irrelevant either way. Same as here for me. Try to keep running a clean reboot of 24.1.10_1 and see how far it goes.


Thanks,
Franco

[Ben S]

With the reverted dhcp6c my IPv6 was up for just over an hour (first request + 2x renewals at 30 minutes).  I've now updated to the latest dhcp6c again, checked everything else is correct with a health audit, and rebooted.  So this should be clean 24.1.10_1.

IPv6 initial request has worked (but it always did).  I will see what happens at renew time.

Thanks
Ben

[Ben S]

Well back on a clean 24.1.10_1 it's now working fine, which is good, but also slightly weird.  I don't know why it was failing this morning with the same settings, or last night, which was admittedly before the hot-fix, although all my logs indicate my ISP sends DHCP replies from a link-local address, so that shouldn't have mattered.

Anyway - good news that it works but I'm still nervous I don't really understand what went wrong.  I know it could be an ISP problem, but that would seem a huge coincidence and doesn't really fit with the odd behaviour I saw with packets being logged as allowed but not appearing in tcpdump.

I'll continue to monitor it anyway.