pfSense 2.5.1 not recognizing my default ipv4 route
-
@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?
-
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.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@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.
-
-
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.
-
This post is deleted! -
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.
-
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.
-
This post is deleted! -
@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.
-
@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.
-
@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 responseTo 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.
-
@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. -
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.
