Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Why is OpenVPN client unstable? What is the work-around for it?

    General pfSense Questions
    3
    6
    8.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      torontob
      last edited by

      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,

      1 Reply Last reply Reply Quote 0
      • N
        Nachtfalke
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • T
          torontob
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • T
              torontob
              last edited by

              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

              1 Reply Last reply Reply Quote 0
              • T
                torontob
                last edited by

                @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

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.