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

    OpenVPN Failback Issue in High Availablility

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    6 Posts 2 Posters 747 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
      SLilley
      last edited by

      Hi All,

      I have 2 PF Sense boxes in a high availability configuration, briefly the setup is;

      • 2 virtualized PF sense VMs on 2 separate ESXi hosts

      • 3 physical NICs mapped to 3 virtual NICs for each PF Sense VM acting as LAN, WAN and Sync

      • Full CARP setup with virtual LAN IP (acting as internal networks gateway) and a Virtual WAN IP.

      • OpenVPN Site to Site service (as a client) connecting to cloud provider

      All this works fine, brilliantly in fact, the gateway fail over/fail back happens with a single ping loss for internet traffic and with about 30 seconds of outage for traffic going up/down the S2S OpenVPN route (the time it takes for the client to re-establish it's connection to the remote server) which is more than fine.

      The problem;

      When we fail back the virtual LAN/WAN IPs are reclaimed by the primary box - which again works perfectly with barely the drop of a ping for internet traffic - but the Open VPN client does not drop on the secondary server and as such doesn't reestablish on the primary. The problem with this is that the LAN gateway is now reclaimed by the primary while the route to the remote network is only available on the secondary meaning an effective loss of communication to the remote network.

      I'm confident this is not a configuration issue with the OpenVPN client or with the HA settings as everything else works well (and there's not much else that's obviously configurable) , it seems to me more likely to be a bug/issue with the OpenVPN service when in a HA configuration. I've obviously googled this issue but haven't turned up a great deal of information on this exact issue in this configuration (which probably means I've done something wrong??). Does anyone on here have any experience of this? Does it behave in a similar way for you or does your fail-back work correctly?

      Thanks!

      TL;DR;

      OpenVPN client service doesn't fail back in HA configuration.

      N 1 Reply Last reply Reply Quote 0
      • N
        netblues @SLilley
        last edited by

        @slilley Is the vpn client interface bound to a physical or to a carp ip?

        1 Reply Last reply Reply Quote 1
        • S
          SLilley
          last edited by

          Good question! Yeah it seems it's bound to the actual WAN interface and not the fail over CARP IP/Interface - you might have hit the nail on the head there! I'm not able to test atm (currently live) but I'll reconfigure and let you know the results. Thanks!

          N 1 Reply Last reply Reply Quote 0
          • N
            netblues @SLilley
            last edited by

            @slilley It is somewhere documented. If you bind it on the carp vip, then the client will follow active standby. Tested.

            S 2 Replies Last reply Reply Quote 1
            • S
              SLilley @netblues
              last edited by

              @netblues Yeah, that does make sense and is rather an obvious oversight on my part - whoops... :) - as I say will test when I can and report back Thanks for the quick reply.

              1 Reply Last reply Reply Quote 0
              • S
                SLilley @netblues
                last edited by

                @netblues Yeah you were on the money.

                Bound the OpenVPN client service to the CARP WAN VIP and failover/failback operates perfectly - as does all everything else.

                Perfect, thank you :) (better check my settings more thoroughly next time ;) )

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