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.conf
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
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.
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.
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.
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.
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.
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?
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