OpenVPN fails with 2.50
-
@nicole4pt said in OpenVPN fails with 2.50:
So some backward compatibility seems missing
Quite possible... I get it people don't like downtime and change.. But your version of openvpnas is couple years old - you know how many security fixes have been included.. Why would you not spin up 2.8.7 which is current vs 2.8.5?
-
This is why I hate forums for asking questions. (or is it just because I'm a woman?)
So far no real help ... no providing configs... and just why don't you have the latest and greatest. How dare you. How about you ask Debian and Digital Ocean why they provide it. Maybe because as with PFS 2.5 all thats new is not always better and as usual with upgrades it seems to always break something and demand other upgrades on down the line. :((It's also one of the reasons I have moved away from FreeBSD for a number of things. They force an upgrades on production servers or you risk never being able to find an older package or even upgrade it if you're not fast enough. Their long term support is exceptionally minimal these days)
2.5 Breaking something like backward compatibility with things like OpenVPN is going to ruin a lot of peoples day the hard way. Especially since there seems to be no warning about... yet. I wonder if anything in 2.5.1-RC addresses this?
-
Why don't you post your configs?
As you saw updating your AS its working. Your welcome...
My stuff is current - like I said never had any issues moving up in versions of AS as they came out, and moving up to new versions of openvpn in pfsense as it was updated. Because I stayed current..
But now your all ticked that you updated one side and it broke because the other side is antiquated.. ?? That is somehow pfsense problem?
-
@johnpoz
Exactly. When you asked why was I using older versions of OpenVPNas, you just made the case for why people do not upgrade.BSD has developed a bad reputation for breaking backward compatibility in the name of forced security.
Sadly for things like PfSense it creates unannounced breakage. Which doesn't help it.
I'm glad you are current on everything. However in a production environment and known issues of upgrading, many people will not be able to spend the time and possible downtime will likely wind up here for when they finally do, hoping for a, well it won't work, or help. But seriously, not, works for me, sucks for you.
-
@nicole4pt said in OpenVPN fails with 2.50:
So some backward compatibility seems missing.
pfSense didn't invent the VPN part, the OpenVPN part (they somewhat did so with WireGaurd)
About the compatibility, I guess OpenVPN as a whole is as complex as is pfSense.
Both have one point in common : the backwards compatibility comes after... security.
So, yeah, check out the FAQ and manuals about the 2.5.0 (identical version number - it's 2.5.1 already) : they did, for example, remove old crypto stuff that's known to be weak now. Another aspect is : a tunnel was always over IPv4. That fades out now, as it could also be IPv6. So 'config option' get renamed, added, removed.Also, VPN access has become very important for a lot of people since March 2020.
If companies wanted easy-of-use first, they would have stayed also with XP - or, as some are still doing, use Win 7 - and RDP - on both sides.@nicole4pt said in OpenVPN fails with 2.50:
BSD has developed a bad reputation for breaking backward compatibility in the name of forced security.
Yep, and glad I does. BSD is also known as the "OS" with one of the best network stacks. That's why its used for pfSense (also, true ;) for legacy reasons - but changes the OS is like creating a new product).
@nicole4pt said in OpenVPN fails with 2.50:
I'm glad you are current on everything
Because he (@johnpoz ) is probably both the OpenVPN admin and OpenVPN (road warrior) user, so he is using the OpenVPN desktop traybar tool tool that shows the client- log- connecting-to-the-server initial phase. This small log windows is not some gadget, but part of the security process.
As soon as there are red "depreciated" lines, he translates that to "not- appreciated", no need for a science background that make that translation, and acts upon it, so the client follows the VPN server version number.An OpenVPN basic end user should have a "what to do" list which stated that if these "depreciated" show up, the log should be Ctrl-C Ctrl-V and mailed to the vpn administrator, so a teamviewer session can be planned so the admin can update the client when he see fits.
-
Hmm, it might very well be the backwards compatibility is an issue, but then again as in my situation it is implemented from pfSense to pfSense and both are on the same latest level, then imho compatibility shouldn't be such an issue.
And, to get back on topic (please), there are strange things seen and reported here by others and myself in this topic, where the jury is still out if it's configuration related... -
@bennyc said in OpenVPN fails with 2.50:
Hmm, it might very well be the backwards compatibility is an issue, but then again as in my situation it is implemented from pfSense to pfSense and both are on the same latest level, then imho compatibility shouldn't be such an issue.
I agree, pfSense to pfSense, 2.5.0 to 2.5.0, identical settings, from client to server, should work.
topic
@jknott said in OpenVPN fails with 2.50:
@bleeuw said in OpenVPN fails with 2.50:
So, there must be some change of behaviour since 2.5.0 as JKnott detailed described already.
As described above, my problem was not caused by OpenVPN. For some reason, I couldn't connect when using my 2nd IPv4 address, though I could if I tethered through my cell phone. This also affected ssh.
The topic title "OpenVPN fails with 2.50 " was wrong.
The initial poster had issues that didn't start with OpenVPN. -
True, though he didn't know that initially because it affected openvpn functionality.
Can we agree on the fact there is an issue? (even though it isn't pinned yet to a specific item? )
I have the feeling it doesn't affect a lot of people, otherwise there would be more noise here in the forum. (or it is yet to come)
I also don't see yet how to start troubleshooting this, as I only see limited side-effects in my situation... (All hints welcome) -
For anyone who might be interested (after running into the OpenVPN issues i experienced with multiple customer after upgrading both our customers and our own pfSense boxes to 2.5.0:
All the OpenVPN related issues dissappeared "like snow in the sun" after upgrading to 2.5.1 !!
(So, @bennyc i think we can agree that there was an issue... ;) )However.... a big advice to those who have multiple WAN-connections (wether or not using load-balancing or fail-over mechanism's...) before upgrading to 2.5.1: do not upgrade!!!
Those customers we have with multiple WAN's had serious connectivity-issues (not only over VPN but also from/to the internet) after upgrading from 2.5.0 to 2.5.1!Rightnow i don't have the time (or desire) to look into this new introduced issue in 2.5.1... i'll just wait for the next patch or major update and have another go with upgrading a multi-WAN customer....
Cheers.
-
Hi, well I just did a 2.4.4 upgrade to 2.5.2 and Openvpn no longer works!
In my setup, I was in version 2.4.4 for multiple sites. I upgraded the site that has the VPN SERVERS setup, and the remote VPN's (still on 2.4.4) continued to work normally, even after re-boots.
As soon as I upgraded one of the REMOTE sites to 2.5.2, they stop working! Configs exactly the same. I did FRESH installs of 2.5.2, then simply had the new install grab my backup config file off of USB.
So this must have something to do with the CLIENT side of OPENVPN if the SERVER side updates to 2.5 without issue.
I will also note that the new install in the remote location would not allow any access to the internet either, so its like DNS or Routing of something is broken as well. ???
So, an upgrade to 2.5.2 may NOT correct these issues as I am seeing them.
MP
-
@mrpushner yeah with the update to openvpn 2.5, and all the other changes around openvpn in 2.5, 2.5.1 and 2.5.2 pfsense I would think that depending on your configuration it would be possible to run into a problem.
I could see an issue with cipher selection maybe. When updating either end of the connection it most likely behooves everyone to do a sanity check of the configs on both ends and make sure they are inline with changes..
I ran into no issues with my clients connecting to the openvpn once updated. But I had been using the ncp stuff and had disabled compression, etc. etc. long before..
But my config overall is pretty generic - so it is quite possible that there are issues to be had depending on use case, etc.
With all the possible configuration combinations available, and different clients etc.. I wouldn't expect there not be some sort of issues for some users.
I can see how this could cause issues for some users, but overall it seems understandable that there could be issues with some configurations.
I had a somewhat similar issue with update of freerad package a while back, where stopped working - but the problem was my config was not really sane, and only reason it was working is an issue with the package. On update and that issue being corrected it broke my setup because well I was doing it wrong ;) hehehe
Not saying your doing anything wrong, and that it shouldn't work on update - just that if you run into issue when updating either side of something like openvpn. Good idea to do a sanity check on both server and client configs and make sure everything is in alignment.
-
@johnpoz Ok, so I got this fixed. My older install only had a single Data Encryption Algorithms listed under the client side. The new had a bunch listed by default for some reason.
I made the new match the old and this appears to have corrected the issue, as the VPN's are working again.
Note that my REMOTE VPN's continued to work, only my PEER-PEER VPN's stopped working.
MP
