HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection

jimp

Let me start by saying this: OpenVPN 2.6 and 3.0 are still under development and we do not know when they will make their way into pfSense. That said, now is the time to start planning for the changes!

There are some pretty substantial changes coming in OpenVPN that require manual intervention from users:

Static Key mode (secret, a.k.a. "Shared Key") is being deprecated. They no longer consider it secure. Thus, TLS is now a requirement. They added a new peer-fingerprint method which they claim in not much more difficult than shared key mode but it still requires certificates so using regular TLS with pfSense is likely still going to be the easiest way.
- It's deprecated, but not removed, so it is still available in OpenVPN 2.6 with a logged warning but will almost certainly be removed completely from 2.7/3.0
- They added a compat-mode option to enable compatibility with specific older clients, but it's unclear if this would still allows static key to be used on future versions after it is removed. It likely will not.
Cipher negotiation is compulsory (no way to disable it)
Compression is disabled by default
Starting with OpenVPN 3, the only ciphers will be AES-256-GCM, AES-128-GCM, and CHACHA20-POLY1305 as these are fast and secure AEAD ciphers.
- Some functions in OpenVPN 3 and even 2.6 may be limited to only AES-256-GCM depending on the operating system.

What does this mean for you?

If you use shared key tunnels, do not wait, convert them to TLS NOW so you are not rushing to do it before upgrading later.
Enable data cipher negotiation and ensure the data ciphers list contains AES-256-GCM, AES-128-GCM, and CHACHA20-POLY1305 at the top of the list NOW. Any modern OpenVPN client will use these without issue already.
- If possible, disable other ciphers as well and see if any clients have issues.
Disable compression on all OpenVPN tunnels, which you should do anyhow because compression is insecure and doesn't help much these days.

Again, there is no ETA on when these may land in a release but do not wait to address these.

EDIT 2022-03-03:
I tested OpenVPN 2.6 and shared key still works but it does log an error stating the option is deprecated. Still a good idea to start migrating tunnels to TLS now, don't wait.

Mar 3 13:56:17 	openvpn 	57942 	DEPRECATED OPTION: The option --secret is deprecated.
Mar 3 13:56:17 	openvpn 	57942 	DEPRECATION: No tls-client or tls-server option in configuration detected. OpenVPN 2.7 will remove the functionality to run a VPN without TLS. See the examples section in the manual page for examples of a similar quick setup with peer-fingerprint.

Gertjan

Info like this should be on the Netgate blog :

This way, only hundreds will get caught by the future update, "as they still missed it", instead of thousands .....
Or a second, 'jimp only - Heads up pinned' RSS channel.

jimp

It's still a bit early to bring it up that publicly, but soon.

Prez_Mgmt

@jimp Hi,
Is this why I'm getting this error?

Mon Mar 21 09:59:40 2022 OpenVPN 2.5.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 21 2021
Mon Mar 21 09:59:40 2022 Windows version 10.0 (Windows 10 or greater) 64bit
Mon Mar 21 09:59:40 2022 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10
Mon Mar 21 09:59:42 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
Mon Mar 21 09:59:42 2022 UDPv4 link local: (not bound)
Mon Mar 21 09:59:42 2022 UDPv4 link remote: [AF_INET]xx.xx.xx.xx:1194
Mon Mar 21 10:00:42 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 10:00:42 2022 TLS Error: TLS handshake failed

Gertjan

@prez_mgmt said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

Mon Mar 21 10:00:42 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 10:00:42 2022 TLS Error: TLS handshake failed

Noop.
Jimp was talking about a future version :

"OpenVPN 2.7" will come out somewhere in 2023.
You are using version 2.5.2.
Just keep an eye on this page.

This :

@prez_mgmt said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

Mon Mar 21 10:00:42 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 10:00:42 2022 TLS Error: TLS handshake failed

is your OpenVPN client complaining that it can not do it's TLS thing with the server.

Do you have the corresponding logs at the same moment from the server side ? It looks like you never even reached the server.

noplan

@jimp

No it's not to early to bring this up

I think we already hit this topic in the last German user group meeting
Let's see maybe we bring it up again

1st Friday 17:00 sharp every month hosted by @JeGr

Plannin starts early

jimp

As others have said, those errors are unrelated. If you want help diagnosing that kind of problem, create a new thread and discuss it there. This thread is only for discussing and planning for upcoming changes in future releases, nothing that is already released..

Prez_Mgmt

@jimp
yes, I created this thread afterwards

brians

Good thing I noticed this.
I was about to send out an appliance using shared to to middle of nowhere and this saved me a bunch of future headache.

Whereas I could setup a shared key OpenVPN in mere minutes, the TLS method is a bit more complicated. I spent this afternoon learning it and testing - now I believe would be fairly fast to setup.

jimp

@brians said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

Good thing I noticed this.
I was about to send out an appliance using shared to to middle of nowhere and this saved me a bunch of future headache.

Whereas I could setup a shared key OpenVPN in mere minutes, the TLS method is a bit more complicated. I spent this afternoon learning it and testing - now I believe would be fairly fast to setup.

I'm working on writing a migration guide to help with that kind of transition. It's not really all that more difficult these days just a few extra steps involved.

Bob.Dig

@jimp said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

I'm working on writing a migration guide to help with that kind of transition.

Sadly your time of YouTube videos seems to be over?
But help is surely appreciated in any form.

jimp

IIRC There are already hangout videos for OpenVPN that cover setting up site-to-site with overrides. Not a lot new for this but I am aiming to try to make it as minimally painful as we can.

RandyW

@jimp
Hi, this was an interesting read. Unfortunately the v2.6 also killed my PureVPN connection and even the tecks couldn't find the reason for not even connecting at all to their servers. They even logged into my system and said that PFsense v2.6 is incompatible with their servers. BONG... what happened ?
I thought v2.6 was up to date on all of these changes.

jimp

@randyw said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

@jimp
Hi, this was an interesting read. Unfortunately the v2.6 also killed my PureVPN connection and even the tecks couldn't find the reason for not even connecting at all to their servers. They even logged into my system and said that PFsense v2.6 is incompatible with their servers. BONG... what happened ?
I thought v2.6 was up to date on all of these changes.

pfSense CE 2.6.0 does not use OpenVPN 2.6.0, this post is about OpenVPN 2.6.0 which is still not released yet. Start your own thread with details about your problem, it's most likely an issue in your settings. OpenVPN is OpenVPN and is very good about compatibility but occasionally needs some adjustments as they change options/protocol details.

mzaknoen

Thanks for the post! I've read through documentation and watched a few videos. This maybe a foolish question, but if I have multiple "clients" connecting to our server. Do I need recreate a new CA and Certificate for each "client" OR Do I simply need to generate unique client certificate's? And apply the same server TLS key to each client?

Cool_Corona

With certificate generation with Lets Encrypt integration?

brians

@mzaknoen said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

Thanks for the post! I've read through documentation and watched a few videos. This maybe a foolish question, but if I have multiple "clients" connecting to our server. Do I need recreate a new CA and Certificate for each "client" OR Do I simply need to generate unique client certificate's? And apply the same server TLS key to each client?

I have followed this guide:
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

I export the CA and client certificates, then import them into the client netgate appliances. Read the entire doc because I missed some things at first regarding client specific overrides but after a couple times reading and actual hands-on it makes sense.

jimp

@mzaknoen said in HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection:

Thanks for the post! I've read through documentation and watched a few videos. This maybe a foolish question, but if I have multiple "clients" connecting to our server. Do I need recreate a new CA and Certificate for each "client" OR Do I simply need to generate unique client certificate's? And apply the same server TLS key to each client?

If your server is setup as SSL/TLS and allows multiple clients on a single server, then it's already not using shared key or P2P mode and it will be fine.

The problematic setups are ones using shared key mode specifically (one server with one client, no certificates).

If you have multiple servers each with a single client and want to convert them, you can do so individually (still one server for each client) or collectively (convert them to one sever and multiple clients). How you handle the CA structure is up to you. You can use a unique CA per server if you want, but it's not strictly necessary. Each server should have a unique TLS key though, which will also help ensure that a client with the "wrong" cert won't be able to connect to a server it shouldn't be using if you have multiple.

RootBear

@cool_corona Are you suggesting that everybody that can use LetsEncrypt should be able to connect to your VPN :-?