Regression #11433
closedGateways with "Use non-local gateway" set are not added to routing table
0%
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
Updated by Jim Pingle almost 4 years ago
- 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.
Updated by Daniel Berteaud almost 4 years ago
Attached is a screenshot of my VM during boot. Not sure if it's a symptom or a consequence of the default route missing
Updated by M Felden almost 4 years ago
- File pfsa-1.JPG pfsa-1.JPG added
- File pfsb-1.JPG pfsb-1.JPG added
- File pfsc-1.JPG pfsc-1.JPG added
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
Updated by Daniel Berteaud almost 4 years ago
Indeed, forgot to mention I'm assigning a static /32 IPv4 on my WAN interface, not with DHCP
Updated by Viktor Gurov almost 4 years ago
Updated by Renato Botelho almost 4 years ago
- Status changed from New to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Updated by Daniel Berteaud almost 4 years ago
Can confirm it fixes the issue for me :-)
Updated by Renato Botelho almost 4 years ago
- Status changed from Feedback to Waiting on Merge
Updated by Jim Pingle almost 4 years ago
This could also be related to #11450 since it uses that function in this way
Updated by Tácio Andrade almost 4 years ago
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.
Updated by Renato Botelho almost 4 years ago
- Status changed from Waiting on Merge to Feedback
- Target version changed from CE-Next to 2.5.1
Cherry picked to 2.5.0
Updated by Jim Pingle over 3 years ago
- 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.
Updated by Viktor Gurov over 3 years ago
- 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
Updated by Andrew Murray over 3 years ago
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.
Updated by Frank Soyer over 3 years ago
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.
Updated by Renato Botelho over 3 years ago
Frank Soyer wrote:
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.
You can apply the patch https://github.com/pfsense/pfsense/commit/a97987a5d1df8219f40433270fce0e3ef49345dc, which fixed this issue, using System Patches package as described at https://docs.netgate.com/pfsense/en/latest/development/system-patches.html
Updated by Frank Soyer over 3 years ago
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.