OpenVPN profiles no longer work in NetworkManager after 20240513 update

Not sure of a fix but all VPN profiles no longer work with Network Manager, either cli or gui. I see in the logs basically:

OpenSSL: error:0A0000086:SSL routines::certificate verify failed:
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

This of course did work previous to the update as I was actively connected to the VPN during the upgrade. Upon reboot it would no longer connect to any

1 Like

Nmcli gives me ā€œError: Connection activation failed: The connection attempt timed outā€.
Journalctl basically says the same with, ā€œconnect timeout exceededā€, 1 minute after ā€œstarting openvpnā€.
Everything was working fine before/during the update.

According to your profile youā€™re on XFCE, so am I and they work for me after todayā€™s update.

Iā€™d first check if your provider has updated their profiles/certificates/ovpn files, might just be a coincidence that it happened today.

If that was to me, Iā€™m on Cinnamon. JimmyK though may have been who that was to.
But, itā€™s not the providerā€™s files per se. I have several Manjaro systems and only two are updated. The ones not updated still connect right away.

Iā€™m taking a guess that something was changed involving OpenSSL and how it verifies files. In further looking Iā€™m seeing stuff like it failing to verify the crl file, which Iā€™m not sure if thatā€™s a bug causing that behavior or something in OpenSSL that was updated requires all new crl files. Though that would seem problematic if so just because what, everyone all at once in the world needs to redo crl files? That would not seem like a decision that would be done by the maintainers, but I could certainly be wrong.

One suggestion on the Arch for the error I get, though from 2022, was to go in the connection profile and set tls-cipher=DEFAULT:@SECLEVEL=0 though I wouldnā€™t keep it that way. But I did test it and that had no effect on the error.

Definitely something with OpenSSL. I downgraded it from 3.3.0-1 to 3.2.1-1 and the connection worked right away. Whether itā€™s a compilation bug or something new in OSSL itself, Iā€™m not sure

Odd. Works for me (Xfce, 6.6LTS, ProtonVPN), hereā€™s journalctl for gui connection with nm using OpenSSL 3.3.0:

May 14 01:31:37 blue-pc NetworkManager[466]: <info>  [1715639497.3505] vpn[0x555cffecb430,27b57dde-d241-7f31613d9eee,"node-nl-195.protonvpn.net.udp"]: starting openvpn
May 14 01:31:37 blue-pc nm-openvpn[349143]: OpenVPN 2.6.10 [git:makepkg/ba0f62fb950c56a0+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Mar 20 2024
May 14 01:31:37 blue-pc nm-openvpn[349143]: library versions: OpenSSL 3.3.0 9 Apr 2024, LZO 2.10
May 14 01:31:37 blue-pc nm-openvpn[349143]: DCO version: N/A
May 14 01:31:37 blue-pc nm-openvpn[349143]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 14 01:31:37 blue-pc nm-openvpn[349143]: TCP/UDP: Preserving recently used remote address: [AF_INET]1xx.1xx.xx.xx:xxxxx
May 14 01:31:37 blue-pc nm-openvpn[349143]: UDPv4 link local: (not bound)
May 14 01:31:37 blue-pc nm-openvpn[349143]: UDPv4 link remote: [AF_INET]1xx.1xx.xx.xx:xxxxx
May 14 01:31:37 blue-pc nm-openvpn[349143]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
May 14 01:31:38 blue-pc nm-openvpn[349143]: [node-nl-195.protonvpn.net] Peer Connection Initiated with [AF_INET]1xx.1xx.xx.xx:xxxxx
May 14 01:31:39 blue-pc nm-openvpn[349143]: NOTE: setsockopt TCP_NODELAY=1 failed
May 14 01:31:39 blue-pc nm-openvpn[349143]: TUN/TAP device tun0 opened
May 14 01:31:39 blue-pc nm-openvpn[349143]: /usr/lib/nm-openvpn-service-openvpn-helper --debug 0 349130 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_15 --tun -- tun0 1500 0 10.96.0.16 255.255.0.0 init
May 14 01:31:39 blue-pc nm-openvpn[349143]: UID set to nm-openvpn
May 14 01:31:39 blue-pc nm-openvpn[349143]: GID set to nm-openvpn
May 14 01:31:39 blue-pc nm-openvpn[349143]: Capabilities retained: CAP_NET_ADMIN
May 14 01:31:39 blue-pc nm-openvpn[349143]: Initialization Sequence Completed

In searching around tonight when I got home I see other posts in other places of people saying the same thing with 3.3. This popped up for Arch users or distros closer to Arch that release faster, so there was some instances of this in the wild at least. Some, not all are, are using PIA like myself. I also had opened a ticket with PIA earlier and apparently some of them did too.

Apparently itā€™s an addition of a crl-verify block in 3.3. One can remove it in the config and it will go back to working but Iā€™m not a fan of removing those types of things myself. So Iā€™ll stay on 3.2.1 for now until thereā€™s updated openvpn files from PIA. Or if they take too long, research what other VPNs are having this issue then look at ones that arenā€™t and decide from there.

1 Like

Iā€™m also using PIA. Odd thing is that I updated both a laptop with KDE and a desktop with XFCE and only the latter is affected. Itā€™s possible that I used different configs, so will have to investigate further when I have the time.

EDIT: Iā€™ve gotten to the bottom of it. :upside_down_face:

I had imported the same ā€˜next-genā€™ configā€™s on both my devices. However, they had imported differently for some reason. One had a custom port set under ā€˜advancedā€™, where the other didnā€™t.

The PIA openvpn configs all specify port 1198 and until now, we didnā€™t need to go into the advanced options and specify that as a custom port. Now we do. Itā€™s that simple.

2 Likes

Experiencing the same problem (timeout due to handshake timeout). Downgrading OpenSSL to v3.2.1, as someone in the stable update thread suggested, did not help. Did specifying the port 1198 help to get the connection working again? Stupid question: Where do I find the advanced options (for the VPN connection) in the Network Manager?
Thanks in advance!

This is on Cinnamon of course but I imagine itā€™s the same or close to it. On your menu bar click on Network Manager, open Network Settings ( not Network Connections ) and on the left select the profile you want. Then on the bottomish right is a cogwheel. Open that, on the left select Identity, and at the bottom is Advanced.

The first option on the General tab is probably unchecked, Use custom gateway port. Check it and change it to 1198 and click Apply up top. Donā€™t change the overall port in the gateway area, leave that at 1197. Basically if it said 1197, I didnā€™t have to touch it.

That did work for me, changing the Advanced custom port to 1198

1 Like

Unfortunately, changing the gateway port to 1198 in the advanced settings did not help :frowning:

Still getting a connection timeout :sob:

Mai 16 09:49:33 tazdevil NetworkManager[1137]: <info>  [1715845773.6900] vpn[0x60016a1d3160,b5e40f9e-ffbb-4570-8c3e-baec85d0ed7c,"TryHackMe"]: starting openvpn
Mai 16 09:49:33 tazdevil NetworkManager[1137]: <info>  [1715845773.6902] audit: op="connection-activate" uuid="b5e40f9e-ffbb-4570-8c3e-baec85d0ed7c" name="TryHackMe" pid=2113 uid=475409894 result="success"
Mai 16 09:49:33 tazdevil NetworkManager[20638]: 2024-05-16 09:49:33 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: OpenVPN 2.6.10 [git:makepkg/ba0f62fb950c56a0+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Mar 20 2024
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: library versions: OpenSSL 3.3.0 9 Apr 2024, LZO 2.10
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: DCO version: N/A
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: TCP/UDP: Preserving recently used remote address: [AF_INET]18.202.129.195:1194
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: UDPv4 link local: (not bound)
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: UDPv4 link remote: [AF_INET]18.202.129.195:1194
Mai 16 09:49:33 tazdevil nm-openvpn[20638]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mai 16 09:50:33 tazdevil nm-openvpn[20638]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mai 16 09:50:33 tazdevil nm-openvpn[20638]: TLS Error: TLS handshake failed
Mai 16 09:50:33 tazdevil nm-openvpn[20638]: SIGUSR1[soft,tls-error] received, process restarting
Mai 16 09:50:34 tazdevil NetworkManager[1137]: <warn>  [1715845834.0973] vpn[0x60016a1d3160,b5e40f9e-ffbb-4570-8c3e-baec85d0ed7c,"TryHackMe"]: connect timeout exceeded
Mai 16 09:50:34 tazdevil nm-openvpn-serv[20633]: Connect timer expired, disconnecting.
Mai 16 09:50:34 tazdevil nm-openvpn[20638]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mai 16 09:50:34 tazdevil nm-openvpn[20638]: SIGTERM[hard,init_instance] received, process exiting

Is this (UDPv4 link local: (not bound)) a problem? How does your journal log (journalctl -u NetworkManager -e -f) look like for the successfull connection?

Mai 16 09:49:33 tazdevil nm-openvpn[20638]: UDPv4 link local: (not bound)

Starting the connection on the console using sudo (sudo openvpn ~/Documents/conn.ovpn) works. Doing it WITHOUT sudo causes

2024-05-16 10:03:34 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)

Maybe something to do with the NetworkManager service not allowed to create a tun adapter? See nm-openvpn ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted / Networking, Server, and Protection / Arch Linux Forums

Morning guys!
Experiencing the same issue, with the same TLS error and tried the following:

:negative_squared_cross_mark: Without any changes to the config file, which is provided by the VPN server

sudo openvpn --config Development/Keystore/vpn/17-05-2024/my_openvpn_file.ovpn 

2024-05-18 14:33:03 TCP/UDP: Preserving recently used remote address: [AF_INET]<IPV4>:443
2024-05-18 14:33:03 Socket Buffers: <REDACT>
2024-05-18 14:33:03 Attempting to establish TCP connection with [AF_INET]<IPV4>:443
2024-05-18 14:33:03 TCP connection established with [AF_INET]<IPV4>:443
2024-05-18 14:33:03 TCPv4_CLIENT link local: (not bound)
2024-05-18 14:33:03 TCPv4_CLIENT link remote: [AF_INET]<IPV4>:443
2024-05-18 14:33:03 TLS: Initial packet from [AF_INET]<IPV4>:443,
2024-05-18 14:33:03 VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: <COUNTRY>, <LOCALITY>, <ORG>>., <CN>>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 14:33:03 Sent fatal SSL alert: bad certificate
2024-05-18 14:33:03 OpenSSL: error:0A000086:SSL routines::certificate verify failed:
2024-05-18 14:33:03 TLS_ERROR: BIO read tls_read_plaintext error
2024-05-18 14:33:03 TLS Error: TLS object -> incoming plaintext read error
2024-05-18 14:33:03 TLS Error: TLS handshake failed
2024-05-18 14:33:03 Fatal TLS error (check_tls_errors_co), restarting
2024-05-18 14:33:03 SIGUSR1[soft,tls-error] received, process restarting
2024-05-18 14:33:03 Restart pause, 4 second(s)

:negative_squared_cross_mark: Weak cipher workaround

tls-cipher DEFAULT:@SECLEVEL=0

sudo openvpn --config Development/Keystore/vpn/17-05-2024/my_openvpn_file.ovpn 

2024-05-18 11:18:59 TCP/UDP: Preserving recently used remote address: [AF_INET]<IPV4>:443
2024-05-18 11:18:59 Socket Buffers: <REDACT>
2024-05-18 11:18:59 Attempting to establish TCP connection with [AF_INET]<IPV4>:443
2024-05-18 11:18:59 TCP connection established with [AF_INET]<IPV4>:443
2024-05-18 11:18:59 TCPv4_CLIENT link local: (not bound)
2024-05-18 11:18:59 TCPv4_CLIENT link remote: [AF_INET]<IPV4>:443
2024-05-18 11:18:59 TLS: Initial packet from [AF_INET]<IPV4>:443
2024-05-18 11:18:59 VERIFY OK: depth=1, <COUNTRY>, <LOCALITY>, <ORG>>., <CN>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 11:18:59 VERIFY X509NAME OK: <COUNTRY>, <LOCALITY>, <ORG>>., <CN>>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 11:18:59 VERIFY OK: depth=0, <COUNTRY>, <LOCALITY>, <ORG>>., <CN>>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 11:18:59 Control Channel: <DOMAIN>, cipher <DOMAIN> DHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA1, peer temporary key: 2048 bits DH
2024-05-18 11:18:59 [<DOMAIN>] Peer Connection Initiated with [AF_INET]<IPV4>:443
2024-05-18 11:18:59 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-05-18 11:18:59 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-05-18 11:19:00 SENT CONTROL [<DOMAIN>]: 'PUSH_REQUEST' (status=1)
2024-05-18 11:19:00 PUSH: Received control message: 'PUSH_REPLY,<ROUTE>,push-continuation 2'
2024-05-18 11:19:00 PUSH: Received control message: 'PUSH_REPLY,<ROUTE> ,dhcp-option DNS <IPV4>,dhcp-option DNS <IPV4>,dhcp-option DOMAIN <DOMAIN>,ifconfig <IPV4>,push-continuation 1'
2024-05-18 11:19:00 OPTIONS IMPORT: --ifconfig/up options modified
2024-05-18 11:19:00 OPTIONS IMPORT: <ROUTE> options modified
2024-05-18 11:19:00 OPTIONS IMPORT: <ROUTE>-related options modified
2024-05-18 11:19:00 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-05-18 11:19:00 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('AES-256-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to connect to this server.
2024-05-18 11:19:00 ERROR: Failed to apply push options
2024-05-18 11:19:00 Failed to open tun/tap interface
2024-05-18 11:19:00 SIGUSR1[soft,process-push-msg-failed] received, process restarting
2024-05-18 11:19:00 Restart pause, 1 second(s)

:information_source: Seems OpenSSL is annoyed with less secure ciphers:

"failed to negotiate cipher with server.  Add the server's cipher ('AES-256-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to connect to this server."

:white_check_mark: Add cipher algorithm to ovpn config

data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC

sudo openvpn --config Development/Keystore/vpn/17-05-2024/my_openvpn_file.ovpn 

2024-05-18 15:29:48 TCP/UDP: Preserving recently used remote address: [AF_INET]<IPV4>:443
2024-05-18 15:29:48 Socket Buffers: <REDACT>
2024-05-18 15:29:48 Attempting to establish TCP connection with [AF_INET]<IPV4>:443
2024-05-18 15:29:48 TCP connection established with [AF_INET]<IPV4>:443
2024-05-18 15:29:48 TCPv4_CLIENT link local: (not bound)
2024-05-18 15:29:48 TCPv4_CLIENT link remote: [AF_INET]<IPV4>:443
2024-05-18 15:29:49 TLS: Initial packet from [AF_INET]<IPV4>:443
2024-05-18 15:29:49 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-05-18 15:29:49 VERIFY OK: depth=1, <COUNTRY>, <LOCALITY>, <ORG>>., <CN>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 15:29:49 VERIFY X509NAME OK: <COUNTRY>, <LOCALITY>, <ORG>>., <CN>>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 15:29:49 VERIFY OK: depth=0, <COUNTRY>, <LOCALITY>, <ORG>>., <CN>>, emailAddress=<DOMAIN>@<DOMAIN>
2024-05-18 15:29:49 Control Channel: <DOMAIN>, cipher <DOMAIN> DHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA1, peer temporary key: 2048 bits DH
2024-05-18 15:29:49 [<DOMAIN>] Peer Connection Initiated with [AF_INET]<IPV4>:443
2024-05-18 15:29:49 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-05-18 15:29:49 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-05-18 15:29:50 SENT CONTROL [<DOMAIN>]: 'PUSH_REQUEST' (status=1)
2024-05-18 15:29:55 SENT CONTROL [<DOMAIN>]: 'PUSH_REQUEST' (status=1)
2024-05-18 11:19:00 PUSH: Received control message: 'PUSH_REPLY,<ROUTE>,push-continuation 2'
2024-05-18 11:19:00 PUSH: Received control message: 'PUSH_REPLY,<ROUTE> ,dhcp-option DNS <IPV4>,dhcp-option DNS <IPV4>,dhcp-option DOMAIN <DOMAIN>,ifconfig <IPV4>,push-continuation 1'
2024-05-18 15:29:55 OPTIONS IMPORT: --ifconfig/up options modified
2024-05-18 15:29:55 OPTIONS IMPORT: <ROUTE> options modified
2024-05-18 15:29:55 OPTIONS IMPORT: <ROUTE>-related options modified
2024-05-18 15:29:55 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-05-18 15:29:55 Using peer cipher 'AES-256-CBC'
2024-05-18 15:29:55 net_route_v4_best_gw query: dst <IPV4>
2024-05-18 15:29:55 net_route_v4_best_gw result: via <IPV4> dev wlp3s0
2024-05-18 15:29:55 ROUTE_GATEWAY <IPV4>/<IPV4> IFACE=wlp3s0 HWADDR=<HW_ADDR>
2024-05-18 15:29:55 TUN/TAP device tun0 opened
2024-05-18 15:29:55 net_iface_mtu_set: mtu 1500 for tun0
2024-05-18 15:29:55 net_iface_up: set tun0 up
2024-05-18 15:29:55 net_addr_v4_add: <IPV4>/19 dev tun0
2024-05-18 15:29:55 Data Channel: cipher 'AES-256-CBC', auth 'SHA512', compression: 'lzo'
2024-05-18 15:29:55 Timers: ping 10, ping-restart 120
2024-05-18 15:29:59 net_route_v4_add: <IPV4>/28 via <IPV4> dev [NULL] table 0 metric -1
2024-05-18 15:29:59 Initialization Sequence Completed

:tada: YAY

2024-05-18 15:29:59 Initialization Sequence Completed

TL;DR

Check logging directly from the ovpn client, and see what exact error is thrown. I havenā€™t read the OpenSSL release notes, but my guess is that algorithm support has become stricter and they want to be sure youā€™re conscious of it :slight_smile:

:hammer_and_wrench: Fix:

add the following key values to your (in my case) ovpn file:

tls-cipher DEFAULT:@SECLEVEL=0 #Old workaround
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
# The algorithm is a representation of what works for me,
# this doesn't mean the server you're tunneling to, uses the same algorithm.
# Check the openvpn logging or your server's requirements
1 Like

Im using Eddie Client (which is based on OpenVPN) no problems at all here after the update.

Probably you guys running into issues, because you didnā€™t updated in TTY and had the VPN files in use? :man_shrugging:

Tried it but doesnā€™t help. As said, initiating the VPN from command line works, but only when doing it with ā€œsudoā€. Seems like the network manager doesnā€™t has the correct rights to access or create a tun interface (see above).

@Kobold
This problem lies within the older algorithm. If the server uses an weaker algorithm to initiate packet encryption, OpenSSL wonā€™t allow it (anymore). When the server is just well maintained, while mine is poorly :sweat_smile:, then thereā€™s no issue :slight_smile:

@gschafra
OpenVPN just doesnā€™t have the permission to do modify stuff that requires root privileges like:

  • create and manage network interfaces, such as tun0 or tap0
  • modify the routing table
  • bind privileged ports

NetworkManager is a system service, which can make use of OpenVPN with NetworkManager privileges.

Based on the error in your logs I would say itā€™s a similar issue:

Mai 16 09:49:33 tazdevil nm-openvpn[20638]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.

Post your redacted ovpn config and/or error that is thrown after the new config, then we can have a closer look.

The same error occurred for me. After the big update at 2024-05-13, i couldnā€™t connect to the Sophos UTM-9 Firewall VPN. The small update at 2024-05-18 didnā€™t fix it. My Journal also says:

Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: OpenVPN 2.6.10 [git:makepkg/ba0f62fb950c56a0+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Mar 20 2024
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: library versions: OpenSSL 3.3.0 9 Apr 2024, LZO 2.10
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: DCO version: N/A
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.xx.xxx:4445
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: UDPv4 link local: (not bound)
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: UDPv4 link remote: [AF_INET]xx.xxx.xx.xx:4445
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mai 21 08:11:08 esprimod738 nm-openvpn[1917]: [remote.sekae.de] Peer Connection Initiated with [AF_INET]xx.xxx.xx.xx:4445
Mai 21 08:11:10 esprimod738 nm-openvpn[1917]: OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('AES-256-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to connect to this server.
Mai 21 08:11:10 esprimod738 nm-openvpn[1917]: ERROR: Failed to apply push options
Mai 21 08:11:10 esprimod738 nm-openvpn[1917]: Failed to open tun/tap interface
Mai 21 08:11:10 esprimod738 nm-openvpn[1917]: SIGUSR1[soft,process-push-msg-failed] received, process restarting
Mai 21 08:11:11 esprimod738 nm-openvpn[1917]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mai 21 08:11:11 esprimod738 nm-openvpn[1917]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

It is clear, that i have to add the dropped cipher, but i donā€™t know WHERE to add this?

It seems there are no GUI options to add data-ciphers. Even nm-connection-editor doesnā€™t show this option.

nmcli might be able to add it, but it seems easier to simply edit the .nmconnection file. This is not recommended and you might need to restart NetworkManager after you changes the file.

The News file, lists * Set data-ciphers option with chosen cipher. for 1.10.2, but it did not worked with a connection to my old test server.

I added to the .nmconnection file the data-ciphers option to [VPN] section, like this:

[connection]
...
[vpn]
...
cipher=AES-256-CBC
data-ciphers=AES-256-CBC
...
[vpn-secrets]
...
1 Like

Thanks xabbu,

as you mentioned, i added

data-ciphers=AES-256-CBC

to the

/etc/NetworkManager/system-connections/<name of my vpn server>_openvpn.nmconnection

and rebootet the computer. After that, everything works fine.

Confirmed that this works on KDE/Plasma 6 and XFCE.

After editing the file /etc/NetworkManager/system-connections/<name of my vpn server connection>.nmconnection just do

sudo systemctl restart NetworkManager.service

afterwards just connect as normal as per before. No need to reboot.

Caution: The issue is really not with openssl nor with NetworkManager but rather with whoever controls the OpenVPN server. If they upgrade to use the current standardized ciphers then this wouldnā€™t occur. @Seabass has captured it perfectly above ā†’

Thus our solution is just a work-around to connect to a VPN server that is no longer considered secure.

Unfortunately thereā€™s a gotcha here, If you edit the configuration using the GUI then
the data-ciphers=AES-256-CBC manual entry is overwritten :sob:

So either make sure you dontā€™t edit using the GUI or pester the VPN server admin to update :stuck_out_tongue_winking_eye:

3 Likes

I recently updated openvpn and networkmanager-openvpn to their currently stable versions, and I had this issue too.

Editing the .nmconnection works (thanks xabbu!) but it feels like a hack.

I tried multiple openvpn config options but I was still getting OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher to --data-ciphers... in my nm-openvpn logs. Eventually I realized that using the config import tool of nm-connection-editor GUI would never put out a data-ciphers option. It makes no difference if itā€™s set in the config file, or set in the ā€˜Advanced settingsā€™ right after the file is imported (note that this advanced menu isnā€™t available anymore after the import).

I reported the issue here (cannot insert a link for some reason): https:// gitlab dot gnome dot org/GNOME/network-manager-applet/-/issues/196