OpenVPN periodically disconnecting? Why? How to fix?
-
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.
-
no ideas, anybody?
-
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?
-
@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.
-
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.
-
@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 lostThis 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
-
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).
-
@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?
-
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.