Running two IPSEC tunnels between two multi-wan sites
-
Scenario: I have two locations, HQ and Branch Office. Both HQ and Branch Office have two separate ISPs for redundancy. IP addressing looks like this:
HQ Public IP1: 1.1.1.1
HQ Public IP2: 2.2.2.2
Branch Office IP1: 3.3.3.3
Branch Office IP2: 4.4.4.4HQ's internal private IP network: 10.0.0.0/24
Brance Office's internal private IP network: 10.1.0.0/24A single IPSEC tunnel between them is simple enough, the tunnel (P1) would link between 1.1.1.1 and 3.3.3.3. The P2 security association would look like 10.0.0.0/24 <> 10.1.0.0/24.
Now, let's say I want some redundancy with my VPN just like I do with my WANs at these locations. Say then that I create a second tunnel (P1) that links between 2.2.2.2 and 4.4.4.4. Works well enough so far I'd assume, but what happens when the secondary tunnel linking 2.2.2.2 and 4.4.4.4 create a P2 security association that duplicates the P2 from the primary VPN tunnel?
My questions are, will this work? Does it cause problems? Will it fail? If it does work, is there a way to make traffic favor one tunnel over another? I am not interested in link balancing in this case, the secondary is purely to be used a hot standby if I need to take down the primary tunnel for some reason.
If this type of setup doesn't work or doesn't work well, is there a method by which I can make a tunnel establish itself over the secondary WAN addresses if the primary tunnel goes down, in an automatic failover kind of fashion?
-
You can't do that with policy-based tunnels.
You have two choices:
- Keep the policy-based tunnels and setup Dynamic DNS and gateway groups on both sides so that if a WAN fails, the switches the hostname and single IPsec tunnel to the other WAN. This works, but takes a long time to switch since it relies on DNS (several minutes, most likely)
- Ditch the policy-based tunnels and use VTI. Configure two tunnels (1.1.1.1<->3.3.3.3, 2.2.2.2<->4.4.4.4) and use FRR with either OSPF or BGP to handle the routing. When setup properly, dynamic routing protocols are smart enough to detect when a path is down and use the other alternate path in a timely manner.
