Messages

I'm not 100% sure of the logic but I think dhcp6c may only run if an IPv6 router advertisement is received on the WAN interface, perhaps worth checking (e.g. with tcpdump) if you're seeing those.

From your last message it sounds like you have DNS problems, if you do a traceroute to an IP address do you see it routing out via the VPN?  And if you try from a machine which shouldn't route via the VPN or from OPNsense itself, do you see it routing out not via the VPN?

It might be useful to see screenshots of your VPN, gateway, NAT, and firewall settings in case anyone can see a problem, redacted as you see fit.  I have a similar setup where one network routes out via Mullvad VPN, I usually use WireGuard but I've tried OpenVPN too and both work fine with suitable gateway, NAT, and firewall settings.

Also Unbound - not sure what you'd need to change there, and since you mention DNS problems, maybe that's somewhere to start.  Are the clients behind OPNsense using OPNsense as their resolver?

Are you still not seeing any DHCPv6 responses from your ISP?  I wonder if it's worth copying the DUID from your working ISP router into OPNsense > Interfaces > Settings in case their DHCP server restricts to 'known' DUIDs only somehow.  That assumes the ISP router lets you find out what the DUID is of course.

It looks like the tailscale 'network' alias is a single IP on IPv4 - confirmed from Firewall > Diagnostics > Aliases and also ifconfig showing a netmask of 0xffffffff.

'any' should be safe as there should only be trusted traffic on the tailnet but you'd have to use 100.64.0.0/10 if you wanted to lock it down to tailscale IPs.  Seems like for IPv6 the interface does have a /48 mask so you'd only see this problem for IPv4.

It's been a while since I set this up and tested it but I think the gateway IP should be the remote exit node's Tailnet IP, not the OPNsense Tailnet IP.

In the absence of any better ideas, you could try:

Code Select Expand

sh -x /var/etc/rtsold_script.sh  em0
(replace em0 with WAN interface)

If I kill dhcp6c and run that the expected output is something like

Code Select Expand

+ [ -z em0 ]
+ grep -q '^interface em0 ' /var/etc/radvd.conf
+ [ -n '' ]
+ [ -f /var/run/dhcp6c.pid ]
+ [ -f /var/run/dhcp6c.pid ]
+ /usr/bin/logger -t dhcp6c 'RTSOLD script - Starting dhcp6c daemon'
+ /usr/local/sbin/dhcp6c -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid -D
If that works, and you see dhcp6c running, the question is why isn't it starting automatically.  If that doesn't work then you might have to look through logs to see if there are any errors logged.  Perhaps somehow there is something invalid in the dhcp6c config file for example.

Create an issue on GitHub: https://github.com/opnsense/plugins/issues

It looks like the widget might be using the wrong attribute from the Tailscale status info but the JSON structure isn't very well documented that I can see.

PR created, for reference: https://github.com/opnsense/plugins/pull/4490

From a quick read of the code and confirming with my dashboard, it looks as if the interface statistics widget is sorted by total packets, descending, and the interfaces widget is just presented in the order displayed by ifconfig.  Whether they should/will change is not for me to say of course, just thought I'd answer the question of what the current order actually is.

Edit: I noticed OP is right about the descending order by interface name if the statistics widget is showing a table - the packet count descending order is for the pie chart legend, perhaps that's ordered that way to improve how the pie chart looks, or something.

I don't use a custom headscale server but I think I was able to reproduce the problem of bootup stalling by just trying a fake headscale URL.  I found a crude workaround, you could see if it works for you, if you're comfortable checking code from a random stranger on the Internet is safe to use - it's a very small change: https://github.com/bensmithurst/opnsense-plugins/commit/0cbcf2d54412e2899348083ee46dd3d198e6ea3c

Code Select Expand

curl https://github.com/bensmithurst/opnsense-plugins/commit/0cbcf2d54412e2899348083ee46dd3d198e6ea3c.patch > tailscale-timeout.patch
patch -d /usr/local -p4 < tailscale-timeout.patch

Go to tailscale > settings in the UI and press apply to make it re-generate the config.  You should see the change in /etc/rc.conf.d/tailscaled

Code Select Expand

tailscaled_up_args="--timeout=10s .....

Then reboot and see if it works as expected.  This should make 'tailscale up' give up after 10 seconds during bootup and not stall completely.  If that works, it at least gives an idea of what a proper fix for the plugin might be (e.g. maybe something like I've done but made into a config option).

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