CARP using VPN IPsec
-
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?
-
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.
-
With current state of IPsec on pfSense? Sounds like sticking your head inside A380's engine and telling the pilot to crank it up…
-
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 :)
-
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...
-
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. -
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 :)
-
dotdash: What values of dead peer detection are you using?
-
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.
