Both the old server and new server used their respective standard OpenVPN packages from the Debian repository. So I guess there must be some change to parameters I need on either client or server. This is my server setup:
Code: Select all
port 1194
dev tun
proto udp
user nobody
group nogroup
persist-key
persist-tun
mute-replay-warnings
status /var/log/openvpn/status.log
log-append /var/log/openvpn/openvpn.log
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.15.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-128-CBC
comp-lzo
verb 4
mute 20
Code: Select all
client
dev tun
proto udp
remote myserver.com 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
log-append /var/log/openvpn/myserver.log
mute-replay-warnings
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
;remote-cert-tls server
ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 3
mute 20
Code: Select all
Wed Aug 9 14:14:40 2017 us=525289 265 variation(s) on previous 20 message(s) suppressed by --mute
Wed Aug 9 14:14:40 2017 us=525297 OpenVPN 2.4.0 [git:master/d73f7253d939e293+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 22 2017
Wed Aug 9 14:14:40 2017 us=525316 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Wed Aug 9 14:14:40 2017 us=539472 Diffie-Hellman initialized with 2048 bit key
Wed Aug 9 14:14:40 2017 us=540384 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 9 14:14:40 2017 us=540404 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
...
Wed Aug 9 20:50:19 2017 us=116762 client/<my ip>:41968 SENT CONTROL [client]: 'PUSH_REPLY,route 10.15.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.15.0.6 10.15.0.5,peer-id 0' (status=1)
Wed Aug 9 20:54:19 2017 us=668595 client/<my ip>:41968 [kenneth] Inactivity timeout (--ping-restart), restarting
Wed Aug 9 20:54:19 2017 us=668695 client/<my ip>:41968 SIGUSR1[soft,ping-restart] received, client-instance restarting
Code: Select all
Wed Aug 9 14:23:17 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Wed Aug 9 14:23:17 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Wed Aug 9 14:23:17 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 9 14:23:17 2017 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Wed Aug 9 14:23:17 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 9 14:23:17 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 9 14:23:17 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Aug 9 14:23:18 2017 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Wed Aug 9 14:23:18 2017 UDPv4 link local: [undef]
Wed Aug 9 14:23:18 2017 UDPv4 link remote: [AF_INET]<server ip>:1194
Wed Aug 9 14:23:19 2017 TLS: Initial packet from [AF_INET]<server ip>:1194, sid=610f0042 301cf4cb
...
Wed Aug 9 20:49:43 2017 35 variation(s) on previous 20 message(s) suppressed by --mute
Wed Aug 9 20:49:43 2017 [server] Inactivity timeout (--ping-restart), restarting
Wed Aug 9 20:49:43 2017 SIGUSR1[soft,ping-restart] received, process restarting
Wed Aug 9 20:49:43 2017 Restart pause, 2 second(s)
Wed Aug 9 20:49:45 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 9 20:49:45 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Aug 9 20:49:45 2017 UDPv4 link local: [undef]
Wed Aug 9 20:49:45 2017 UDPv4 link remote: [AF_INET]<server ip>:1194
Wed Aug 9 20:49:45 2017 TLS: Initial packet from [AF_INET]<server ip>:1194, sid=83469552 01a6ca99
Wed Aug 9 20:49:48 2017 PUSH: Received control message: 'PUSH_REPLY,route 10.15.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.15.0.6 10.15.0.5,peer-id 0'
Wed Aug 9 20:49:48 2017 OPTIONS IMPORT: timers and/or timeouts modified
Wed Aug 9 20:49:48 2017 OPTIONS IMPORT: --ifconfig/up options modified
Wed Aug 9 20:49:48 2017 OPTIONS IMPORT: route options modified
Wed Aug 9 20:49:48 2017 OPTIONS IMPORT: peer-id set
Wed Aug 9 20:49:48 2017 OPTIONS IMPORT: adjusting link_mtu to 1561
Wed Aug 9 20:49:48 2017 Preserving previous TUN/TAP instance: tun1
Wed Aug 9 20:49:48 2017 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Wed Aug 9 20:49:48 2017 /sbin/ip route del 10.15.0.0/24
RTNETLINK answers: Operation not permitted
Wed Aug 9 20:49:48 2017 ERROR: Linux route delete command failed: external program exited with error status: 2
Wed Aug 9 20:49:48 2017 Closing TUN/TAP interface
Wed Aug 9 20:49:48 2017 /sbin/ip addr del dev tun1 local 10.15.0.6 peer 10.15.0.5
RTNETLINK answers: Operation not permitted
Wed Aug 9 20:49:48 2017 Linux ip addr del failed: external program exited with error status: 2
Wed Aug 9 20:49:48 2017 /etc/openvpn/update-resolv-conf tun1 1500 1561 10.15.0.6 10.15.0.5 init
Wed Aug 9 20:49:49 2017 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=wlp3s0 HWADDR=5c:51:4f:2b:e6:16
Wed Aug 9 20:49:49 2017 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
Wed Aug 9 20:49:49 2017 Exiting due to fatal error
In the meantime, I have created a cronjob on the clients to check if openvpn is running, and restarting the service if not. It seems like the problem only occur on the clients if no data is transmitted for some time.