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)?
@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
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.
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.
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
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.