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


Log in to reply