OpenVPN client reconnects every 15 minutes at the timeout?

There is a VDS server installed on it OpenVPN. Connect to customers on Windows and the router with Padavan firmware.
Connections are established properly, but the router reconnects every 15 minutes (no patterns, maybe 5, maybe 20, but on average every 15 minutes). In all cases, in the logs there is a line about reset connections on timeout.

Here is the log of the router:

Mar 29 12:41:09 openvpn-cli[4178]: [server] Inactivity timeout (--ping-restart), restarting
Mar 29 12:41:09 openvpn-cli[4178]: /sbin/route del -net 192.168.1.0 netmask 255.255.255.0
Mar 29 12:41:09 openvpn-cli[4178]: /sbin/route del -net 192.168.31.0 netmask 255.255.255.0
Mar 29 12:41:09 openvpn-cli[4178]: Closing TUN/TAP interface
Mar 29 12:41:09 openvpn-cli[4178]: /sbin/ifconfig tun0 0.0.0.0
Mar 29 12:41:09 openvpn-cli[4178]: ovpnc.script tun0 1500 1552 10.8.0.3 255.255.255.0 init
Mar 29 12:41:09 vpnc-script: tun0 down
Mar 29 12:41:09 openvpn-cli[4178]: SIGUSR1[soft,ping-restart] received, process restarting
Mar 29 12:41:09 openvpn-cli[4178]: Restart pause, 5 second(s)
Mar 29 12:41:14 openvpn-cli[4178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 29 12:41:14 openvpn-cli[4178]: TCP/UDP: Preserving recently used remote address: [AF_INET]X. X. X. X:1194
Mar 29 12:41:14 openvpn-cli[4178]: Socket Buffers: R=[155648->155648] S=[155648->155648]
Mar 29 12:41:14 openvpn-cli[4178]: UDP link local: (not bound)
Mar 29 12:41:14 openvpn-cli[4178]: UDP link remote: [AF_INET]X. X. X. X:1194
Mar 29 12:41:14 openvpn-cli[4178]: TLS: Initial packet from [AF_INET]X. X. X. X:1194, sid=f0ed64be bc5f2af5
Mar 29 12:41:14 openvpn-cli[4178]: VERIFY OK: depth=1, CN=ChangeMe
Mar 29 12:41:14 openvpn-cli[4178]: VERIFY KU OK
Mar 29 12:41:14 openvpn-cli[4178]: Validating certificate extended key usage
Mar 29 12:41:14 openvpn-cli[4178]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mar 29 12:41:14 openvpn-cli[4178]: VERIFY EKU OK
Mar 29 12:41:14 openvpn-cli[4178]: VERIFY OK: depth=0, CN=server
Mar 29 12:41:15 openvpn-cli[4178]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mar 29 12:41:15 openvpn-cli[4178]: [server] Peer Connection Initiated with [AF_INET]X. X. X. X:1194
Mar 29 12:41:16 openvpn-cli[4178]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mar 29 12:41:16 openvpn-cli[4178]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.31.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 5,ping-restart 180,ifconfig 10.8.0.3 255.255.255.0,peer-id 2,cipher AES-256-GCM'
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: timers and/or timeouts modified
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: --ifconfig/up options modified
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: route options modified
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: route-related options modified
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: peer-id set
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: link_mtu adjusting to 1624
Mar 29 12:41:16 openvpn-cli[4178]: OPTIONS IMPORT: data channel crypto options modified
Mar 29 12:41:16 openvpn-cli[4178]: Data Channel: using negotiated cipher 'AES-256-GCM'
Mar 29 12:41:16 openvpn-cli[4178]: Outgoing Channel Data: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 29 12:41:16 openvpn-cli[4178]: Incoming Channel Data: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 29 12:41:16 openvpn-cli[4178]: TUN/TAP device tun0 opened
Mar 29 12:41:16 openvpn-cli[4178]: TUN/TAP TX queue length set to 100
Mar 29 12:41:16 openvpn-cli[4178]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mar 29 12:41:16 openvpn-cli[4178]: /sbin/ifconfig tun0 10.8.0.3 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Mar 29 12:41:16 openvpn-cli[4178]: ovpnc.script tun0 1500 1552 10.8.0.3 255.255.255.0 init
Mar 29 12:41:16 vpnc-script: tun0 up
Mar 29 12:41:16 openvpn-cli[4178]: /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.1
Mar 29 12:41:16 openvpn-cli[4178]: /sbin/route add -net 192.168.31.0 netmask 255.255.255.0 gw 10.8.0.1
Mar 29 12:41:16 openvpn-cli[4178]: Initialization Sequence Completed
Mar 29 12:55:56 openvpn-cli[4178]: [server] Inactivity timeout (--ping-restart), restarting


Server logs:


Fri Mar 29 12:41:15 2019 Y. Y. Y. Y:2312 TLS: Initial packet from [AF_INET]Y. Y. Y. Y:2312 sid=611c4a72 ac01b3c8
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 VERIFY OK: depth=1, CN=ChangeMe
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 VERIFY OK: depth=0, CN=client-rx
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_VER=2.4.4
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_PLAT=linux
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_PROTO=2
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_NCP=2
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_LZ4=1
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_LZ4v2=1
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_LZO=1
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_COMP_STUB=1
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_COMP_STUBv2=1
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 peer info: IV_TCPNL=1
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Mar 29 12:41:16 2019 Y. Y. Y. Y:2312 [client-rx] Peer Connection Initiated with [AF_INET]Y. Y. Y. Y:2312
Fri Mar 29 12:41:16 2019 MULTI: new connection by client 'client rx' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Fri Mar 29 12:41:16 2019 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/client-rx
Fri Mar 29 12:41:16 2019 MULTI_sva: pool returned IPv4=10.8.0.3, IPv6=(Not enabled)
Fri Mar 29 12:41:16 2019 MULTI: Learn: 10.8.0.3 -> client-rx/Y. Y. Y. Y:2312
Fri Mar 29 12:41:16 2019 MULTI: primary virtual IP for client-rx/Y. Y. Y. Y:2312: 10.8.0.3
Fri Mar 29 12:41:16 2019 MULTI: internal route 192.168.2.0/24 -> client-rx/Y. Y. Y. Y:2312
Fri Mar 29 12:41:16 2019 MULTI: Learn: 192.168.2.0/24 -> client-rx/Y. Y. Y. Y:2312
Fri Mar 29 12:41:16 2019 REMOVE PUSH ROUTE: 'route 192.168.2.0 255.255.255.0'
Fri Mar 29 12:41:17 2019 client-rx/Y. Y. Y. Y:2312 PUSH: Received control message: 'PUSH_REQUEST'
Fri Mar 29 12:41:17 2019 client-rx/Y. Y. Y. Y:2312 SENT CONTROL [client-rx]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.31.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 5,ping-restart 180,ifconfig 10.8.0.3 255.255.255.0,peer-id 2,cipher AES-256-GCM' (status=1)
Fri Mar 29 12:41:17 2019 client-rx/Y. Y. Y. Y:2312 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Mar 29 12:41:17 2019 client-rx/Y. Y. Y. Y:2312 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key



Client configuration:

5c9df49935cb4930271481.png

Settings on server:


port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir /etc/openvpn/ccd
client-to-client
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 192.168.31.0 255.255.255.0"
route 192.168.2.0 255.255.255.0
keepalive 5 180
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
crl-verify crl.pem


I don't need to put all traffic through the VPN, you only need access to the devices/networks. Now everything works as it should, only gets reconnect the router every 15 minutes, with the loss of Internet for all its customers for a minute. What can we do?

PS Every client connects with their certificates.
March 19th 20 at 09:10
2 answers
March 19th 20 at 09:12
router with Padavan firmware.

Suggest to contact the developer and try not to use asensbruk on important services.
March 19th 20 at 09:14
On the router, configure keepalive with the same values as on the server.
Tried, not working. Somewhere in man have found that ping and key exchange are not considered for traffic. I have configured the pings every 5 seconds and disconnection after 180 seconds if no reply. And the connection breaks and is generated again in 15 minutes. Can anything else tears the passage of those most pings, but not immediately, but after any time. - owen_Aufderh commented on March 19th 20 at 09:17
To automatically configure the keepalive on the clients on the server, add the following options:
push "ping 5"
push "ping-restart 90"
The client is ping-restart 90 to do in 2 times less than on the server (2nd argument in keepalive).
https://openvpn.net/community-resources/reference-... - Gerd commented on March 19th 20 at 09:20
This makes the command keepalive 5 180.
Here is an excerpt from the log of a client that he took:


Mar 29 12:41:16 openvpn-cli[4178]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.31.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 5,ping-restart 180,ifconfig 10.8.0.3 255.255.255.0,peer-id 2,cipher AES-256-GCM'
- owen_Aufderh commented on March 19th 20 at 09:23
Try to load the tunnel for a long time (at least external pings).
Will fall off during loading? - Gerd commented on March 19th 20 at 09:26
I don't even know how to load. I go to the router 1 client VPN address of the VPN network, include viewing of real-time traffic. The idea of the traffic goes through the tunnel, between the two, but after a time graph freezes after reconnecting restores the activity. On the chart at this time failure. - owen_Aufderh commented on March 19th 20 at 09:29
Try instead of keepalive on the server to use this set of directives:
ping 5
ping-restart 180
push "ping 5"
push "ping-restart 90"
- Gerd commented on March 19th 20 at 09:32
@owen_Aufderh,
The idea of the traffic goes through the tunnel, between the two, but after a time graph freezes after reconnecting restores the activity. On the chart at this time failure.

So the traffic really goes through the tunnel and so the cause of the fractures in keepalive.
Can the quality of communication floats? Let parallel ping Google from the router and watch the latency. - Gerd commented on March 19th 20 at 09:35
@Gerd, Allowed ping from the same network as the router. An hour of ping - an average of 45 MS., maximum 1082 milliseconds. It turns out that the network is available and does not tear connection.
Put in the OpenVPN settings on the router to direct all traffic through the VPN and reconnect stopped.
So here's how to do that the connection is not disconnected by timeout and did not send all traffic to VPN? - owen_Aufderh commented on March 19th 20 at 09:38
@owen_Aufderh, reconnection and should not be, that you have some kind of anomaly. Maybe this is a bug in version sewn into the router. Try updating the firmware. Look at the router config OpenVPN what happened.
Another option - set the VPN connection is not a router, and any computer and through it allow all VPN traffic. - Gerd commented on March 19th 20 at 09:41

Find more questions by tags OpenVPN