OpenVPN not working after 2.5 upgrade.
-
@jegr said in OpenVPN not working after 2.5 upgrade.:
@jknott describes a dial in scenario. Again one now has to check the clients if there are e.g. settings like NCP Ciphers active or not as 2.5 has NCP enforced and renamed to data-ciphers (one big change from OpenVPN). So that's nothing that has to be "properly" tested as again it is an OpenVPN problem, not a pfSense problem. Also check out, that now there is a checkbox in the client export settings that can generate v2.4 compat configurations when exporting configs otherwise your client has to understand the new keywords from v2.5.
That seems to be a lot of things to check for something that used to just work. I also have that compatible config set and it still doesn't work. Also, why can I connect while on the same LAN, but not when coming in from elsewhere? That would seem to imply that my settings are correct. What can I do to get this to work properly? Is there some setting somewhere, that allows for remote access?
Maybe pfsense should go back to the previous version of OpenVPN, until this is worked out.
-
The data ciphers change can bite some people for a couple reasons, but most don't have to do with pfSense.
For example:
Server: OpenVPN 2.5 with Data Ciphers list with cipher A, Fallback cipher B (used when data cipher negotiation isn't possible)
Client: pfSense 2.4.x/OpenVPN 2.4.x with cipher set to B.When that client is upgraded to pfSense 2.5, it adds B to the data cipher list and sets fallback to B, and data cipher negotiation is enabled. It also adds some stock items to the list which are suggested by OpenVPN which in this example we'll say don't include A.
In this scenario, now the client has data cipher negotiation and is negotiating with the server. The server data cipher list only includes A, the client data cipher list doesn't include A. The fallback isn't used on the server because they are both capable of negotiating, but they can't agree on a cipher.
So post-upgrade this doesn't work, but there isn't anything pfSense should have done differently in this scenario, the server is not configured to match the client. Disabling data cipher negotiation nudges it to work because now the server is forced to use its fallback cipher in that scenario.
tl;dr Upgrade might expose an existing misconfiguration on the remote side, and you have to change the list to match what the server wants, which may be different than what was configured before.
Resist the temptation to disable data cipher negotiation. Eventually it won't be possible to disable, and also OpenVPN says in 3.0 they're removing the cipher choice entirely, allowing it to pick from all AEAD ciphers such as AES-GCM and ChaCha automatically.
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!
-
So, what are we supposed to do to get around this??? Also, why can I connect on the local LAN, but not from elsewhere? If I can connect on the local LAN, then surely the ciphers, etc. are OK.
-
Either:
- Fix the server.
- Find out what cipher the server does want, and add it to the list.
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!
-
And how the H do I do that??? I deleted the previous server config and started from scratch. What did I do wrong to cause this?
-
Not enough info for your case, I'm talking about OP and others connecting to a third party provider.
Yours may or may not be the same, but would be a subject for another thread if it's your own server.
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!
-
I had a working VPN between my pfsense system (2.4.5) and my notebook computer. After upgrading to 2.5.0, that VPN failed. I then deleted both the server and client configs and recreated from scratch. The problem still remains. I even tried that Legacy Client setting, as the client is 2.4.3. Given that I can connect over the local LAN, but not from outside the LAN, I don't understand how it could be an issue with ciphers or any other setting in either the server or client. Shouldn't it also fail on the local LAN, if I had any of those wrong? Also, the Allowed Data Encryption Algorithms, Fallback Data Encryption Algorithm and Auth digest algorithm are identical on server & client. I have been through configurations several times and can't see any discrepancies.
Again, why would it connect on the local LAN, but not from outside?
-
Without more info I can't say but it doesn't sound like the problem being discussed in this thread, so either start a different thread or continue one you already have elsewhere so the topic doesn't get hijacked.
The problem in this thread is for clients on pfSense to remote VPN providers, not for servers on pfSense.
-
@jegr said in OpenVPN not working after 2.5 upgrade.:
@stevemosher said in OpenVPN not working after 2.5 upgrade.:
2.5 is the suck until its tested properly.
That has nothing to do with pfSense 2.5 but with OpenVPN 2.5 that is now shipped with it. OpenVPN changed parameters and deprecated a few of thems and made others mandatory.
Also you both are discussing very different problems. @stevemosher obviously is using client mode to connect to some VPN provider which may still be on 2.4 and thus perhaps needs different settings now to connect from a 2.5 instance. Again not per se pfSense' fault.
@jknott describes a dial in scenario. Again one now has to check the clients if there are e.g. settings like NCP Ciphers active or not as 2.5 has NCP enforced and renamed to data-ciphers (one big change from OpenVPN). So that's nothing that has to be "properly" tested as again it is an OpenVPN problem, not a pfSense problem. Also check out, that now there is a checkbox in the client export settings that can generate v2.4 compat configurations when exporting configs otherwise your client has to understand the new keywords from v2.5.
Cheers
\jens -
All I hear is 'not our problem'.
Just sat in another meeting to discuss buying some Palo Alto product or some FIrepower crap from Cisco.
So much for open source solutions.
-
Not "not our problem" but "some things are out of our control".
If we can find a workaround or a way to make things behave better in our code, we'll happily change it. But thus far most of the threads have had OPs stop responding without giving us enough information to determine what can be done, or they get mixed up with 3-4 different issues and confuse people (like what was happening here).
See also: Changes we made at the direct suggestion of OpenVPN developers
https://redmine.pfsense.org/issues/10919If OP or anyone that is having a problem with the VPN client scenario to a third party provider wants to pick this back up and provide more info/logs, then we can keep looking into it.
-
@jimp said in OpenVPN not working after 2.5 upgrade.:
Not "not our problem" but "some things are out of our control".
If we can find a workaround or a way to make things behave better in our code, we'll happily change it. But thus far most of the threads have had OPs stop responding without giving us enough information to determine what can be done, or they get mixed up with 3-4 different issues and confuse people (like what was happening here).
See also: Changes we made at the direct suggestion of OpenVPN developers
https://redmine.pfsense.org/issues/10919If OP or anyone that is having a problem with the VPN client scenario to a third party provider wants to pick this back up and provide more info/logs, then we can keep looking into it.
What am I to gain out of the url provided?
-
@stevemosher said in OpenVPN not working after 2.5 upgrade.:
What am I to gain out of the url provided?
Information about specific changes made in OpenVPN behavior for OpenVPN 2.5.0 which could be relevant to problems in threads like this (and others).
-
@jimp said in OpenVPN not working after 2.5 upgrade.:
@stevemosher said in OpenVPN not working after 2.5 upgrade.:
What am I to gain out of the url provided?
Information about specific changes made in OpenVPN behavior for OpenVPN 2.5.0 which could be relevant to problems in threads like this (and others).
My eyes glaze over on some of this stuff. I was just trying to get my company back online here. You can see the entire thread is issues with 2.5. Our speeds are gone. 2 links to Nord usually got us about 80MB on the tunnels. We now get about 34MB. After this 'downgrade' they are making us buy Palo Alto products.
I'll say it again .. 2.5 is the suck.
-
@stevemosher Same problem from me! 2.5 really has broken openvpn badly!! Thinking of trying to find a way to downgrade maybe just to get my vpn working again!
-
@jagradang said in OpenVPN not working after 2.5 upgrade.:
@stevemosher Same problem from me! 2.5 really has broken openvpn badly!! Thinking of trying to find a way to downgrade maybe just to get my vpn working again!
We went back to 2.4.5-P1. Speeds, stability and peace from my users has returned. 2.5 is ass.
-
@stevemosher I'm on the verge of reverting too.. 2.5 is a shockingly bad release. Considering they had release candidates and still not fixed this.. I think the issue is around ciphers
I have managed to 'fix' the fluctuating speeds by unchecking Enable Data Encryption Negotiation and changed the Fallback Data Encryption Algorithm to AES-128.
I get lots of warnings in the logs but it connects and my speeds are now consistently back to how the were before my upgrade.
How that's working or why, no idea but it seems to fix it for me so guessing from your comment even though it shouldn't affect it, it is for me.
Let's see how much I can out up with it before I switch back to odler release
