pfSense 2.5.1 not recognizing my default ipv4 route

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.

jimp

You are aware the issue linked upthread has a committed fix already which addresses the problem? We didn't have any problem solving it, there just hasn't been a release including the fix yet.

https://redmine.pfsense.org/issues/11806

You can apply the commit there with the system patches package if you need to use IPv4 link local gateways.