ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

bjpp2523

Hello,

We recently upgraded from Ubuntu 16.04 to 20.04 and right after the upgrade OpenVPN stopped working.

The current version of OpenVPN we have is

OpenVPN 2.4.7 x86_64-pc-linux-gnu

Client Kernel / OS:

Linux xray 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Client log:

Tue Sep 13 13:05:17 2022 us=365059 TUN/TAP device tap0 opened
Tue Sep 13 13:05:17 2022 us=365085 TUN/TAP TX queue length set to 100
Tue Sep 13 13:05:17 2022 us=365098 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Sep 13 13:05:17 2022 us=365110 /sbin/ip link set dev tap0 up mtu 1500
Tue Sep 13 13:05:17 2022 us=366179 /sbin/ip addr add dev tap0 192.168.201.125/-1 broadcast 255.255.255.255
Error: any valid prefix is expected rather than "192.168.201.125/-1".
Tue Sep 13 13:05:17 2022 us=366952 Linux ip addr add failed: external program exited with error status: 1
Tue Sep 13 13:05:17 2022 us=366982 Exiting due to fatal error

Client ifconfig:

enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.232  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::baae:edff:fe3e:394f  prefixlen 64  scopeid 0x20<link>
        ether b8:ae:ed:3e:39:4f  txqueuelen 1000  (Ethernet)
        RX packets 34007  bytes 6631982 (6.6 MB)
        RX errors 0  dropped 6  overruns 0  frame 0
        TX packets 29363  bytes 6376064 (6.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1252  bytes 421843 (421.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1252  bytes 421843 (421.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Client /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp5s0
iface enp5s0 inet static
        address 192.168.100.232
        netmask 255.255.255.0
        gateway 192.168.100.1
        dns-nameservers 8.8.8.8

client
dev tap
;dev-node MyTap
proto tcp
;remote-random
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
;http-proxy-retry
;http-proxy [proxy server] [proxy port
;mute-replay-warnings
remote-cert-tls server
;tls-auth ta.key 1
;cipher x
comp-lzo
verb 10
;mute 20

Server Kernel / OS

Linux euler 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

;local a.b.c.d
proto tcp
dev tap
;dev-node MyTap
ca ca.crt
cert clonerserver.crt
key clonerserver.key
dh dh2048.pem
;topology subnet
server 192.168.201.0 255.255.255.0
ifconfig-pool-persist cloner-ipp.txt
;server-bridge
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push "redirect-gateway def1 bypass-dhcp"
client-to-client
;duplicate-cn
keepalive 10 120
;tls-auth ta.key 0
;cipher BF-CBC
;cipher AES-128-CBC
;cipher DES-EDE3-CBC
comp-lzo
;max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
;log openvpn.log
;log-append openvpn.log
verb 3
;mute 20
push "route 192.168.0.0 255.255.255.0"

TinCanTech

bjpp2523 wrote It was working perfectly before upgrading though

More by luck than judgement.

Please start here: https://forums.openvpn.net/viewtopic.php?t=22603

bjpp2523

TinCanTech wrote More by luck than judgement.

Yup. You're damn right.

I edited the original post and added more information of the client trying to connect. Aswell as the server, except logs.

TinCanTech

And you still have no idea what you have done wrong ?

What you should do is switch back to --dev tun

bjpp2523

TinCanTech wrote And you still have no idea what you have done wrong ?

Honestly, i don't.
At first i thought the problem would be having a client with a more updated version (OpenVPN 2.4.7) than the server (OpenVPN 2.3.10) but then i found other clients also with OpenVPN 2.4.7 connected to the same server.

bjpp2523

TinCanTech wrote What you should do is switch back to --dev tun

TUN mode has never been used. We've always used TAP.
We have around 10 clients (with OpenVPN 2.4.7 and 2.3.10) connected with TAP mode. Yes, i know you would ve thinking "Why you have clients still using 2.3.10?" which i would answer with "They're still on Ubuntu 16.04" and that would lead to another question "WHY NOT UPGRADE THOSE CLIENT'S OS?!" And... I know. That's something we're doing right now and that's why we faced the issue in this topic.

I've read that recent versions of OpenVPN only support TUN mode, which i've been suggesting to change to. Even though there are alot of changes that need to be done in many services that are currently running.

dazo

Just a follow up on "recent versions" and "TUN only".

Generally speaking, TUN is preferred. There are few use cases where TAP is the right or sane option - but TAP can be the only right option in some cases. But over the last 10+ years I've done OpenVPN setups and development, I've only seen a handful use cases for TAP. TUN gives lesser overhead (no Ethernet frames being passed back and forth over the tunnel) and it reduces broadcast noise and potential DHCP server conflicts - to mention a few benefits with TUN.

The OpenVPN 3 Core library, which the OpenVPN Connect clients are built on only supports TUN. The OpenVPN 3 Linux project has the same limitation. Android and iOS only supports TUN mode for VPN applications. Windows has a VPN API in newer Windows releases (Win 10 and newer, iirc), which also only supports TUN mode. Further the OpenVPN Data Channel Offload (DCO) drivers for Linux, Windows and FreeBSD will also only support TUN mode. DCO moves a lot of the cryptographic operations into the OS kernel, which can then process, decrypt and encrypt traffic much more efficiently - so the VPN tunnel gets a better throughput.

But TAP support will not disappear in the near or foreseeable future. OpenVPN 2.x releases will continue to support TAP mode as long as the virtual network driver (the "tun/tap driver") supports TAP mode. In practice, that will mean TAP will be supported on Linux and BSD using the well used "tun" driver (it supports TAP mode too). On Windows the tap-windows6 driver will also continue to support TAP mode. But there will be no Android/iOS support for TAP; that is an OS limitation.

All said, planning ahead to move to TUN mode will give you more advantages - in particular performance wise. And it will open the possibilities to move over to DCO later on as well. Just ensure you use AES-GCM based ciphers and do not enable compression, then you should be fairly well settled for the future. You should also plan to lower the --tun-mtu value as well; IIRC,I believe that will be reduced to 1420 with the OpenVPN 2.6 release.

bjpp2523

dazo wrote All said, planning ahead to move to TUN mode will give you more advantages - in particular performance wise. And it will open the possibilities to move over to DCO later on as well. Just ensure you use AES-GCM based ciphers and do not enable compression, then you should be fairly well settled for the future. You should also plan to lower the --tun-mtu value as well; IIRC,I believe that will be reduced to 1420 with the OpenVPN 2.6 release.

Thank you for the advice.
I will have to validate if all services running right now will still work with TUN.

Right now i managed to "bypass" the issue by renaming the ccd config file to something else.
However, we can't keep it like that. We need to assign a specific IP to this client.

Actual ccd config file:

ifconfig-push   192.168.201.125 192.168.201.1

I have to mention that other clients that were updated too to recent versions of Ubuntu and OpenVPN are not in the ccd dir. It's just this client that's having this issue. Other clients with fixed IPs are still using Ubuntu 16.04 and OpenVPN 2.3 or older, they all connect to the server with no problem, but we're sure we will face this same issue as soon as we upgrade them.

Still not sure about this :?

bjpp2523

I changed the ccd config file from:

ifconfig-push   192.168.201.125 192.168.201.1

to:

ifconfig-push   192.168.201.125 255.255.255.0

and that worked.

Other clients (with older OpenVPN versions) have conf files similar to the first one and they're working just fine. So, i believe this changed beetwen versions?

ordex

well old clients may have bugs and may "accidentally work". The best choice is to always check the manpage and see what it says about the provided arguments. There may have been some default settings that changed as well, affecting this directive