Non-local default gateway via interface broken after updating 2.4.4 to 2.4.4_p1
-
Hello pfSense users,
today I updated both my pfSense vm's to the latest 2.4.4_p1 stable release. One of these vm's is hosted in an OVH datacentre. The WAN interface of this vm uses a WAN IP-address which gateway lies in a completely different subnet. In 2.3 the option to add this through the webinterface was finally added, and has since worked like a dream... Until today. I upgraded to 2.4.4_p1 and was unable to ping 1.1.1.1 or 8.8.8.8 from the pfSense box. Computers in the LAN of this vm could ping both 1.1.1.1 and 8.8.8.8 fine. Strange... Now, when I remove the default route, and the interface specific route, through the shell, and then manually add them again, it works perfectly again. Then I can even apply it through the webinterface again, so all will be saved after reboot, and it still works. Then if I reboot.... stops working again. I can repeat the process and the route works as expected again. Anyone having similar issues? Could anyone provide any assistance?
It does seem that when I add the interface specific route, I can see the route going to /32 subnet. When I reboot after configuring the gateway in the webinterface, I dont see /32 in the route table at all, just the IP-address without subnet.
-
So you have this checked in your Advanced Gateway Options?
-Rico
-
Thanks for the quick reply! Yes most definitely, and I have been using this option ever since it became available in the webinterface.
-
I can confirm the same issue on both online.net and OVH servers. Since 2.4.4-P1, non-local gateway is broken. The pfsense host itself cannot reach the outside world (but the lan can).
Deleting the default route and adding it back again with "route add default <gateway>" is fixing the issue.
-
Glad to finally find someone who is experiencing the same issues. How do you reckon we go about fixing this? Netgate will have to create an issue in the bugtracker I suppose?
-
Report it here: https://redmine.pfsense.org/ with as many details as you can.
-
So when you see this you just get no default route in the routing table?
I assume clients behind the firewall were still able to ping out because you had policy routing rules to direct that? And those were also via the same gateway that's out of subnet?
Steve
-
Yes, clients in the lan could still access the internet, through the same gateway. The default gateway was still present in the webinterface and visible with ‘netstat -rn’. However, when I add the route myself with route add, it shows the route as ‘a.b.c.d/32’ whereas when I add it through the webinterface it omits the subnet. This was the only difference I noticed. This makes it so that after rebooting the pfsense box cant connect to any hosts on the internet anymore, until I remove and add the same exact route through the shell again.
-
Hmm, interesting. What do you have set in the default v4 gateway field in Systen > Routing > Gateways?
There were significant changes in that way that is handled in 2.4.4 and further changes to refine it in p1.
If LAN side clients can still reach out the gateway must still be valid. Or the route is at least...
Steve
-
This route is my default ipv4 gateway. Only settings are literally the IP of the gateway and the non-local gateway tickbox. Nothing else. As I mentioned earlier, Ive used this configuration ever since this checkbox became available. Think that was with 2.4.
*edit: Im in an airport atm so cant check the details of the IP so not sure if you have enough information. Are you looking for anything specific?
-
More what is the actual v4 default gateway field set to that any setting on the gateway in particular.
Whether it's set to that specific gateway rather than 'automatic' or a gateway group.
That was what changed in 2.4.4/p1.
Steve
-
The WAN interface does have this non-local gateway set as the default gateway for the interface.
*edit will confirm later. I cant recall seeing this field in the “system > routing > gateways” menu. And youre right, surely the route is valid because the lan clients can connect... and I can also still connect to clients in the lan over the internet via NAT rules etc
-
Yes, it seems likely this is an edge case in the default route handling that the changes in p1 are adversely effecting.
Steve
-
Hey Steve,
thanks for all the responses so far. So I just found the new setting. The default gateway is set to this non-local gateway, not on automatic or any other route. Makes sense, seeing that when I enter 'netstat -rn' through the it does state this route as being the default aswell.
-
Ok, and that's how it was set already? Still giving the wrong/no subnet mask after reboot?
You might try setting it to
automaticthere. That should work correctky in 2.4.4p1 for local gateways. If that does work it gives us a very good clue where to look to correct the manual setting.Steve
-
Yeah, that was how it was set already. I just changed it to automatic and rebooted, problem is back again so that didnt really do anything at all. I need to install a second pfSense box over here as a failover for my connection to the host, I cant remove and add the default route anymore because I dont have KVM access... This pfSense machine is also router for the physical host in the datacentre, so you understand its a bit of a painful situation like this hehe.
*edit, okay Im an idiot, I can safely readd the default route as long as I just remove it and add it in a single line separated by a semicolon. I changed it back to the the specific gateway and restarted, that didnt help. Removing and readding the default gateway through the shell consistently fixes the issue.
-
Hmm, OK. Thanks for testing that.
-
If theres anything else I can test please let me know. Should I make a write up on redmine and refer to this thread when Im home later? I can imagine not many people will run in to this issue but it does break functionality. The dashboard becomes unbearably slow because it cant resolve hostnames, obviously cant download packages/update information etc
-
Yes, if a report has not yet been filed go ahead and do that.
Steve
-
Registered the issue under https://redmine.pfsense.org/issues/9232. I suppose, if people read this, any support in that issue is welcome. First time I filed a bug for this software so I hope its in order.
