Regression #16331
closed
25.07 RC - no default gateway being set if default route is set to a gateway group and the Tier 1 member interface is down
0%
Description
With 25.07 so close I wanted to get this issue opened ASAP. Sorry for being a bit light on details—I'm collecting info still.
On my home 6100 that I factory erased and formatted with a fresh 25.07RC via Netgate installer (25.07.r.20250715.1733) I am having a bad situation occur where the default route (0.0.0.0/0) gets removed if the link drops (no carrier) on my WAN. This includes during operation, or at boot-time. The default route is not replaced by anything, thus breaking just about everything.
I thought it might have been because I have a S2S Wireguard tunnel that uses Policy Based Routing and has a Peer with "Allowed IPs" set to 0.0.0.0/0 but I tried disabling that peer and the behavior continued. I have tried rebooting a few times to be sure this wasn't a one-off.
If I manually go to System > Routing and choose a specific V4 gateway (my Tier2) then things start to work again.
Similarly, if I ssh in and type
route add default <ip_of_my_tier2_gw>
That gets things working temporarily as well. My setup is FIOS via a 10Gtek SFP+ adapter on ix0 as Tier1 (DHCP+DHCP6), a Teltonika RUTX11 as my Tier2 WAN on ix2 (RJ45) and LAN on ix1 (another SFP+ to a Unifi 10G switch). Packages installed currently are:
- acme
- arping
- aws-wizard
- Backup
- Cron
- Filer
- iperf
- ipsec-profile-wizard
- mDNS-Bridge
- Netgate_Firmware_Upgrade
- Nexus
- pfBlockerNG
- Shellcmd
- softflowd
- sudo
- System_Patches
- Tailscale
- WireGuard
I have a couple of status_output.tgz debug archives collected before and immediately after a reboot. Happy to send those off to whoever @netgate to help troubleshoot this, or any other sort of troubleshooting. I'm surprised nobody else has hit this during the beta testing.
Files
Updated by → luckman212 3 months ago
Here's a screenshot I took of the System > Routing > Gateways after booting up and experiencing this bug
Updated by → luckman212 3 months ago
Updated by Marcos M 3 months ago
- Project changed from pfSense Plus to pfSense
- Category changed from Gateways to Gateways
- Status changed from New to Not a Bug
- Priority changed from High to Normal
- Affected Plus Version deleted (
25.07) - Affected Architecture deleted (
6100)
I've done some troubleshooting on this and there doesn't appear to be a bug here. The issue ultimately stems from using the option to not add static routes for the monitoring address. The following are details from my testing:
When the WAN1 interface is detached the OS removes the default route since the gateway address is no longer reachable via any route. Once the route is removed, dpinger can't reach the monitoring address and starts getting the sendto error; this also means pf can't force the traffic out the correct gateway with route-to. I found various ways to trigger the issue but could not think of any workarounds that wouldn't be prone to race conditions. That leads me to the conclusion that the option "Do not add static route for gateway monitor IP address via the chosen interface" must not be checked for multi-WAN configurations that rely on gateway failover or recovery.
Updated by → luckman212 3 months ago
There's a knock-on bug that I believe is related to this, I'll open a separate redmine for it as I was at work all day today and couldn't collect all the details yet. Static routes (and states) are not being removed when the monitor IPs are changed. I tested this with the pfSense_kill_states() function and setup_gateways_monitor()