Last week, Red Hat published their latest and greatest Fedora version, number 39. That means Fedora 38 will still be supported for about half a year. Fedora 37 even has nog more than a few more weeks of support left. So over the weekend, I updated my laptop. First I backupped my whole system to a USB stick and then updated using the well-known formula:
sudo dnf-y update && \sudo dnf -y install dnf-plugin-system-upgrade && \sudo dnf system-upgrade download –releasever=39 && \sudo dnf system-upgrade reboot
Updating was a pretty smooth operation. But today, when I wanted to login to my servers in the datacenter, I found that OpenVPN could not connect anymore. While the configuration file hadn't changed even one letter. Time to investigate.
Problem 1: Ciphers
First, I found this message in the logs:
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.
The --data-ciphers option is something new to OpenVPN 2.5 and in version 2.6 it defaults to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305. Because AES-256-CBC is not in there, OpenVPN cannot setup encryption anymore. To fix this, I added:
--data-ciphers AES-256-CBC:AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
Problem 2: MTU
Then I found a message:
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1590', remote='link-mtu 1622'
Option inconsistency warnings triggering disconnect due to --opt-verify
SENT CONTROL [mekker]: 'AUTH_FAILED' (status=1)
I've seen both warning-messages combined, but also each separate, with dozens of different numbers. And always they were followed by a "opt-verify" and a AUTH_FAILED message. For me, the big solution was to fiddle a bit with the --tun-mtu option. Please note that the signature of this option used to be:
--tun-mtu n = Take the TUN device MTU to be n and derive the link MTU from it (default=1500).
But is now:
--tun-mtu args = tun-mtu [tun-mtu] [occ-mtu]
In my specific situation, I got all connections working using the following settings:
| Server side Version | Server side Settings | Client side Version | Client side Settings |
| OpenVPN 2.4.7 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10 Running on a Raspbian 10.2 device | no mtu settings, just defaults | OpenVPN 2.6.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] library versions: OpenSSL 3.1.1 30 May 2023, LZO 2.10 | --tun-mtu 1500 1532 |
| OpenVPN 2.5.9 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 16 2023 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10 Running on AlmaLinux 9.2 | no mtu settings, just defaults | OpenVPN 2.6.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] library versions: OpenSSL 3.1.1 30 May 2023, LZO 2.10 | --tun-mtu 1500 1532 |
| OpenVPN 2.4.9 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2020 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03 Running on CentOS 6.10 | no mtu settings, just defaults | OpenVPN 2.6.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] library versions: OpenSSL 3.1.1 30 May 2023, LZO 2.10 | --tun-mtu 1500 1500 |
| OpenVPN 2.4.7 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 22 2022 library versions: OpenSSL 1.0.2u 20 Dec 2019, LZO 2.08 Running on a Ubiquiti EdgeRouter 12P | no mtu settings, just defaults | OpenVPN 2.6.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] library versions: OpenSSL 3.1.1 30 May 2023, LZO 2.10 | [yet to be tested] |
(No Ratings Yet)
Loading...