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

    Once a week OpenVPN tunnel drop in 2.2.[x]

    Scheduled Pinned Locked Moved OpenVPN
    2 Posts 1 Posters 672 Views
    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.
    • S Offline
      scm
      last edited by

      Since updating from 2.1.5 to 2.2.1 at two different locations (one is now at 2.2.2), each respective OpenVPN tunnel to our HQ has stopped passing traffic almost like clockwork once a week on Sunday, although both sides still show the connection being up (by green arrow). The fix right now is to log into these two remote firewalls and restart the OpenVPN client service - this brings it back quickly. The HQ firewall (still at version 2.1.5) is set up as the OpenVPN server and the remote locations clients.

      These are the client configs:

      site 1 client

      dev ovpnc3
      dev-type tun
      tun-ipv6
      dev-node /dev/tun3
      writepid /var/run/openvpn_client3.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-128-CBC
      auth SHA1
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local [public IP redacted]
      lport 0
      management /var/etc/openvpn/client3.sock unix
      remote [route 192.168.1.0 255.255.255.0
      secret /var/etc/openvpn/server8.secret
      comp-lzo

      [b]site 2 client[/b]

      dev ovpnc2
      verb 1
      dev-type tun
      tun-ipv6
      dev-node /dev/tun2
      writepid /var/run/openvpn_client2.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-128-CBC
      auth SHA1
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local [public IP redacted]
      lport 0
      management /var/etc/openvpn/client2.sock unix
      remote [url] 1190
      ifconfig 172.22.1.30 172.22.1.29
      route 192.168.0.0 255.255.255.0
      secret /var/etc/openvpn/client2.secret
      comp-lzo yes
      resolv-retry infinite

      [b]site 2 server[/b]

      dev ovpns10
      dev-type tun
      tun-ipv6
      dev-node /dev/tun10
      writepid /var/run/openvpn_server10.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-128-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local 127.0.0.1
      ifconfig 172.22.1.29 172.22.1.30
      lport 1190
      management /var/etc/openvpn/server10.sock unix
      push "route 192.168.0.0 255.255.255.0"
      route 192.168.9.0 255.255.255.0
      secret /var/etc/openvpn/server10.secret
      comp-lzo

      Could this have anything to do with the server still being at 2.1.5? Any help you could offer would be appreciated.  :D
      [/url]" target="_blank"> 1192
      ifconfig 172.22.1.22 172.22.1.21
      route 192.168.0.0 255.255.255.0
      secret /var/etc/openvpn/client3.secret
      comp-lzo adaptive
      resolv-retry infinite

      site 1 server

      dev ovpns8
      dev-type tun
      tun-ipv6
      dev-node /dev/tun8
      writepid /var/run/openvpn_server8.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-128-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local 127.0.0.1
      ifconfig 172.22.1.21 172.22.1.22
      lport 1192
      management /var/etc/openvpn/server8.sock unix
      push "route 192.168.0.0 255.255.255.0"
      route 192.168.1.0 255.255.255.0
      secret /var/etc/openvpn/server8.secret
      comp-lzo

      site 2 client

      dev ovpnc2
      verb 1
      dev-type tun
      tun-ipv6
      dev-node /dev/tun2
      writepid /var/run/openvpn_client2.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-128-CBC
      auth SHA1
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local [public IP redacted]
      lport 0
      management /var/etc/openvpn/client2.sock unix
      remote](1192<br />ifconfig 172.22.1.22 172.22.1.21<br />route 192.168.0.0 255.255.255.0<br />secret /var/etc/openvpn/client3.secret<br />comp-lzo adaptive<br />resolv-retry infinite<br /><br />[b]site 1 server[/b]<br /><br />dev ovpns8<br />dev-type tun<br />tun-ipv6<br />dev-node /dev/tun8<br />writepid /var/run/openvpn_server8.pid<br />#user nobody<br />#group nobody<br />script-security 3<br />daemon<br />keepalive 10 60<br />ping-timer-rem<br />persist-tun<br />persist-key<br />proto udp<br />cipher AES-128-CBC<br />up /usr/local/sbin/ovpn-linkup<br />down /usr/local/sbin/ovpn-linkdown<br />local 127.0.0.1<br />ifconfig 172.22.1.21 172.22.1.22<br />lport 1192<br />management /var/etc/openvpn/server8.sock unix<br />push ) [route 192.168.9.0 255.255.255.0
      secret /var/etc/openvpn/server10.secret
      comp-lzo

      Could this have anything to do with the server still being at 2.1.5? Any help you could offer would be appreciated.  :D
      " target="_blank"> 1190
      ifconfig 172.22.1.30 172.22.1.29
      route 192.168.0.0 255.255.255.0
      secret /var/etc/openvpn/client2.secret
      comp-lzo yes
      resolv-retry infinite

      site 2 server

      dev ovpns10
      dev-type tun
      tun-ipv6
      dev-node /dev/tun10
      writepid /var/run/openvpn_server10.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-128-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local 127.0.0.1
      ifconfig 172.22.1.29 172.22.1.30
      lport 1190
      management /var/etc/openvpn/server10.sock unix
      push "route 192.168.0.0 255.255.255.0"
      route 192.168.9.0 255.255.255.0
      secret /var/etc/openvpn/server10.secret
      comp-lzo

      Could this have anything to do with the server still being at 2.1.5? Any help you could offer would be appreciated.  :D](1190<br />ifconfig 172.22.1.30 172.22.1.29<br />route 192.168.0.0 255.255.255.0<br />secret /var/etc/openvpn/client2.secret<br />comp-lzo yes<br />resolv-retry infinite<br /><br />[b]site 2 server[/b] <br /><br />dev ovpns10<br />dev-type tun<br />tun-ipv6<br />dev-node /dev/tun10<br />writepid /var/run/openvpn_server10.pid<br />#user nobody<br />#group nobody<br />script-security 3<br />daemon<br />keepalive 10 60<br />ping-timer-rem<br />persist-tun<br />persist-key<br />proto udp<br />cipher AES-128-CBC<br />up /usr/local/sbin/ovpn-linkup<br />down /usr/local/sbin/ovpn-linkdown<br />local 127.0.0.1<br />ifconfig 172.22.1.29 172.22.1.30<br />lport 1190<br />management /var/etc/openvpn/server10.sock unix<br />push )

      1 Reply Last reply Reply Quote 0
      • S Offline
        scm
        last edited by

        Fixed.

        It appears I've figured out what was causing this, but not exactly why it was causing it.

        The two locations having this problem each use their own 4G router as a backup WAN (set as tier 2 in a failover group that the LAN points to), and the router is set to automatically reboot every Sunday morning. When I tested by initiating a reboot of the 4G router with a running ping to the remote LAN network, sure enough the tunnel stopped passing traffic about 30 seconds after beginning the reboot. This happened reliably when trying it for both locations. Once again, going into the remote firewall and restarting the OpenVPN client connection brought it back.

        So now it's a curiousity why bouncing a tier 2 and not-currently-active WAN connection would break an OpenVPN tunnel.

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