Hi everybody,
First, sorry for my english, this is not my native language.
Thank in advance to people who will take the time to read and try to help us.
We have an openvpn server since approximately 2 years. It is a virtual server with Centos 6.7 for OS. Since, we added 55-56 clients to our VPN. All those clients are replicated images of a Centos 6.7 machine. Our 4-5 last clients always mount a second tunnel to connect to our VPN and this slow down considerably their connection. Sometimes we succeed to delete the second tunnel but the problem appear on another client who worked well before.
All the clients machines have the same configuration. We have doing some experiences with the configuration on the server and the client side and we got some strange results.
The server config file :
port 1194
proto tcp-server
dev tun
ca keys/admin/ca.crt
cert keys/admin/server.crt
key keys/admin/server.key
dh keys/admin/dh2048.pem
server 14.68.0.0 255.255.255.0
crl-verify keys/admin/crl.pem
ifconfig-pool-persist servers/VPN/logs/ipp.txt
cipher BF-CBC
user nobody
group nobody
status servers/VPN/logs/openvpn-status.log
log-append servers/VPN/logs/openvpn.log
verb 3
mute 20
max-clients 150
tun-mtu 1500
local 192.168.23.101
management 127.0.0.1 8876
keepalive 5 30
client-config-dir /etc/openvpn/servers/VPN/ccd
tls-server
comp-lzo
persist-key
persist-tun
ccd-exclusive
mode server
push route 14.68.0.0 255.255.255.0
#duplicate-cn
The « duplicate-cn » parameters is put in comment because at reboot of the clients, with the problem, they can't connect to the VPN if it is active.
The client machine mounting a tun0 and a tun1. We try to delete the second tunnel with this command :
sudo ip link del tun1
The client mounts the tun1 again and again. If the client machine is started, we activate the « duplicate-cn » parameter on the server side, we restarts the openvpn service on it and then we can delete the second tunnel on the client. At the next reboot of the client it will can't connect to the VPN if we let the parameter active.
??? Strange isn't it?
Server side, OpenVPN is up to date since 3 months :
OpenVPN 2.3.10 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 4 2016
library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03
Not up to date on the client side, but at least 50 clients on 55-56 are ok:
OpenVPN 2.3.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 2 2014
library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.03
The clients config file :
client
proto tcp-client
dev tun
ca /etc/openvpn/key/ca.crt
dh /etc/openvpn/key/dh2048.pem
cert /etc/openvpn/key/vpn-crt.crt
key /etc/openvpn/key/vpn-key.key
remote ouradress.no-ip.ca 1194
cipher BF-CBC
verb 3
mute 20
tun-mtu 1500
keepalive 3 60
comp-lzo
persist-key
persist-tun
resolv-retry infinite
nobind
mute-replay-warnings
We will trying to update all clients, but we're not sure this will correct the problem. If someone has faced this kind of problem in the past and knew how to correct it, we will appreciate his help.
Thanks a lot
Frank
