Messages

My WAN interface configuration:
- DHCPv6
- Only request IPv6 prefix
- Sent Prefix Hint
- IPV6 Privacy Extensions enabled

OPNsense 24.7.11_2-amd64

My reading of the code is that in this case it would use the link-local address as you have seen.  It looks as if setting the 'Optional prefix ID' under Settings > WAN > DHCPv6 may cause it to use the GUA, if that's something you can try (i.e. if the prefix for your ISP is bigger than /64 and you can assign a /64 to your WAN interface).

In your first post you say

it seems like an IPv6 address is also assigned, the WAN6 gateway only displays a link-local IPv6 address

.. but I don't think that's a problem?  My ISP also provides a link-local gateway address.

I don't know about your ISP but my ISP will provide an address via DHCP which for whatever reason doesn't work.  I've never figured it out.  I just use 'Request a prefix only' and a /64 from my /56 on the WAN interface and all is good.

What do you mean about the gateway being defunct?

On interfaces -> overview for your WAN interface, what else is shown under Routes if you click expand?

I tracked down the reverting nologin problem to a missing config.inc include, and added some stuff to support bash.

https://github.com/opnsense/core/pull/8156

Thanks.

Further input on the shell changing problem: if I change my non-root user's shell, it immediately gets set to nologin in /etc/passwd.  After reboot, it is updated with the correct shell.  This seems to be repeatably reproducible.  I'll dig further into it later if no-one else figures out the problem first.

Hi

Before I do further digging to see what's going on I thought I'd see if this is a known issue in 25.1.

I've installed a test VM on 25.1 and when creating a new non-root user I've noticed two things:

• Even though bash is installed (via pkg install bash) and appears in /etc/shells, it doesn't appear as a shell choice in the UI.
• If I choose another valid shell it still gets written as nologin in /etc/passwd and so I can't log in as that user via SSH.

The user in question is a member of 'admins' and initially didn't have any permissions (assuming it inherited from the admins group) - I've also tried explicitly setting 'all pages' as a permission at the user level and it didn't help.

I can't see anything obvious in the logs.

Is this a bug or have I missed something obvious?

Thanks
Ben

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