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

    CARP using VPN IPsec

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    9 Posts 3 Posters 2.6k 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.
    • L
      laped
      last edited by

      Hi Guys.

      Got CARP working but have a question on how it is supposed to work when also using VPN. If the CARP master fails the VPN clients will connect to the backup after the dead peer detection kicks in. Is this like it is supposed to work or can the CARP switching be done without interruption of packets like when using CARP without VPN?

      1 Reply Last reply Reply Quote 0
      • L
        laped
        last edited by

        Thought this was a simple question :) Maybe the question is described poorly. I just wanted to know how long it normally takes for VPN clients to detect and switch from the Master to the Backup site.

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by

          With current state of IPsec on pfSense? Sounds like sticking your head inside A380's engine and telling the pilot to crank it up…

          1 Reply Last reply Reply Quote 0
          • L
            laped
            last edited by

            @doktornotor:

            With current state of IPsec on pfSense? Sounds like sticking your head inside A380's engine and telling the pilot to crank it up…

            The state of IPsec is fine for me when custom patching the following pull request: https://github.com/pfsense/pfsense/pull/1649

            Got a IPSec IKEV2 with AES256-GCM using elliptic curve key exchange up and running without any problems, but I can see on the forum that many are having trouble with 2.2.3 :)

            1 Reply Last reply Reply Quote 0
            • D
              doktornotor Banned
              last edited by

              Good that it works for you…

              Many have had endless issues and random regressions ever since IPsec switched to Strongswan in 2.2.  I've switched pretty much everyone with site-to-site tunnels to OpenVPN since I was plain tired of tunnels randomly becoming dead, not passing traffic, working configurations getting broken on 2.2.x upgrades and people complaining over and over again...

              1 Reply Last reply Reply Quote 0
              • dotdashD
                dotdash
                last edited by

                If you use a CARP VIP for the tunnel endpoint, it should switch over to the secondary without interruption.
                I've got a cluster with around 40 IPSec tunnels. When I was running 2.1.5, a failover event would typically leave a half-dozen tunnels not passing traffic. Clearing the SA's and re-establishing generally fixed those. The rest were fine. Most of my peers are pfSense, with a few ASAs or Sonics.
                I switched to 2.2.2 when I upgraded to aesni capable hardware. I had a few tunnels not passing traffic after the switch, but the great majority reestablished seamlessly. After some banging and cursing, everything stabilized and has been solid, and AES-NI dropped the cpu usage to nearly nothing. I have not had a failover event on 2.2.2 yet, so I don't know if the behavior is better or worse than 2.1.5. I suppose I'll find out when I do an upgrade to 2.2.4. I'm skipping 2.2.3 due to the reports of trouble with aesni.

                1 Reply Last reply Reply Quote 0
                • L
                  laped
                  last edited by

                  @dotdash:

                  If you use a CARP VIP for the tunnel endpoint, it should switch over to the secondary without interruption.
                  I've got a cluster with around 40 IPSec tunnels. When I was running 2.1.5, a failover event would typically leave a half-dozen tunnels not passing traffic. Clearing the SA's and re-establishing generally fixed those. The rest were fine. Most of my peers are pfSense, with a few ASAs or Sonics.
                  I switched to 2.2.2 when I upgraded to aesni capable hardware. I had a few tunnels not passing traffic after the switch, but the great majority reestablished seamlessly. After some banging and cursing, everything stabilized and has been solid, and AES-NI dropped the cpu usage to nearly nothing. I have not had a failover event on 2.2.2 yet, so I don't know if the behavior is better or worse than 2.1.5. I suppose I'll find out when I do an upgrade to 2.2.4. I'm skipping 2.2.3 due to the reports of trouble with aesni.

                  Sounds like it will be fun to get 5000-10000 IPsec tunnels up and also get failover working :)

                  1 Reply Last reply Reply Quote 0
                  • L
                    laped
                    last edited by

                    dotdash: What values of dead peer detection are you using?

                    1 Reply Last reply Reply Quote 0
                    • dotdashD
                      dotdash
                      last edited by

                      I leave it enabled at defaults. It shouldn't need DPD to fail to the second node- the secondary should take over the existing IPSec connections.

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