OpenVPN periodically disconnecting? Why? How to fix?

elementalwindx

Jul 18 13:26:06	openvpn	23915	Initialization Sequence Completed
Jul 18 13:26:05	openvpn	23915	Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Jul 18 13:26:05	openvpn	23915	TCPv4_CLIENT link remote: [AF_INET]x.x.x.x:1194
Jul 18 13:26:05	openvpn	23915	TCPv4_CLIENT link local (bound): [AF_INET]y.y.y.y
Jul 18 13:26:05	openvpn	23915	TCP connection established with [AF_INET]x.x.x.x:1194
Jul 18 13:26:01	openvpn	23915	Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
Jul 18 13:26:01	openvpn	23915	/usr/local/sbin/ovpn-linkup ovpnc2 1500 1563 10.0.3.2 10.0.3.1 init
Jul 18 13:26:01	openvpn	23915	/sbin/ifconfig ovpnc2 10.0.3.2 10.0.3.1 mtu 1500 netmask 255.255.255.255 up
Jul 18 13:26:01	openvpn	23915	do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jul 18 13:26:01	openvpn	23915	TUN/TAP device /dev/tun2 opened
Jul 18 13:26:01	openvpn	23915	TUN/TAP device ovpnc2 exists previously, keep at program end
Jul 18 13:26:01	openvpn	23915	Initializing OpenSSL support for engine 'cryptodev'
Jul 18 13:26:01	openvpn	23915	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 18 13:26:01	openvpn	23717	library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Jul 18 13:26:01	openvpn	23717	OpenVPN 2.3.11 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on May 16 2016
Jul 18 13:26:01	openvpn	14929	SIGTERM[hard,] received, process exiting
Jul 18 13:26:01	openvpn	14929	/usr/local/sbin/ovpn-linkdown ovpnc2 1500 1563 10.0.3.2 10.0.3.1 init
Jul 18 13:26:01	openvpn	14929	event_wait : Interrupted system call (code=4)
Jul 18 12:46:31	openvpn	14929	Initialization Sequence Completed
Jul 18 12:46:29	openvpn	14929	Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Jul 18 12:46:29	openvpn	14929	TCPv4_CLIENT link remote: [AF_INET]x.x.x.x:1194
Jul 18 12:46:29	openvpn	14929	TCPv4_CLIENT link local (bound): [AF_INET]y.y.y.y
Jul 18 12:46:29	openvpn	14929	TCP connection established with [AF_INET]x.x.x.x:1194
Jul 18 12:46:14	openvpn	14929	TCP: connect to [AF_INET]x.x.x.x:1194 failed, will try again in 5 seconds: Operation timed out
Jul 18 12:46:04	openvpn	14929	Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
Jul 18 12:46:04	openvpn	14929	Preserving previous TUN/TAP instance: ovpnc2
Jul 18 12:46:04	openvpn	14929	Re-using pre-shared static key
Jul 18 12:46:04	openvpn	14929	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 18 12:45:59	openvpn	14929	SIGUSR1[soft,connection-reset] received, process restarting
Jul 18 12:45:59	openvpn	14929	Connection reset, restarting [0]
Jul 18 10:20:00	openvpn	14929	Initialization Sequence Completed
Jul 18 10:19:58	openvpn	14929	Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Jul 18 10:19:58	openvpn	14929	TCPv4_CLIENT link remote: [AF_INET]x.x.x.x:1194
Jul 18 10:19:58	openvpn	14929	TCPv4_CLIENT link local (bound): [AF_INET]
Jul 18 10:19:58	openvpn	14929	TCP connection established with [AF_INET]x.x.x.x:1194
Jul 18 10:19:57	openvpn	14929	Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
Jul 18 10:19:57	openvpn	14929	Preserving previous TUN/TAP instance: ovpnc2
Jul 18 10:19:57	openvpn	14929	Re-using pre-shared static key
Jul 18 10:19:57	openvpn	14929	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 18 10:19:52	openvpn	14929	SIGUSR1[soft,ping-restart] received, process restarting
Jul 18 10:19:52	openvpn	14929	Inactivity timeout (--ping-restart), restarting
Jul 18 04:55:31	openvpn	14929	Initialization Sequence Completed
Jul 18 04:55:29	openvpn	14929	Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Jul 18 04:55:29	openvpn	14929	TCPv4_CLIENT link remote: [AF_INET]x.x.x.x:1194
Jul 18 04:55:29	openvpn	14929	TCPv4_CLIENT link local (bound): [AF_INET]y.y.y.y
Jul 18 04:55:29	openvpn	14929	TCP connection established with [AF_INET]x.x.x.x:1194
Jul 18 04:55:28	openvpn	14929	Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
Jul 18 04:55:28	openvpn	14929	Preserving previous TUN/TAP instance: ovpnc2
Jul 18 04:55:28	openvpn	14929	Re-using pre-shared static key
Jul 18 04:55:28	openvpn	14929	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 18 04:55:23	openvpn	14929	SIGUSR1[soft,ping-restart] received, process restarting
Jul 18 04:55:23	openvpn	14929	Inactivity timeout (--ping-restart), restarting

For some unknown reason our VPN is dropping periodically. Any idea why this is happening? Thanks.

elementalwindx

no ideas, anybody?

cmb

You should use UDP rather than TCP unless you have no other option for some reason. Probably not in and of itself why it's disconnecting.

Part of it's from ping-restarts which means the client and server lost connectivity to each other. Part of it looks like a normal service restart, like what would happen if you have a dynamic IP WAN and it reconnects/updates its IP.

Correlate those times with the system log, anything happening there?

elementalwindx

@cmb:

You should use UDP rather than TCP unless you have no other option for some reason. Probably not in and of itself why it's disconnecting.

Part of it's from ping-restarts which means the client and server lost connectivity to each other. Part of it looks like a normal service restart, like what would happen if you have a dynamic IP WAN and it reconnects/updates its IP.

Correlate those times with the system log, anything happening there?

The system is showing uptimes of over a month. We are utilizing Panasonic VOIP phones over this VPN. Even doing that you would recommend UDP? Both are on static ip addresses, and it happens multiple times through the day so it shouldn't have to do with IP addresses. Not sure why the service would be randomly restarting itself.

Also to let you know this is a Hyper-V installation of pfsense on the newest version on both server and client side.

cmb

Yes, UDP is always preferable unless you're in a circumstance where it can't be used (UDP can't get between client and server). There's a reason VoIP uses UDP, as retransmissions are pointless, by the time it would be retransmitted the data is useless. TCP VPN would just result in out of order delivery of VoIP in the case of packet loss, which best case the phone and PBX just ignore since it's too old to be useful, but worst case sometimes makes VoIP phones and/or PBXes behave poorly.

Static IP WANs rules out the most common reason for a forced reconnection. Likely a connectivity issue between the two, or possibly something between the two dropping a TCP connection. Switching to UDP could prevent that from occurring if that is the case.

elementalwindx

@cmb:

Yes, UDP is always preferable unless you're in a circumstance where it can't be used (UDP can't get between client and server). There's a reason VoIP uses UDP, as retransmissions are pointless, by the time it would be retransmitted the data is useless. TCP VPN would just result in out of order delivery of VoIP in the case of packet loss, which best case the phone and PBX just ignore since it's too old to be useful, but worst case sometimes makes VoIP phones and/or PBXes behave poorly.

Static IP WANs rules out the most common reason for a forced reconnection. Likely a connectivity issue between the two, or possibly something between the two dropping a TCP connection. Switching to UDP could prevent that from occurring if that is the case.

I've changed it to UDP. I've set gateway monitoring to its default ip of the wan device itself (it use to be google dns). I can't think of anything else causing this :(

Jul 28 05:19:55 	openvpn 	72080 	Initialization Sequence Completed
Jul 28 05:19:54 	openvpn 	72080 	Peer Connection Initiated with [AF_INET]y.y.y.y:21153
Jul 28 05:19:42 	openvpn 	72080 	UDPv4 link remote: [undef]
Jul 28 05:19:42 	openvpn 	72080 	UDPv4 link local (bound): [AF_INET]x.x.x.x:1194
Jul 28 05:19:42 	openvpn 	72080 	Preserving previous TUN/TAP instance: ovpns1
Jul 28 05:19:42 	openvpn 	72080 	Re-using pre-shared static key
Jul 28 05:19:42 	openvpn 	72080 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 28 05:19:40 	openvpn 	72080 	SIGUSR1[soft,ping-restart] received, process restarting
Jul 28 05:19:40 	openvpn 	72080 	Inactivity timeout (--ping-restart), restarting
Jul 28 04:29:53 	openvpn 	72080 	Initialization Sequence Completed
Jul 28 04:29:53 	openvpn 	72080 	Peer Connection Initiated with [AF_INET]y.y.y.y:2155
Jul 28 04:29:52 	openvpn 	72080 	UDPv4 link remote: [undef]
Jul 28 04:29:52 	openvpn 	72080 	UDPv4 link local (bound): [AF_INET]x.x.x.x:1194
Jul 28 04:29:52 	openvpn 	72080 	Preserving previous TUN/TAP instance: ovpns1
Jul 28 04:29:52 	openvpn 	72080 	Re-using pre-shared static key
Jul 28 04:29:52 	openvpn 	72080 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 28 04:29:50 	openvpn 	72080 	SIGUSR1[soft,ping-restart] received, process restarting
Jul 28 04:29:50 	openvpn 	72080 	Inactivity timeout (--ping-restart), restarting
Jul 27 12:45:51 	openvpn 	72080 	Initialization Sequence Completed
Jul 27 12:45:50 	openvpn 	72080 	Peer Connection Initiated with [AF_INET]y.y.y.y:2155
Jul 27 12:45:44 	openvpn 	72080 	UDPv4 link remote: [undef]
Jul 27 12:45:44 	openvpn 	72080 	UDPv4 link local (bound): [AF_INET]x.x.x.x:1194
Jul 27 12:45:44 	openvpn 	72080 	Preserving previous TUN/TAP instance: ovpns1
Jul 27 12:45:44 	openvpn 	72080 	Re-using pre-shared static key
Jul 27 12:45:44 	openvpn 	72080 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 27 12:45:42 	openvpn 	72080 	SIGUSR1[soft,ping-restart] received, process restarting
Jul 27 12:45:42 	openvpn 	72080 	Inactivity timeout (--ping-restart), restarting

I've ran ping -t tests across the vpn, internet, and a local pc.

Local PC 0 packets lost
Internet 41 packets lost
VPN 68 packets lost

This tells me it must be due to my quality of internet.

Is there a way to tweak the timeout settings of the VPN so that it will not lose connection and try to reconnect? Yes the call quality is still going to suck at times, however at least the call won't be completely dropped. They drop when the vpn drops, despite immediately reconnecting.

Also I found this while googling. Think it may have some weight to it? If so, how do I remove that option?

https://www.privateinternetaccess.com/forum/discussion/8943/keeping-openvpn-tunnel-alive

cmb

That PIA thread is full of misguided info. I wouldn't recommend anything there.

The ping-restart happens because you get no traffic at all from the remote endpoint for 60 seconds. That's what drops the calls, not the VPN reconnecting after that minute has passed. It doesn't immediately reconnect every time either, there are gaps of several seconds at times where it's trying before succeeding (likely after connectivity between the sites comes back).

elementalwindx

@cmb:

That PIA thread is full of misguided info. I wouldn't recommend anything there.

The ping-restart happens because you get no traffic at all from the remote endpoint for 60 seconds. That's what drops the calls, not the VPN reconnecting after that minute has passed. It doesn't immediately reconnect every time either, there are gaps of several seconds at times where it's trying before succeeding (likely after connectivity between the sites comes back).

So there is no way to tune that at all?

cmb

There isn't, but there is also no point in tuning it. It's a symptom of the root connectivity problem, not the source of any problems. Nothing you change will fix connectivity issues.