Regression #11433
closed
Gateways with "Use non-local gateway" set are not added to routing table
Added by Daniel Berteaud about 3 years ago.
Updated about 3 years ago.
Description
I'm using a non-local gateway as my default gateway (ticking the "Use non-local gateway through interface specific route" on the gateway advanced settings)
After upgrading from 2.4.5_p1 to 2.5.0, no default gateway is added on boot. I have to manually add it back with
route add x.x.x.x/32 -iface vtnet0
route add default x.x.x.x
Files
- Tracker changed from Bug to Regression
- Target version set to CE-Next
Do you see any errors in the console output while it boots when that happens?
There were numerous changes to gateway handling on 2.5.0 but I'm not aware of anything that would have specifically broken this. It's not very widely used, however, so if the required syntax changed in some way it may have not been updated since nobody complained when using development snapshots.
Attached is a screenshot of my VM during boot. Not sure if it's a symptom or a consequence of the default route missing
I can replicate this!
I was about to respond that this "works for me" because I have a pfSense demo VPS with a cloud provider who gives an IPv4 gateway of 172.31.1.1 when the public IP address is in a totally different subnet. I upgraded this to 2.5.0 today and have had no issues. Then I realized that this instance has WAN set to DHCP4. Perhaps the original report is all static.
Trying to replicate this issue I proceeded to spin up a new instance of 2.4.5 and set a static IPv4 of 95.217.5.253/32 (no need to censor this, its a throwaway) and the gateway as 172.31.1.1 with the option "Use non-local gateway through interface specific route" as reported by Daniel B.
Confirmed it worked in 2.4.5. Rebooted. Still good. Upgraded to 2.5.0-Release and rebooted: No gateway. Instance unreachable as described by the original report. netstat -r shows now IPv4 default route - see attached pfsc-1.JPG
Indeed, forgot to mention I'm assigning a static /32 IPv4 on my WAN interface, not with DHCP
- Status changed from New to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Can confirm it fixes the issue for me :-)
- Status changed from Feedback to Waiting on Merge
This could also be related to #11450 since it uses that function in this way
I am facing the same problem at OVH. After the migration some pfSense stopped the gateway.
I found it strange because I updated 3 pfSense and none of them had this problem, but I realized that it is because the other 3 instead of non-local gateway used the last IP of their network range as a gateway.
- Status changed from Waiting on Merge to Feedback
- Target version changed from CE-Next to 2.5.1
- Subject changed from 2.5.0 breaks non local gateways to Gateways with "Use non-local gateway" set are not added to routing table
Updating subject for release notes.
- Status changed from Feedback to Resolved
works as expected on 2.5.1.r.20210314.2256:
Destination Gateway Flags Netif Expire
...
172.13.13.13 ea:f3:ba:7c:55:4a UHS vtnet0
Viktor Gurov wrote:
works as expected on 2.5.1.r.20210314.2256:
[...]
I tested this with 2.5.1.r.20210314.2256 and confirmed it does work with IP but DNS doesn't resolve even though remote DNS is configured for 1.1.1.1 and 1.0.0.1. I can access these without issue but trying with DNS on pfsense doesn't work.
EDIT: Setting the default gateway to a specific one instead of automatic, solved the problem.
Hi guys,
I'm just facing this bug after an update to 2.5.0. Unfortunatly, gitlab.netgate.com is actually OFF, I can't see the fix, and I not really want to fully re-install a RC. I can revert to 2.4.5 for the moment, no matter, but can someone tell me when a stable 2.5.1 (if it fix this) will be available ? Or point me to a roadmap, somewhere ? Thanks.
Hi Renato,
the only patch (pfSense-pkg-System_Patches: 1.2_5) shown in the UI does not correct the problem. It seems that a "2.5.1" patch isn't yet available.
But modifying the line manually did the trick, thanks a lot.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Viktor Gurov 
Updated by 
Updated by 
Updated by 
Updated by 
