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

    Openvpn s2s automatic reconnection after link loss?

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 1.7k 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.
    • K
      klajosh2
      last edited by

      Hi,

      I have 2 locations both locations have leased line and adsl connectons.
      I setup 4 openvpn tunnels between these 2 sites.
      site1_ll -> site2_ll
      site1_ll -> site2_adsl
      site1_adsl -> site2_ll
      site1_adsl -> site2_adsl

      I notice when a connection dies (this problem is mainly with adsl) and recovers the openvpn tunnel does not recover.
      The service of the openvpn tunnel connection does not run and if I manually start it I got this error:

      May 23 11:44:54 	openvpn[72524]: OpenVPN 2.3.2 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
      May 23 11:44:54 	openvpn[72524]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
      May 23 11:44:54 	openvpn[72524]: TUN/TAP device ovpns4 exists previously, keep at program end
      May 23 11:44:54 	openvpn[72524]: TUN/TAP device /dev/tun4 opened
      May 23 11:44:54 	openvpn[72524]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
      May 23 11:44:54 	openvpn[72524]: /sbin/ifconfig ovpns4 172.16.2.33 172.16.2.34 mtu 1500 netmask 255.255.255.255 up
      May 23 11:44:54 	openvpn[72524]: FreeBSD ifconfig failed: external program exited with error status: 1
      May 23 11:44:54 	openvpn[72524]: Exiting due to fatal error
      

      netstat -rn output:

      172.16.2.33        172.16.2.2         UGH1        0        0 ovpns2
      

      The solution is to delete manually the route above with this command:  route del 172.16.2.33

      After this, I can start the openvpn service and the vpn tunnel recovers….
      Does anybody know an automatic solution for this?

      Thanks,

      klajosh2

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Are you using OSPF on there?

        That's the only way I've ever seen that happen. Normally it reconnects without issue.

        If you're using OSPF, add the tunnel network IP addresses on the main page of quagga with 'accept filter' checked.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • K
          klajosh2
          last edited by

          Jimp,

          you are correct! I am using ospf over the openvpn links.

          I am using /28 networks for point to point s2s openvpn links. (I know /30 would be enough also and probably I will not use
          more than 2 ip addresses on these links but I decided to use /28)

          so what I did is to turn on the accept filter box on all openvpn interfaces under quagga Interface Settings tab.
          (the interface names on server: ovpns2, ovpns3,ovpns4,ovpns5 ; on openvpn client: ovpnc1,ovpnc2,ovpn3,ovpn4)
          and on quagga main page I addedd these filter:  (under global settings):

          172.16.2.0/28
          172.16.2.16/28
          172.16.2.32/28
          172.16.2.48/28
          both disable redistribution and disable acceptance are checked. These settings are in place on site1 and site2 firewalls.

          If I understand well these settings above should remove the route entries from OSPF routing table.
          But this is what I see on site1:
          Quagga OSPF routes:

          N    172.16.2.2/32         [5] area: 0.0.0.0
                                     directly attached to ovpns2
          N    172.16.2.18/32        [10] area: 0.0.0.0
                                     directly attached to ovpns3
          N    172.16.2.34/32        [10] area: 0.0.0.0
                                     directly attached to ovpns4
          
          

          Quagga Zebra routes:

          
          O   172.16.2.2/32 [110/5] is directly connected, ovpns2, 18:08:55
          C>* 172.16.2.2/32 is directly connected, ovpns2
          O   172.16.2.18/32 [110/10] is directly connected, ovpns3, 18:08:55
          C>* 172.16.2.18/32 is directly connected, ovpns3
          O   172.16.2.34/32 [110/10] is directly connected, ovpns4, 18:08:55
          C>* 172.16.2.34/32 is directly connected, ovpns4
          

          (despite that two firewalls can see eachother on 172.16.2.48/28 network they cannot establish ospf neighbor relationship but I think this
          is a different issue)

          on site2 the situation is the following:

          Quagga OSPF routes:

          
          N    172.16.2.1/32         [5] area: 0.0.0.0
                                     directly attached to ovpnc1
          N    172.16.2.17/32        [10] area: 0.0.0.0
                                     directly attached to ovpnc2
          N    172.16.2.33/32        [10] area: 0.0.0.0
                                     directly attached to ovpnc3
          N    172.16.2.49/32        [10] area: 0.0.0.0
                                     directly attached to ovpnc4
          

          Quagga Zebra routes:

          O   172.16.2.1/32 [110/5] is directly connected, ovpnc1, 18:09:52
          C>* 172.16.2.1/32 is directly connected, ovpnc1
          O   172.16.2.17/32 [110/10] is directly connected, ovpnc2, 18:09:52
          C>* 172.16.2.17/32 is directly connected, ovpnc2
          O   172.16.2.33/32 [110/10] is directly connected, ovpnc3, 18:09:52
          C>* 172.16.2.33/32 is directly connected, ovpnc3
          O   172.16.2.49/32 [110/10] is directly connected, ovpnc4, 18:09:52
          C>* 172.16.2.49/32 is directly connected, ovpnc4
          

          Can you help me to understand the situation?

          Thank for your support,

          klajosh

          1 Reply Last reply Reply Quote 0
          • K
            klajosh2
            last edited by

            any idea folks?

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              Re-read what I posted before. You put in the entire tunnel network, which doesn't match the /32 route you are receiving. Put in the endpoint IP addresses individually.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • K
                klajosh2
                last edited by

                ok. thanks, now I understand, /32 has to put in the list.

                I have one more concern:

                currently we are using  2.1.2-RELEASE of pfsense.
                and quagga we are using: 0.99.22.3 v0.6.1.

                With my previous setup where I turned on accept filter in OSPF interface config on openvpn interfaces and setup /28 filter subnets in quagga
                OSPF main page we had the problem when a link went down and ospf neighbour has gone the Quagga Zebra service stopped.
                So all routes via OSPF have gone. I was not able to manually start Quagga Zebra daemon, till I remove the accept filter setting on
                openvpn interface in Quagga interface configuration section.

                Did you experience something similar? I can reproduce this error anytime.

                Thanks for help,

                klajosh2

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