Unable to connect to my VPN with the 2.6.0 update

[frandieguez]

Describe the bug My system upgraded the openvpn client to 2.6.0 and since then I'm unable to connect to my VPN.

To Reproduce I have my system configured in the file /etc/openvpn/client/my-company.conf which starts with

dev tun
proto tcp
verb 5

cipher AES-256-CBC
client
remote-cert-tls server
tls-cipher DEFAULT
remote MY-SERVER-IP PORT

THE CERTIFICATE

route-nopull

a bunch of routes

auth-user-pass ROUTE-TO-FILE

when trying to connect the log outputs

Feb 06 09:35:49 my-computer-name openvpn[13648]: OpenVPN 2.6.0 [git:makepkg/b999466418dddb89+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan 25 2023
Feb 06 09:35:49 my-computer-name openvpn[13648]: library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
Feb 06 09:35:49 my-computer-name openvpn[13648]: Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Feb 06 09:35:49 my-computer-name openvpn[13648]: Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Feb 06 09:35:49 my-computer-name openvpn[13648]: TCP/UDP: Preserving recently used remote address: [AF_INET]MYSERVER:PORT
Feb 06 09:35:49 my-computer-name openvpn[13648]: Socket Buffers: R=[131072->131072] S=[16384->16384]
Feb 06 09:35:49 my-computer-name openvpn[13648]: Attempting to establish TCP connection with [AF_INET]MYSERVER:PORT
Feb 06 09:35:49 my-computer-name openvpn[13648]: TCP connection established with [AF_INET]MYSERVER:PORT
Feb 06 09:35:49 my-computer-name openvpn[13648]: TCPv4_CLIENT link local: (not bound)
Feb 06 09:35:49 my-computer-name openvpn[13648]: TCPv4_CLIENT link remote: [AF_INET]MYSERVER:PORT
Feb 06 09:35:49 my-computer-name openvpn[13648]: WRTLS: Initial packet from [AF_INET]MYSERVER:PORT, sid=1afbdcc7 e6e5f0ea
Feb 06 09:35:49 my-computer-name openvpn[13648]: WRWARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Feb 06 09:35:51 my-computer-name openvpn[13648]: WRRWRWRVERIFY OK: depth=1, C=ES, ST=GALICIA, L=Santiago de Compostela, O=xxx, OU=IT, CN=CA
Feb 06 09:35:51 my-computer-name openvpn[13648]: VERIFY KU OK
Feb 06 09:35:51 my-computer-name openvpn[13648]: Validating certificate extended key usage
Feb 06 09:35:51 my-computer-name openvpn[13648]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Feb 06 09:35:51 my-computer-name openvpn[13648]: VERIFY EKU OK
Feb 06 09:35:51 my-computer-name openvpn[13648]: VERIFY OK: depth=0, C=XX, ST=XXXX, L=xxx, O=xxx, OU=IT, CN=server
Feb 06 09:35:51 my-computer-name openvpn[13648]: WRWRRWRConnection reset, restarting [0]
Feb 06 09:35:51 my-computer-name openvpn[13648]: TCP/UDP: Closing socket
Feb 06 09:35:51 my-computer-name openvpn[13648]: SIGUSR1[soft,connection-reset] received, process restarting
Feb 06 09:35:51 my-computer-name openvpn[13648]: Restart pause, 1 second(s)
Feb 06 09:35:52 my-computer-name openvpn[13648]: Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Feb 06 09:35:52 my-computer-name openvpn[13648]: Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Feb 06 09:35:52 my-computer-name openvpn[13648]: TCP/UDP: Preserving recently used remote address: [AF_INET]MYSERVER:PORT
Feb 06 09:35:52 my-computer-name openvpn[13648]: Socket Buffers: R=[131072->131072] S=[16384->16384]
Feb 06 09:35:52 my-computer-name openvpn[13648]: Attempting to establish TCP connection with [AF_INET]MYSERVER:PORT
Feb 06 09:35:52 my-computer-name openvpn[13648]: TCP connection established with [AF_INET]MYSERVER:PORT
Feb 06 09:35:52 my-computer-name openvpn[13648]: TCPv4_CLIENT link local: (not bound)
Feb 06 09:35:52 my-computer-name openvpn[13648]: TCPv4_CLIENT link remote: [AF_INET]SERVER-IP:1194
Feb 06 09:35:52 my-computer-name openvpn[13648]: WRTLS: Initial packet from [AF_INET]SERVER-IP:1194, sid=b16dca59 6c565fff
Feb 06 09:35:54 my-computer-name openvpn[13648]: WRWRRWRWRVERIFY OK: depth=1, C=xx, ST=xxx, L=xxxx, O=xxx, OU=IT, CN=CA
Feb 06 09:35:54 my-computer-name openvpn[13648]: VERIFY KU OK
Feb 06 09:35:54 my-computer-name openvpn[13648]: Validating certificate extended key usage
Feb 06 09:35:54 my-computer-name openvpn[13648]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Feb 06 09:35:54 my-computer-name openvpn[13648]: VERIFY EKU OK
Feb 06 09:35:54 my-computer-name openvpn[13648]: VERIFY OK: depth=0, C=xxx, ST=xxxx, L=xxxxx, O=xxx, OU=IT, CN=server
Feb 06 09:35:54 my-computer-name openvpn[13648]: WRWRRWRConnection reset, restarting [0]
Feb 06 09:35:54 my-computer-name openvpn[13648]: TCP/UDP: Closing socket
Feb 06 09:35:54 my-computer-name openvpn[13648]: SIGUSR1[soft,connection-reset] received, process restarting
Feb 06 09:35:54 my-computer-name openvpn[13648]: Restart pause, 1 second(s)

Expected behavior Being able to connect successfully as with previous version (2.5.8)

Version information:

• OS: Archlinux
• OpenVPN version: 2.6.0

Additional context no additional info

[cron2]

Hi,

On Mon, Feb 06, 2023 at 01:04:25AM -0800, Fran Diéguez wrote:

Describe the bug My system upgraded the openvpn client to 2.6.0 and since then I'm unable to connect to my VPN.

From the logs, it looks like the server is unhappy with something the client sends during handshake, and then just resets the TCP connection (= up to that point, everything in the client log looks normal).

Can you have a look into the server logs?

gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[schwabe]

Also you should not use tls-cipher DEFAULT as that downgrades the TLS ciphers strength.

[frandieguez]

I've commented the tls-cipher DEFAULT line but no changes whatsoever. I'll take a look at server logs and report back.

Thanks for your help

[schwabe]

The behaviour you are seeing is the server killing your connection since it does not like something about your client. So you really need to check the server log.

[frandieguez]

We are contacting our Mikrotik provider to debug with them as the logs are not throwing any useful information

[schwabe]

you could check if compat-mode 2.4.0 (or 2.3.0) helps.

[frandieguez]

I've fixed it by setting the fallback ciphers in my client

data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC cipher AES-256-CBC data-ciphers-fallback AES-256-CBC

[schwabe]

That kind of confirms that the Mikrotik implementation is still stuck on relying on compatibility to OpenVPN 2.3.x. We do not offer that by default in configurations anymore as all OpenVPN 2.4.0+ support AEAD ciphers and cipher negotiation and Mikrotik should resolve that issue or explicitly state that you need compatibility mode/extra configs with their configs.

[mmokrejs]

Just as a note, I came across this as I had troubles in getting a server running after udate to openvpn-2.6.4. Beware AES-128-CBC was dropped.

Jul 16 17:40:52 xx openvpn[16088]: OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Jul 16 17:40:52 xx openvpn[16088]: library versions: OpenSSL 1.1.1q  5 Jul 2022, LZO 2.10
Jul 16 17:40:52 xx openvpn[16090]: Diffie-Hellman initialized with xxxx bit key
Jul 16 17:40:52 xx openvpn[16090]: Cipher algorithm 'AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC' not found
Jul 16 17:40:52 xx openvpn[16090]: Cipher AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC not supported

The error message should isolate the offending cipher.

[cron2]

Hi,

On Sun, Jul 16, 2023 at 10:13:22AM -0700, Martin Mokrej?? wrote:

Jul 16 17:40:52 xx openvpn[16090]: Cipher algorithm 'AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC' not found

This looks like you had

cipher AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC

in your config - this was never a valid config, even before 2.6. "--cipher" takes a single cipher argument (and "a number of ciphers with :" is not "a single cipher"), "--data-ciphers" takes a list.

Usually the best advice is to leave out all "--cipher" and "--data-ciphers" config options, unless you need compatibility with remotes older than 2.4, or with a non-default config hardwiring a non-default cipher (and in this case, do what OpenVPN tells you: add it to the "--data-ciphers" list).

gert

[mmokrejs]

@cron2 Thank you for inspection. I don't think I placed all the ciphers seaparated by colon under cipher, I mostly just comment out some lines in my config. I believe I touched only data-ciphers line and introduced during experiment also data-ciphers-fallback. Yes, in the end I tried to comment out the ciphers and data-ciphers.

It seems the data-ciphers-fallback must be additional ciphers not present in data-ciphers but openvpn should be clever enough and not complain if the ciphers were repeated and trailed by a few more.

More importantly, it should be much more advertised the ciphers are an ordered listing from left to right. I do not see in the logs on the server with verb 5 level a list of ciphers tried during negotiations, one by one.

But once again, if there is an offending (unsupported) cipher in the data-ciphers or data-ciphers-fallback its name should be extracted from the string separated by colons and shown in the error message.

[cron2]

data-ciphers-fallback is also a single cipher only. So if you put the full list there, it will explain the error you saw - "the thing with all the colons in it" is not a supported cipher, and that's what OpenVPN is telling you.

This is a very special case option anyway, which should be only ever used if you are connecting to a peer that is refusing to participate in any variant of cipher negotiation - like, a 2.2 or 2.3 peer configured with --enable-small or a 2.4/2.5 peer running with --ncp-disable. Under normal operations, a 2.6.x version talking to a 2.4.x or 2.5.x version (without extra configs getting in the way) will just work, without having to touch this.

[schwabe]

I think you misunderstand data-ciphers-fallback. This option is set to exactly one cipher and that cipher is used as last resort fallback if all others method of cipher negotiation fail. Unless you have some 2.3 or older peers with uncommon configure options, this option is not needed at all.

And what you are asking is is already implemented. We print the unsupported ciphers. If you add something with : to an option that only supports a single cipher, we will point out that the whole stirng is not a supported cipher.

[mmokrejs]

Indeed the data-ciphers-fallback should have been called data-cipher-fallback (singular), it is confusing. At least if the docs stated it is for a single cipher only, supposedly AES-128-CBC dropped in version XX or for BF-CBC dropped in version 2.5.

I upgraded all clients to 2.5 or even 2.6.

BTW, page https://community.openvpn.net/openvpn/wiki/CipherNegotiation says:

Effective directives and terms

2.5: --data-ciphers ALG:ALG - Data channel ciphers. Default ALG AES-256-GCM:AES-128-GCM 2.5: --data-ciphers-fallback ALG:ALG - Essentially the same as --cipher

Note the : (colon).

Currently, the tunnels are established fine but the routes are not added properly, like before. I will try to recap that elsewhere.

[TinCanTech]

Note the : (colon).

Duly noted.

Don't forget to see xkcd#386

[schwabe]

Indeed the data-ciphers-fallback should have been called data-cipher-fallback (singular), it is confusing. At least if the docs stated it is for a single cipher only, supposedly AES-128-CBC dropped in version XX or for BF-CBC dropped in version 2.5.

It is singular (fallback), it is the fallback if data-ciphers option does not work.

I upgraded all clients to 2.5 or even 2.6.

BTW, page https://community.openvpn.net/openvpn/wiki/CipherNegotiation says:

Better refer to the man page section https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst That is the most authoritive source apart from the source code itself.

[cron2]

Hi,

On Wed, Jul 19, 2023 at 02:14:47PM -0700, TinCanTech wrote:

Note the : (colon).

Duly noted.

Already fixed?

gert -- Gert Doering - Munich, Germany @.***

[TinCanTech]

Fixed. I also made it clear that --data-ciphers is a list, while --data-ciphers-fallback is a single algorithm.