New OpenVPN 2.6.0 Client (Windows 10 64bit) fails to connect

Virtual Private Networks OpenVPN
1

Brand new Community OpenVPN client Version 2.6.0 (Community Downloads | OpenVPN) fails to connect and shows these related messages in log, whereas previous Version 2.5.8 connected flawlessly, - any ideas/suggestions from other users what to change (serverside/clientside)?

2023-01-28 14:35:40 us=328000 OpenVPN 2.6.0 [git:v2.6.0/b999466418dddb89] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Jan 25 2023
2023-01-28 14:35:40 us=328000 Windows version 10.0 (Windows 10 or greater), amd64 executable
2023-01-28 14:35:40 us=328000 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2023-01-28 14:35:40 us=328000 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2023-01-28 14:35:40 us=328000 Need hold release from management interface, waiting...
2023-01-28 14:35:40 us=765000 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:51473
2023-01-28 14:35:40 us=875000 MANAGEMENT: CMD 'state on'
2023-01-28 14:35:40 us=875000 MANAGEMENT: CMD 'log on all'
2023-01-28 14:35:41 us=546000 MANAGEMENT: CMD 'echo on all'
2023-01-28 14:35:41 us=546000 MANAGEMENT: CMD 'bytecount 5'
2023-01-28 14:35:41 us=562000 MANAGEMENT: CMD 'state'
2023-01-28 14:35:41 us=562000 MANAGEMENT: CMD 'hold off'
2023-01-28 14:35:41 us=578000 MANAGEMENT: CMD 'hold release'
2023-01-28 14:35:41 us=609000 MANAGEMENT: CMD 'password [...]'
2023-01-28 14:35:41 us=609000 OpenSSL: error:11800071:PKCS12 routines::mac verify failure
2023-01-28 14:35:41 us=609000 OpenSSL: error:0308010C:digital envelope routines::unsupported
2023-01-28 14:35:41 us=609000 Decoding PKCS12 failed. Probably wrong password or unsupported/legacy encryption
2

Your client is using openssl version 3 which gives a mismatch with the openssl 1.1.1 version that IPFire is using.

See following thread for a fix on the client.
https://community.ipfire.org/t/ovpn-cert-creation-algo/7911

1 Like
3

@bonnietwin thank you for pointing to that thread, but that’s mainly a discussion about Linux clients with SSL 3. However, I found that adding the line

providers legacy default

to the .ovpn configuration file does the trick.

3 Likes
4

The idea was that you would need to make the same changes in the windows openssl3 config file.

However,

that seems to be an even easier fix. I will try it out on my system, reverting the openssl3 config file back to its original status.

That is a very good find. :+1:

1 Like
5

so providers legacy default added to the .ovpn file did not work for me with my Network Manager OpenVPN plugin approach on my Linux laptop which still has OpenVPN 5.8.0 at the moment.

Looking through the changelog info for version 2.6.0 it looks like that option might have been put into 2.6.0 because they have added openssl 3 support. It mentions that they have options to override if necessary.

EDIT: Confirmed that option “providers” is new in 2.6.0

I will try again when openvpn-2.6.0 is updated on my system.

When IPFire gets OpenSSL 3 implemented then you should be able to remove that line from your .ovpn file in your client. Keep an eye out in the Core Update announcements.

1 Like
6

Hi all,
@bonnietwin

i think an update to OpenSSL-3.x alone won´t help since the .p12 package has been crypted with the old deprecated algorithm. I think there is the need to recreate it via WUI and the new OpenSSL defaults for the PKCS#12 creation.

Best,

Erik

P.S.: OpenVPN-2.6.0 is meanwhile out https://github.com/OpenVPN/openvpn/blob/v2.6.0/Changes.rst !

1 Like
7

In limited testing with OPVN 2.6.0 on windows , I confirm, with an updated (4096bit) client certificate the line providers legacy default still needs to be present, a bigger issue is for my setups is the default cipher AES-256-CBC. This must either be changed in both client and server to AES-256-GCM, unless the workaround (data-ciphers-fallback AES-256-CBC) to force it to accept the CBC cipher server-side is deployed in the ovpn file ; Here is my working config for this setup where its a new 4096bit file , using a AES-256-CBC encryption server ( Firewall side)
Lots of manual stuff sadly but at least it gets it going for now , I am reading AES-256-GCM is a good thing , should this perhaps not be the default?
PS in all cases providers legacy default seems to be a requirement

nobind
dev tun
proto udp
tun-mtu 1400
remote xxxx.find.me 1194
providers legacy default
pkcs12 IJBx4096.p12
data-ciphers-fallback AES-256-CBC
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name 88.999.000.40 name
mssfix 0
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact

1 Like
8

Hi all,

OpenVPN-2.6.0 uses the default ‘AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305’ for data-ciphers → https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst which might be a good one in my opinion. AEAD is preferable to CBC in security but also in speed i think. To get rid of the deprecation warning ''DEPRECATED OPTION: --cipher set to ‘*-CBC’ but missing in --data-ciphers…" the only way for me was to use as you mentioned the ‘–data-ciphers-fallback’ option to silence the warning. If this is set in combination with ‘–data-ciphers’ on server side, it makes no difference which cipher is used on client side since OpenVPN uses the data ciphers from left to right and negotiates it with the client if they are present. GCM should be available since OpenSSL-1.0.1 i think.

Best,

Erik

1 Like