Why is OpenVPN client unstable? What is the work-around for it?
-
Hi everyone,
I have noticed few times that if I use pfSense as OpenVPN client that it goes down and does not RECONNECT as it should. This mostly happens when I playing on the VPN server settings on a remote system. The OpenVPN client should attempt to connect for ever without any issues but it's not happening and users have to power recycle pfSense for it to work or someone should go to pfSense client and save it again so the tunnel restarts.
But this is really not nice as there could be some serious downtime and many support tickets…
So, my question is if there is something one can do to fix this? I am using SSL/TLS keys. Should I use a different mode? I have 4 pfSense routers and want to connect all. Should I use a different OpenVPN method to connect?
Or what is the best way to connect them together? I like to stay with OpenVPN though.
Thanks,
-
You could add this on client site:
keepalive 5 30
This will send a ping every 5 seconds. If there is no response for 30 seconds the client restarts the tunnel.
-
Nachtfalke,
I have this but it's no help:
persist-key; persist-tun; keepalive 10 120
Seems like a bug of some sort as the tunnel just stays down despite the "keepalive" parameter.
P.S. I have been hearing others complain of this issue on IRC channel as well. Maybe we can trace this and create a bug?
-
There's nothing unstable about OpenVPN client, it's one of the most widely used things. You have some kind of problem that isn't a bug, but no telling from that description what that might be.
-
cmb, thanks for weighing in.
I know that OpenVPN is very solid and this happens only once in a while when I am playing with VPN Server side. The client just doesn't re-attempt to connect.
When this happens next, what commands should I run on client side to find out what the issue is?
Thanks
-
@cmb:
There's nothing unstable about OpenVPN client, it's one of the most widely used things. You have some kind of problem that isn't a bug, but no telling from that description what that might be.
cmb, I had the WAN disconnected for 24 hours and now that I reconnected WAN the OpenVPN client didn't come up. I think I have nailed the problem to be with OpenVPN exiting when there is no WAN connection - This shouldn't happen and OpeVPN client should keep trying or it should be smart enough to come up the moment there is a WAN connection detected again. So, something is failing here. Following is the log:
[b]Mar 3 22:43:48 openvpn[39786]: SIGTERM[hard,] received, process exiting Mar 3 22:43:48 openvpn[62930]: UDPv4 link local (bound): [AF_INET]192.168.254.10:47383 Mar 3 22:43:48 openvpn[62930]: UDPv4 link remote: [undef] Mar 3 22:43:48 openvpn[63453]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 6 2012 Mar 3 22:43:48 openvpn[63453]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 3 22:43:48 openvpn[63453]: LZO compression initialized Mar 3 22:43:48 openvpn[63453]: TUN/TAP device /dev/tun1 opened Mar 3 22:43:48 openvpn[63453]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mar 3 22:43:48 openvpn[63453]: /sbin/ifconfig ovpnc1 172.18.18.2 172.18.18.1 mtu 1500 netmask 255.255.255.255 up Mar 3 22:43:48 openvpn[63453]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1561 172.18.18.2 172.18.18.1 init Mar 3 22:43:48 openvpn[4443]: UDPv4 link local (bound): [AF_INET]192.168.254.10 Mar 3 22:43:48 openvpn[4443]: UDPv4 link remote: [AF_INET]65.64.64.64:54344 Mar 3 22:43:48 openvpn[4443]: Peer Connection Initiated with [AF_INET]65.64.64.64:54344 Mar 3 22:43:49 openvpn[4443]: Initialization Sequence Completed Mar 4 09:32:24 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:25 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:26 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:27 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:28 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:29 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:30 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:31 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:32 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:33 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:34 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:35 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:36 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:37 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:38 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:39 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:40 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:41 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:42 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:43 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:44 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:45 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:46 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:47 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:48 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:49 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:50 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:51 openvpn[4443]: write UDPv4: No route to host (code=65) Mar 4 09:32:52 openvpn[4443]: Inactivity timeout (--ping-restart), restarting Mar 4 09:32:52 openvpn[4443]: SIGUSR1[soft,ping-restart] received, process restarting Mar 4 09:32:54 openvpn[4443]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 4 09:32:54 openvpn[4443]: Re-using pre-shared static key Mar 4 09:32:54 openvpn[4443]: LZO compression initialized Mar 4 09:32:54 openvpn[4443]: TCP/UDP: Socket bind failed on local address [AF_INET]192.168.254.10: Can't assign requested address Mar 4 09:32:54 openvpn[4443]: Exiting Mar 4 09:32:54 openvpn[4443]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1561 172.18.18.2 172.18.18.1 init[/b]
List of process running at this moment as it might be relevant per this link = https://forums.openvpn.net/topic8933.html :
$ top last pid: 25694; load averages: 0.00, 0.00, 0.00 up 0+22:43:15 19:40:08 34 processes: 1 running, 33 sleeping Mem: 39M Active, 24M Inact, 41M Wired, 8K Cache, 34M Buf, 130M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 24839 root 1 46 0 36564K 24408K piperd 0:49 1.95% php 262 root 1 76 20 3408K 1208K kqread 3:25 0.00% check_reload_status 466 root 1 76 20 3656K 1460K wait 1:06 0.00% sh 48841 root 1 64 20 6080K 6104K select 0:15 0.00% ntpd 24156 root 1 44 0 8764K 6628K kqread 0:08 0.00% lighttpd 32953 dhcpd 1 44 0 8436K 5688K select 0:07 0.00% dhcpd 62930 root 1 64 20 5116K 3304K select 0:05 0.00% openvpn 33857 nobody 1 44 0 5564K 2552K select 0:02 0.00% dnsmasq 16616 root 1 44 0 5912K 2368K bpf 0:02 0.00% tcpdump 24408 root 1 46 0 35540K 19848K accept 0:02 0.00% php 16411 root 1 44 0 4956K 2436K select 0:01 0.00% syslogd 48534 root 1 64 20 3316K 1352K select 0:01 0.00% apinger 16778 root 1 44 0 3316K 904K piperd 0:00 0.00% logger 49678 root 1 44 0 3408K 1388K nanslp 0:00 0.00% cron 54249 root 1 71 0 3316K 1040K nanslp 0:00 0.00% minicron 17024 root 1 44 0 3436K 1444K select 0:00 0.00% inetd 63848 root 1 76 0 3688K 1576K wait 0:00 0.00% login 282 root 1 44 0 1888K 532K select 0:00 0.00% devd
***The only other VPN process on this pfSense is a VPN server.
It seems like once WAN is connected some script is not notifying OpenVPN tunnel to restart so it just stays stopped.
***I think this issue is closely related to this issue: http://forum.pfsense.org/index.php/topic,2785.30.html
Thanks