Messages

Patch 26.7.1_1 fixes this issue

Note that due to 26.7.1(_1) not rebooting you need to restart the "Gateway Watcher" service to apply the fix.  It also has to be _1 specifically. .1 doesn't have the fix.

I also confirm that 26.7.1_1 fixes this issue, thanks Franco !

Similar issue, most likely related to ours, reported here: https://forum.opnsense.org/index.php?topic=52454.0

This seems to be similar to what we're experiencing here: https://forum.opnsense.org/index.php?topic=52470.0 we also have a non working default gateway (default route is not pointing to the right gateway or not there at all even though WAN is up and working). We're having this especially during HA failover.

Going in gateways (without changing anything in the gateways) and clicking simply apply fixes the routes and puts the right gateway so I guess it is likely calling configctl interface routes configure in the backend

Same situation here since 26.7 and 26.7.1 also didn't fix it for me either.

I have a very similar setup as niei and I also triple checked all my gateways configs. Nothing changed since 26.7, the configs remained as they should be and worked well before 26.7.

When I fail over, I end up with a bad default gateway and no internet access. As if the default gateway isn't being configured anymore when the WAN comes back up after HA failover and you end up with an UP WAN link but without the default gateway pointing to it in the routing table so no internet access.

For now, the only workaround I found to fix this without playing manually with the routing table is: I have to manually (after a failover) go in System, Gateways, Configuration and (without changing anything) I simply click Apply and the routing table updates and the default gateway is corrected. If I don't do this, it will not fix itself.

This isn't super easy to explain, sorry, but this is a major issue.

Hi All,

I'm trying to connect my dual-nic OpenSense x64 Windows 11 box running 25.7 to my ISP using PPPoE.  I know the user ID, password, and VLAN are correct as they work on my Asus BT10 but, I keep failing to connect directly with OpnSense despite being told it's easy.  I've tried MAC cloning and without, although that's not required on my BT10 router.

I've tried the official directions but these get vague around the end and I can't get them to work.   I've also tried this and filed https://forum.opnsense.org/index.php?topic=21207.0.

I've followed the instructions sent to me in DM on Reddit and still failed.

Any ideas, please?

You were close.

You create a vlan device and assign it to the network interface (you did that), you then create a PPPoE device and you assign it to the vlan device (you also did that), you then assign the WAN interface to the PPPoE device (not the network interface, I believe this is were you made a mistake according to your screenshots).

The WAN interface should be assigned to the PPPoE device, not the network interface or vlan, the PPPoE device will do this by itself.

Let me know if that works or not. I also use PPPoE over a vlan. Actually, I use a redundant (CARP) opnsense setup and the primary does not need to tag the vlan since the switch does the tagging but the backup needs to tag the vlan by itself since it's connected to a trunk port so I'm setup for both cases and it works well.

Can you open a ticket for that?

Sure thing, sorry I couldn't do it sooner, here it is: https://github.com/opnsense/core/issues/9227

Also, after re-reading your comment, I wasn't too sure (lol) if it was about that I reported regarding CARP and auto-collect of interfaces IP instead of VIP or the other thing I was talking about (DHCP Option 121 which I cannot fix versus the VIP one that I can fix) so I created another issue for the VIP/Auto-collect in case this is the one you wanted: https://github.com/opnsense/core/issues/9228

Can you open a ticket for that?

Hey franco, I hope you're doing well, long time no chat.

Sure thing, sorry I couldn't do it sooner, here it is: https://github.com/opnsense/core/issues/9227

Let me know if you need anything more.

Thanks

FYI, I also had to disable auto collect and manually fill in the gateway, DNS and NTP for my 5 networks since I'm setup in HA and it was using the interfaces IP instead of the CARP VIP.

Every time there was a failover, everything was losing connectivity because the gateway and DNS were not working anymore since they were pointing to the interface that was down or rebooting instead of the CARP VIP.

I'm not really considering this a "bug" but more of a "heads up" if you use HA and CARP VIP.

The biggest problem I still have with kea is that I cannot send option 121 anymore, the UI doesn't support it (classless static routes, not the static routes in the UI that no client supports or nobody uses that is only 1 IP to 1 Gateway which is option 33). I had a thread on that issue a long time ago and that is problematic a lot for me: https://forum.opnsense.org/index.php?topic=39563.0

I have two networks defined in the UniFi controller, one for the main subnet and another for a VLAN subnet (to isolate IOT devices).

After the 24.7.1 upgrade, nothing on either wi-fi network can reach the internet.  Wired connections are fine.

I can't spare the network downtime to troubleshoot it right now, so I reverted to 24.7 and reloaded the same configuration, and everything works again.  If anyone has any thoughts, it'd be welcome for when I can look at it.

Not sure if related or not but I had a similar issue that was caused by Unbound not able to start anymore. I was caused by my Google Home generating a IPv6 network temporarily during opnsense reboot. Once opnsense had rebooted, I saw a ULA IPv6 address on my Google Home IoT network assigned to opnsense (interface / overview). This happens even though this interface IPv6 configuration is "None". This feels related to SLAAC which is impossible to disable it seems.

For some reason, that prevented Unbound from being able to start (I'm binding Unbound to specific interfaces, not ALL as they recommend). When that happens, there are a few things I can do

- Manually remove the ULA IPv6 in command line from the Interface where my Google homes are (it usually doesn't come back once they have internet access, I suppose they do this to talk to each other temporarily during outage)
- Enable dhcpv6 on the interface, save/apply. Re-disable IPv6 (set it back to none), save/apply. (This makes the IPv6 ULA go away and Unbound is now able to start)
- Remove specific interface binding from Unbound so it binds to everything, for some reason this makes Unbound able to start even with this problem.

This is reproducible every time I reboot opnsense and only happens on my Google Home interface (which is linked to Unifi Access points which have their own SSID for my Google Homes).

Next time you upgrade or reinstall, run ifconfig in command line or check in interfaces/overview to see if you don't have an IPv6 on an interface that shouldn't be there and check is Unbound is running or not. You should have IP address access to everything even without DNS running (to access opnsense UI or command line or even ping 8.8.8.8)

Like I said... Could be related or not to your issue but this is my case since the last few updates and I thought I could share in case it helps.

https://github.com/opnsense/core/commit/287c13beb

# opnsense-patch 287c13beb

That seems to have helped for Starlink, problem remains to Hurricane Electric GIF tunnel.

I patched, and rebooted 2 times and both times the dpinger for Starlink was up and monitoring. I removed the patch, rebooted a 3rd time and I saw dpinger started on startup and then stopped and did not restart by itself. I then proceeded to enable manually and it remained up.

I wonder if this could also be related to a problem I started having on 24.1 in the very latest updates. After reboot I see a weird IPv6 assigned to the interface (ULA fd9c:xxxxxxxx) where I have my Google Homes. As if the interface would get itself an IPv6 from somewhere. The IPv6 configuration on the interface is "None" so I would not expect the interface to end up having an IPv6 in any way, ever. I wonder if something like SLAAC is enabled at all times now or something like that even though IPv6 is not enabled on the interface.

I need to manually remove the ULA IPv6 from the interface or put the interface in DHCPv6, save/apply, then go back to None and save/apply to get rid of the IPv6 address on the interface. This situation also prevents Unbound from starting, it remains off until I get rid of this IPv6 or remove the interface from the Unbound list of bounded interfaces.

I know this sounds like outside this thread but since it affects IPv6 only and we're talking about weird SLAAC issues, I prefer to let you know about this as well in case it is related or it helps.

EDIT1: Added info to specify that the weird IPv6 I'm getting in an interface is FD9C:xxx which is a ULA IPv6, probably some device created its own ipv6 network and is broadcasting it. Not sure why OpnSense uses it though since I have IPV6 configured to none on the interface. But this definitely prevents Unbound from starting.

EDIT2: It really seems like it is a RA coming from my Google Home devices or Unifi AP maybe and opnsense picks it up by autoconf. Something must have changed recently (likely kernel) that now autoconf ipv6 even if disabled.

Code Select Expand

inet6 fd9c:85da:835d:8696:92e2:baff:feb0:efeb prefixlen 64 detached autoconf pltime 1800 vltime 1800

I use 2 providers for IPv6

Starlink (DHCPv6) and Hurricane Electric (GIF tunnel).

After reboot, I have an IPv6 on both interface but gateway monitoring (dpinger) is not enabled on any of the ipv6 interfaces so both interfaces are marked as down. All IPv4 gateways are ok and dpinger is running for them, only IPv6 are affected.

I can manually start dpinger on both gatways and then they get marked as up and dpinger continues to run.

If I reboot, the same situation happens again. It also happens if I go on the interface of Starlink and click save to refresh IPs. Seems dpinger gets disabled while the interface flaps but it never gets re-enabled automatically unless I manually start it.

This is a new behaviour since I upgraded to 24.7, this was working fine in 24.1

This is not a bug or problem, this is basically just a FYI...

Careful, I made the mistake of thinking that this 24.1.4 release note was DHCP option 121 to send static routes to dhcp clients (I need this option before moving to kea) but it is not.

Code Select Expand

o kea-dhcp: add domain-search, time-servers and static-routes client options to subnet configuration


It's DHCP option 33, which is a single IP to a router IP. You cannot use this to route 192.168.30.0/24 to 192.168.31.1 for instance. You can only route 1 ip to a router, like 192.168.30.12 to 192.168.31.1 for instance.

This is basic and can still serve some purpose for some people but most of us use DHCP option 121 in ISC which is totally different than the less used DHCP option 33 which basically enforce /32 on your static route because you cannot define a subnet/CIDR on the IP/network you pass.

In other words, what we likely want, is the support for this KEA feature in OPNSense (DHCP option 121) which encompass and overrides when it is present (per RFC) option 33. Option 121 also enables you to do exactly the same as option 33 since you can specify /32 on a subnet if you want but the important part is that it allows you to specify subnets, not only individual IP addresses to be routed to a router.

https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2135/diffs

Now, since this has been implemented like that. This will likely create a breaking change when option 121 is implemented unless the upgrade process converts what was specified as ip,router to ip/32,router so that we can keep the same field for the better DHCP option 121 without breaking the kea config for people that started using it already in the option 33 format. Unless someone decides to support both options in the UI and configs and then we would have 2 separate fields for static routes in the kea UI. One for single IPs (DHCP option 33) and another one for networks (DHCP option 121)

I'm very glad that a lot of work is being done on KEA and I'm almost to the point of being able to move away from ISC. Once Option 121 is implemented in OPNSense and that KEA also registers its DHCP leases hosts in Unbound, I'll be good to migrate.

Thanks everyone !

Problem is still present in 24.1.2

Bad state

Code Select Expand

No ALTQ support in kernel
ALTQ related functions disabled
all icmp 100.79.101.92:33064 -> 1.1.1.1:33064       0:0
   age 08:41:39, expires in 00:00:10, 30734:0 pkts, 891286:0 bytes, rule 104
   id: d928da6500000003 creatorid: d7e1a47d gateway: 192.168.100.1
   origif: igb0

Killing it

Code Select Expand

root@opnsense:~ # pfctl -k id -k d928da6500000003
killed 1 states

State is now back to what it should and gateway is now recovering

Code Select Expand

root@opnsense:~ # pfctl -ss -vvv | grep "1\.1\.1\.1" -A 3
No ALTQ support in kernel
ALTQ related functions disabled
all icmp 100.79.101.92:33064 -> 1.1.1.1:33064       0:0
   age 00:00:05, expires in 00:00:09, 5:5 pkts, 145:145 bytes, rule 104
   id: 7698db6500000002 creatorid: d7e1a47d gateway: 100.64.0.1
   origif: igb0

It seems to me this is still an unresolved issue.  I have disabled ISC on all but one interface and migrated the rest to Kea.  For this to work, I found I had to stop ISC entirely, restart Kea, then restart ISC.  Otherwise, the Kea log reports "Address already in use - is another DHCP server running?" errors.  If I then have to reboot opnsense (e.g. after firmware updates), it seems ISC will start before Kea and I will not have DHCP servers active on any of the interfaces except the one that I still have on ISC (Kea will report "address already in use" for the other interfaces).

Is the intent for now to support running ISC on some interfaces and Kea on others or are uses expected to migrate all interfaces to Kea?

This is my experience, it is impossible to run both. franco also confirmed this earlier. ISC gets a hold of all interfaces and prevents KEA from binding to it, as you saw.

In my case, kea was missing too many features that I need before migrating (dhcp custom options for additional routes and also unbound DNS registration) which I rely on heavily thus preventing me from migrating the subnets that I could right away and keep the others on ISC.

For now, it's unfortunately all or nothing, not because of kea, but because ISC bind to all IPs as the output for sockstat shows and from what I read on ISC, it seems to be by design.

Kea however worked well in my case when I tested but unfortunately is missing too many things for me to migrate, yet.