Messages

Just as another data point, icmp2 works for me, IPv4+6, local + forwarded ICMP traceroutes tested.  Thanks to all involved!

I have no idea about AT&T or this bypass procedure but I had a quick read of the code in the repo you linked, and one thing I notice is your screenshot says 'Starting pfatt' but the latest code says 'Starting opnatt'.  It looks like that 'pfatt' message dates back to this commit - https://github.com/owenthewizard/opnatt/commit/134dd592d5ee459b88d94dac8a6110265ebba1a2 - in which many other things were changed, including how it runs wpa_supplicant.  I also notice your screenshot, near the bottom, it says 'wpa_supplicant running on PID', and doesn't show a PID number, suggesting wpa_supplicant is not running, which makes me think it's not calling wpa_supplicant in the right way perhaps.

So tl;dr - have you tried the latest upstream version of this script?

Also I wonder if you can find any more clues in any logs and/or try running the script from the console/SSH, to see if it gives any more diagnostics about what's going wrong.

I'll hotfix this now and then we're hopefully back to 24.1.8 state. The rest of the goodies for IPv6 are stashed away on 24.7 which makes this extra work worth the while eventually.

24.1.10_2 has been stable for me overnight, with OpenVPN turned back on.  Thanks for the fix.

Ben

I came up with this fix which works, but might be a bit crude - it's on the github bug too.

Initially https://github.com/opnsense/core/commit/eb269e0d4a is looking good for me.  I've re-enabled OpenVPN and DHCPv6 still renews ok.  I'm going to reboot and make sure a clean boot runs fine.

Thanks, I've applied that and will report back.

I disabled OpenVPN again and on the next attempt, dhcp6c succeeded.

Turning my OpenVPN client back on has broken it.  Getting desperate, I found this:

Code Select Expand

$ sudo tcpdump -i ovpnc1 net fe80::/10 or net ff02::/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), capture size 262144 bytes

14:03:16.232230 IP6 fe80::xx.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit

The DHCPv6 packet is being sent over the VPN interface.

Any idea why that would happen?  It makes little sense to me.

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.

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

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.

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.

I've done:

Code Select Expand

opnsense-revert  -r 24.1.9 dhcp6c

(and rebooted) to narrow down where the problem might be, will see how that goes.

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).

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