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
-
@luckman212 what a weird way of coding the monitoring.
I had assumed if monitoring was specified for a particular gateway then the monitoring packets would be sent over the monitored interface without implying any other changes to the routing policy.
Similar to when pinging from an interface doesn't imply all routing to that server suddenly also must go through that interface.
-
@Patch said in 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:
I had assumed if monitoring was specified for a particular gateway then the monitoring packets would be sent over the monitored interface without implying any other changes to the routing policy.
Similar to when pinging from an interface doesn't imply all routing to that server suddenly also must go through that interface.
Routing in Unix is IP destination based rather than source based. The way monitor packets are forced out an interface is with a static routing rule that says "If you are sending a packet to this IP address, the packet must be sent out this interface." This means that all packets destined for that IP address will out the interface specified.
-
I saw 25.07 release was published. So I guess this is a moot point for now, as the next major release won't be before 25.11 at the earliest. I will keep monkeying around I guess.
@dennypage if what you wrote is true, then how can you explain the tcpdumps above, when both WAN1 and WAN2 are "up", and I have the "don't create static routes for monitor IPs" option enabled on WAN2, and I see no packets to 8.8.8.8 leaving ix0—they are 100% going out on ix2, confirmed with tcpdump and the 50+ms latency indicative of the 4G connection, and at the same time my default route being via the WAN1/FIOS... ?
-
@luckman212 said in 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:
@dennypage if what you wrote is true, then how can you explain the tcpdumps above, when both WAN1 and WAN2 are "up", and I have the "don't create static routes for monitor IPs" option enabled on WAN2, and I see no packets to 8.8.8.8 leaving ix0—they are 100% going out on ix2, confirmed with tcpdump and the 50+ms latency indicative of the 4G connection, and at the same time my default route being via the WAN1/FIOS... ?
“If what you wrote is true”? Do you think I am lying to you? Really?
Yes, it’s true that Unix uses destination based routing. Yes, it’s true that static routes are required for monitoring Multi-Wan. And monitoring works correctly if you set the static route, yes? QED. I don’t know what else to say.
If it’s important to you to understand the reason for the specific results of the test above, it’s your system so you’ll have to figure it out based on the system state at the time of the test. I’d suggest that you start by examining your routing tables:
netstat -rn -
@luckman212 It works without the option because pf "catches" the traffic before it leaves ix0 - hence my previous comment "pf overrides the OS and sends it over ix2". The reason why pf can't do its job in your case is because the default route goes away; since there's no route for the OS to use for dpinger, you get the sendto error and pf doesn't get the chance to override the path to send it out of ix2.
-
Nobody said anything about lying. I should have phrased it as "Let's assume that FreeBSD routing behaves as you've outlined... in that case, how can I be observing XYZ"
I'm sorry this thread is starting to derail. I appreciate all your help. I am not nor never claimed to have all the answers. Just looking for explanations for the new, unwanted and somewhat unexplainable behavior I am seeing here.
-
@marcosm said:
pf can't do its job in your case is because the default route goes away
So is that still being considered a bug then? I still can't figure out why WAN1 going down (either by way of physically downing the interface by removing the cable, or by dpinger triggering a down event) should cause pfSense to mark the other gateway down and/or remove the default gateway. Feels wrong.
Is the explanation that, WAN1 goes down, and before the system has a chance to set WAN2 as the default gateway, the pings to 8.8.8.8 start failing because "technically" there's no longer or not yet a valid default route to send those packets (pf ignored) - and this causes WAN2 to then go down leaving the box dead as a doornail?
If that's loosely what's going on here, then what about adding a simple option to the routing page something like "Do not remove a default gateway if there are no other online gateways in the group"
-
It seems like a bug to me. Because the WAN2 gateway would remain marked up for a while, even if dpinger starts to lose pings, and should be set as default.
If there was any default route then dpinger would use it and pf would catch and reroute that via WAN2.
It's an interesting issue. I don't think I've ever seen anyone using it without the static route set. I've seen numerous issues with conflicting routes for DNS and dpinger though
But I have always resolved them by simply using a different target or making sure the both use the same gateway. -
Most of that code is script though so it should be patchable.
-
At least there seem to be improvements to be made. I will dig further.
-
and this causes WAN2 to then go down leaving the box dead as a doornail?
Yes.
what about adding a simple option to the routing page something like "Do not remove a default gateway if there are no other online gateways in the group"
When the WAN1 interface is detached the OS removes the (default) route using the gateway within that interface's subnet since the gateway address is no longer reachable. Hence there's not much that pfSense can do/prevent at that point since the default route has already been removed.
Once the route is removed the packet loss percentage starts climbing. However other processes are triggered as part of the interface event which end up restarting dpinger and hence the gateway immediately shows offline. As a test I spent some time patching the various code paths so that the dpinger process would be kept running and allow the packet loss to slowly build up. That didn't help because 1) regardless of dpinger being restarted or kept running it still has the sendto error due to the default gateway being removed by the OS (and hence cannot be forced with route-to by pf), and 2) by the time the new default gateway would be added, the gateway is already marked offline due to packet loss.
I don't know why it worked for you previously. There are a least a couple new related changes that are implemented to prevent the monitoring traffic from going out the wrong interface; perhaps that's part of it or maybe your configuration and environment allows the timing to work out. I did find various ways to trigger the issue while I was testing. Ultimately any workarounds I could think of would be prone to race conditions and hence I don't think it's worth pursuing. That leads me to the conclusion that a correct multi-WAN setup that uses gateway failover/recovery requires the static routes.
-
@marcosm said in 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:
That leads me to the conclusion that a correct multi-WAN setup that uses gateway failover/recovery requires the static routes.
Thanks @marcosm. What do you think about adding a note regarding this to the help text for the “Do not add static route for gateway monitor IP address via the chosen interface” option?
-
@dennypage Yeah. Or just remove them entirely.
