pfSense 2.5.1 not recognizing my default ipv4 route

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 :

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 :)

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:

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.

brianj2k

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

@brianj2k said in pfSense 2.5.1 not recognizing my default ipv4 route:
@gertjan I know this is a delayed response
To what question ?

To your response to the original poster... I thought that was obvious...

@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.

I find this to be an odd response. I do lots of development without the assistance, or knowledge, of my ISP. I think you may be a bit naive to think that every developer has access at that level to their ISP.

Gertjan

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

I think you may be a bit naive to think that every developer has access at that level to their ISP.

I didn't say that. It's the other way around ;)
A pfSense developer would 'code around' the situation when it happens to his connection => issue solved - no need to contact the ISP.

Still, in this special case , I maintain my position : if an ISP really assigns a https://en.wikipedia.org/wiki/Link-local_address I would contact its client service just ones : to say 'good bye', as it's plain broken.
And that's a language every ISP will understand.