OpenVPN 2.6.6 on Fedora 39: How to fix your connectivity to legacy OpenVPN servers!

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 VersionServer side SettingsClient side VersionClient 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 defaultsOpenVPN 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 defaultsOpenVPN 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 defaultsOpenVPN 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 defaultsOpenVPN 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]

© GeekLabInfo OpenVPN 2.6.6 on Fedora 39: How to fix your connectivity to legacy OpenVPN servers! is a post from GeekLab.info. You are free to copy materials from GeekLab.info, but you are required to link back to http://www.geeklab.info

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

SELinux: Running OpenVPN on a different port

To allow OpenVPN to run on a different port than 1194, you'll need to tweak your SELinux permissions:
/usr/sbin/semanage port -a -t openvpn_port_t -p udp 61616
© GeekLabInfo
SELinux: Running OpenVPN on a different port is a post from GeekLab.info. You are free to copy materials from GeekLab.info, but you are required to link back to http://www.geeklab.info

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

OpenVPN: script failed: could not execute external program

I've been using the great VPN software OpenVPN for a long time now. I just love it. Today, I copied the configuration of my old router to my brand new Fedora 15 box, and suddenly it can't start anymore.

In the logs I found this message:
script failed: could not execute external program

What does that mean?
Is the 'up' script not found? It it in the wrong directory? I could not just find it. Until I hooked up my favourite debugger tool: strace. And look what I found there:
[pid 8273] execve("./up", ["./up", "vpn", "1500", "1576", "", "", "init"], [/* 14 vars */]) = -1 ENOEXEC (Exec format error)

Solution

What is the case? In older OpenVPN versions, scripts where run by system(3), which uses the shell to run scripts. Newer versions are more secure, and use execl/execve or something like that. That means that shell scripts must explicitly tell the sytem that they're to be run by the shell.

So, add the following line to the top of the script:
#!/bin/bash
And you're done.© GeekLabInfo
OpenVPN: script failed: could not execute external program is a post from GeekLab.info. You are free to copy materials from GeekLab.info, but you are required to link back to http://www.geeklab.info

1 Star2 Stars3 Stars4 Stars5 Stars (9 votes, average: 4.11 out of 5)
Loading...

Share one VPN connection

My personal Linux laptop is a real spider in the web. It's got OpenVPN connections to the office, to the datacenter, to serveral family members, etcetera. I love it. But sometimes, there are some tasks that Linux simply can't do, like running a vSphere client.

For those situations, I use the second (Windows) computer on my desk to perform those tasks. However, this computer does not have a VPN connection right to the place I'm connecting to.

Continue Reading…

© GeekLabInfo
Share one VPN connection is a post from GeekLab.info. You are free to copy materials from GeekLab.info, but you are required to link back to http://www.geeklab.info

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading...