IPSec failover - theory

Issues related to configuring your network
Post Reply
EdHeron
Posts: 23
Joined: 2009/03/20 20:34:11
Location: Albuquerque, NM, USA

IPSec failover - theory

Post by EdHeron » 2013/12/04 23:06:44

It seems to me that we might be able to do IPSec tunnel failover using some scripts...

First, some background...
I've been virtualizing, for lack of a more accurate term, my business units. Since I'm using RDP to connect to the virtual machines and it doesn't handle high latency well, I'm putting local servers (CentOS 5 w/Xen) at all business units. With all my eggs in one basket, I'm using DRBD to sync with a backup server at each unit. Since the backup server is there, I distribute the load so both servers are active (cold spares are a nightmare waiting to happen). Since I've got 2 active virtual servers, I've put a router on each server. I've rebuilt keepalived for CentOS 5.10 and it seems to be working. I've got DHCP set up to provide failover. I'm connecting my offices with ipsec.

Now, the theory...
Suppose we have 4 firewalls... A1 - unit A, firewall 1. A2 - unit A, firewall 2. B1 - unit B, firewall 1. B2 - unit B, firewall 2.

When A1 gets the Virtual IP address (VIP), it would run a script to bring up IPSec. When it looses the VIP, it would take down IPSec. Same with A2, B1 and B2. Theoretically, we would only have 1 firewall at each unit with IPSec active. There might have to be a ping to keep the IPSec connection up.

When IPSec from A1 to B1 comes up, using the phase1-up script, we'd create a semaphore, look for and destroy any tunnel policy between A1 and B2, then create the tunnel policy from A1 to B1.

If the connection from A1 to B1 ever goes down, using the phase1-down script, we'd delete the tunnel policy to B1 and the semaphore, verify A1 to B2 is up (using the semaphore) and create the tunnel policy to B2.

The hole is if A1 loses connection to B1 but B2 doesn't get the VIP and bring up IPSec, which would indicate a secondary issue that might require manual troubleshooting.

We could build the phase1 up and down scripts in the ifup-ipsec file, where it already builds the racoon include file. We could configure the primary and secondary remote by using DST1 and DST2 variables in ifcfg-ipsec?. The DST variable could still be used in a non-failover configuration to maintain backward compatibility. Since the changes to ifup-ipsec would not directly depend on keepalived (a package not included by the upstream vendor), the changes could be submitted to the upstream vendor and possibly other related projects.

I'm going to start working on getting all this to work. I know I haven't pedantically listed all possibilities but if someone sees a hole in my theory, please share it.

User avatar
Super Jamie
Posts: 310
Joined: 2014/01/10 23:44:51

Re: IPSec failover - theory

Post by Super Jamie » 2014/01/11 00:34:43

You might find this interesting: http://simonmott.co.uk/vpn-bonding

This guy creates tun interfaces with the ssh client, then bonds them and uses the bond to route and load balance traffic over the tunnels.

I have done IPSec failover before, but it was using BGP on Cisco. Running Quagga's a bit of an overkill. You could make something simpler on Linux with static routes. Just have a given remote subnet routed down one tunnel, and put a route in with a worse metric over the other tunnel.

Assuming the tunnel interface actually goes down when the IPSec fails, that would simplify your config immensely.

Post Reply