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: 18.104.22.168
HQ Public IP2: 22.214.171.124
Branch Office IP1: 126.96.36.199
Branch Office IP2: 188.8.131.52
HQ's internal private IP network: 10.0.0.0/24
Brance Office's internal private IP network: 10.1.0.0/24
A single IPSEC tunnel between them is simple enough, the tunnel (P1) would link between 184.108.40.206 and 220.127.116.11. 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 18.104.22.168 and 22.214.171.124. Works well enough so far I'd assume, but what happens when the secondary tunnel linking 126.96.36.199 and 188.8.131.52 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 (184.108.40.206<->220.127.116.11, 18.104.22.168<->22.214.171.124) 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.