pfSense 2.5.1 not recognizing my default ipv4 route

[intellq]

I upgraded today my pfSense from 2.5.0 to 2.5.1.

Now it doesn't add a default route anymore.

My connection is ppoe, and my ISP uses 169.254.0.2 as their gateway (don't ask me why). This IP doesn't respond to pings either.

In 2.5.0 I checked both "Disable Gateway Monitoring" and "Disable Gateway Monitoring Action" for this gateway, and the default route was added.

But not anymore.

I had to create a script, and execute it each 2 minutes inside crontab (in case of reconnects), otherwise I can't ping anything, 1.1.1.1, 8.8.8.8, etc (even inside pfsense shell)

#!/bin/sh
if ! netstat -r4|grep default>nul
then
route add default 169.254.0.2
else
echo Route is ok. Nothing to do.
fi

btw, now when pfSense starts there's a new error, since 2.5.1 upgrade:

login-to-view

This is a new bug introduced by 2.5.1? Any tips/recommendations?

Thanks in advance.

[Gertjan]

@intellq said in pfSense 2.5.1 not recognizing my default ipv4 route:

and my ISP uses 169.254.0.2 as their gateway

Incredible.
Was this know up front ?
This IP (network) has it's own wiki page, and it learns you one thing : if you see this IP, : run away.
Or, as a pfSense admin, resolve the issue.

Normally, for a WAN interface, this is checked :

login-to-view 169.254

Now guess what ? The "169.254.0.0/16" network is part of the bogons list ! As these IP addresses that are not routable, they should be "not used".

login-to-view

Let's face it : your ISP isn't compatible with pfSense. It isn't compatible.with the thing called "Internet".

@intellq said in pfSense 2.5.1 not recognizing my default ipv4 route:

This is a new bug introduced by 2.5.1? Any tips/recommendations?

Not a bug.

Are you sure your ISP is attributing you this IP ?
DHCP client attributes this IP to themselves when they can't get an IP from the upstream DHCP server.
It signals that something went wrong during DHCP negotiation.

@intellq said in pfSense 2.5.1 not recognizing my default ipv4 route:

This IP doesn't respond to pings either.

You can set it up to use another IP.

[intellq]

@gertjan said in pfSense 2.5.1 not recognizing my default ipv4 route:

Incredible.
Was this know up front ?
This IP (network) has it's own wiki page, and it learns you one thing : if you see this IP, : run away.
Or, as a pfSense admin, resolve the issue.

Normally, for a WAN interface, this is checked :

login-to-view

Both "Block private networks and loopback addresses" and "Block bogon networks" are unchecked.

169.254

Now guess what ? The "169.254.0.0/16" network is part of the bogons list ! As these IP addresses that are not routable, they should be "not used".

Let's face it : your ISP isn't compatible with pfSense. It isn't compatible.with the thing called "Internet".

Not a bug.

I know my ISP is doing lame things, nothing I can do about it. But even using this range 169.254 as a gateway to my pppoe, in 2.5.0 it was working.

That's what I want to know, if there's something I can do to revert back to the previous behaviour.

Are you sure your ISP is attributing you this IP ?

Pretty damn sure :)

login-to-view

pFsense 2.5.1 does everything right, except for adding this ip (169.254.0.2) as a default route, like 2.5.0 was doing.

Manually adding via crontab or command line works, but is far from ideal (they may change the ip and I'll have to update the script, for example)

[jimp]

I wonder if it might be related to the changes on https://redmine.pfsense.org/issues/11713

The % is a tell-tale sign it's trying to consider that an IPv6 link-local route, when it's an IPv4 link-local address.

You could try this change to see if it helps:

diff --git a/src/etc/inc/util.inc b/src/etc/inc/util.inc
index c330e3a22d..c3973b1b47 100644
--- a/src/etc/inc/util.inc
+++ b/src/etc/inc/util.inc
@@ -2848,7 +2848,7 @@ function route_add_or_change($target, $gw, $iface = '', $args = '',
        if (is_ipaddr($gw)) {
                /* set correct linklocal gateway address,
                 * see https://redmine.pfsense.org/issues/11713 */
-               if (is_linklocal($gw) && empty(get_ll_scope($gw))) {
+               if (is_ipaddrv6($gw) && is_linklocal($gw) && empty(get_ll_scope($gw))) {
                        $routeget = route_get($gw, 'inet6', true);
                        $gw .= "%" . $routeget[0]['interface-name'];
                }

[slu]

If i understand this right, it's not a good idea to update a remote PPPoE_WAN pfSense from 2.5.0 to 2.5.1 right now?

[jimp]

Has nothing to do with PPPoE or anything like that.

It's because they are using 169.254.x.x as their interface gateway -- that's IPv4 link-local, a special network.

[intellq]

@jimp thanks for your reply.

If I'm understanding correctly, I would have to recompile the code to test the change you suggest?

I'm far from being a FreeBSD expert, and have no idea how to do that. Can you point me in the right direction? :)

[johnpoz]

No need to compile any code.. Its just the change he listed in the util.inc file

You should be able to apply the patch via the patch package..

[intellq]

@johnpoz said in pfSense 2.5.1 not recognizing my default ipv4 route:

No need to compile any code.. Its just the change he listed in the util.inc file

You should be able to apply the patch via the patch package..

Oops :P

I'll try it when I get home.

Thanks guys!

[intellq]

@jimp said in pfSense 2.5.1 not recognizing my default ipv4 route:

I wonder if it might be related to the changes on https://redmine.pfsense.org/issues/11713

The % is a tell-tale sign it's trying to consider that an IPv6 link-local route, when it's an IPv4 link-local address.

You could try this change to see if it helps:

I did the change. New error:

login-to-view

But believe it or not, it's working. The default route is now (again) being deployed.

Leave it that way or any other advice?

[jimp]

Thanks for testing that patch. Those errors should be harmless if it's working otherwise.

I opened https://redmine.pfsense.org/issues/11806 so we can look into this deeper now that we have all the info together.

[Gertjan]

@intellq said in pfSense 2.5.1 not recognizing my default ipv4 route:

New error:

More like "the next error".
Because WAN is up and running, OpenVPN can actually start and find an environment where it can do something useful.
One of the conditions is of course a working WAN.

"The route has not been found" message itself is pretty harmless.

[intellq]

@jimp thanks for all the help. And the description you wrote when creating the issue was pretty accurate.

@Gertjan thankfully a solution was found. All I can ask for :)

[Lanna]

@jimp

Hello, I recently upgraded a couple of boxes and this appears to have broken some site-to-site VPN connections. I gave the above edit a try but it didn't fix anything for me. I note the following fix described in the 2.5.1 release blog post. . .

• Interface and routing issues which in certain cases could lead to problems with responding to requests from non-default WANs, problems determining gateways, configuring routes, and route lookups

Could you please further describe these changes and how I might roll them back somehow to get these site to site issues nailed down because it's causing me quite a headache. The problem in my case is that NATted connections into one pfSense box, routed through the tunnel to the other pfSense box, fail to get a reply now. I've not found a way to fix this. I considered going back to 2.5.0 but what would be involved in that is even more onerous than the situation I'm facing now with these lost packets. To be more specific, any incoming OpenVPN client connection NATted via the remote pfSsense box fails, with state of:

NO_TRAFFIC:SINGLE

and VPN log of :
TLS Error: incoming packet authentication failed from [AF_INET]

If the client tries to connect to the local pfSense box directly, the connection succeeds. However, this is not sustainable due to local box not having static IP.

It is noteworthy that we have 3 WANS and multiple OpenVPN instances. All OpenVPN servers are running on localhost so we can utilise all WANs for incoming connections.

[Lanna]

This post is deleted!

[Lanna]

Actually my network is just unravelling completely, I need to roll back to 2.5.0 but I can't find anywhere to download it on the site. I read that Netgate have intentionally stopped making older versions available. This is proving disastrous for me and I can't find the version on my HDD anywhere. I urge you to reconsider this move, I desperately need to install 2.5.0 and get back to where I was.

EDIT: It looks like my issues is related directly to Regression #11805. I humbly and without shame beg for a manual instruction on a fix.

[Lanna]

For anyone else in despair like me, here is what'll save you. 2.5.0 is still on the official mirror here. . .
https://sgpfiles.netgate.com/mirror/downloads/

Get it fast before they pull the rug.

[sananibrahimoff]

This post is deleted!

[brianj2k]

@gertjan I know this is a delayed response, but do you believe end-users can move their ISPs to make systemic changes because 1 out of a million end-user router vendors has an issue...

I get that this is bad/wrong and that the provider SHOULD make a change, but making pfSense unusable to "solve" the problem is actually more of a pfSense issue. Might want to add a checkbox that enables this to work instead of breaking systems when they upgrade.

[Gertjan]

@brianj2k said in pfSense 2.5.1 not recognizing my default ipv4 route:

@gertjan I know this is a delayed response

To what question ?

@brianj2k said in pfSense 2.5.1 not recognizing my default ipv4 route:

but making pfSense unusable to "solve" the problem is actually more of a pfSense issue.

A developer should have that ISP connection at hand so the situation can get analyzed.