Multiple Redundant L2L VPN Endpoints

[Ian Underwood]

Here's an interesting problem.

I am attempting to land multiple L2L IPSec tunnels on an ASR-1001-HX, but with multiple endpoint addresses on my side.  At first glance, this looks like it should be doable with multiple HSRP redundancy groups.  However, it seems like I can only apply a single crypto map onto a given interface.

Here's what my interface configuration looks like (IPs changed, of course):

interface TenGigabitEthernet0/1/0
 no ip address
 load-interval 30
!
interface TenGigabitEthernet0/1/0.95
 description EXTERNAL
 encapsulation dot1Q 95
 vrf forwarding EXTERNAL
 ip address 192.0.1.68 255.255.255.224
 ip access-group ACL-EXTERNAL-IN in
 standby version 2
 standby 2 ip 192.0.1.70
 standby 2 priority 150
 standby 2 preempt delay minimum 15 reload 120
 standby 2 name STBY-VPNA
 standby 2 track 1 decrement 60
 standby 2 track 2 decrement 60
 standby 3 ip 192.0.1.71
 standby 3 priority 150
 standby 3 preempt delay minimum 15 reload 120
 standby 3 name STBY-VPNB
 standby 3 track 1 decrement 60
 standby 3 track 3 decrement 60
 standby 4 ip 192.0.1.72
 standby 4 priority 150
 standby 4 preempt delay minimum 15 reload 120
 standby 4 name STBY-VPNC
 standby 4 track 1 decrement 60
 standby 4 track 4 decrement 60
 crypto map CRYPTO-VPNB redundancy STBY-VPNB 
end

So it looks like it's not possible to add multiple crypto maps, even with different redundancy groups.

My best guess is that the only way I'm going to be able to achieve the separation I am looking for is to carve out multiple /29s and run a single VPN on each, which is a huge waste of resources.  However, I figured the community would be the best place to run this by.

[Marius Gunnerud]

You can configure the crypto map with different sequence numbers for each public peer.  That might work

[Bogdan Nita]

You could apply the crypto-map to /32 loopback interfaces, but then you would not have the redundancy.

I am having trouble understanding what the use case for this setup would be.

The only one that I could think of is having multiple tunnels between the same devices, in that case I would have one tunnel with the best crypto algorithms.

[Ian Underwood]

The chief requirement is redundancy in an event of a failure.

The separate addressing is to support multiple business units, leaving the capability to move the tunnels to another router pair without having to go through and renumber all the remote endpoints.  That's why I want to use multiple redundancy groups and crypto maps.

[Bogdan Nita]

In that case you could have 2 routers facing the internet and all the other routers performing the VPN sit behind this 2 routers. You could then set up NAT policies on the internet facing routers in order to select the routers doing the VPN. NAT-traversal will have to be enabled of course.

This is just the first idea that popped into my head. I obviously do not know the hole requirements.

[Marius Gunnerud]

In this case standard IPsec site to site VPN is not the answer.  Have you considered using VTI with IPsec encryption?  Then you could also use GRE and have dynamic routing handling redundancy.

[Ian Underwood]

VTI sounds nice, except I don't have administrative control of the remote endpoints and there is a wide spread of expertise between the remote vendors and partners.

My current thought is to shrink the network I'm using and create separate /29s on additional subinterfaces and apply the crypto maps and redundancy groups that way.  It just aggravates me because instead of using one additional IP, I have to use 8.  (or 3 if I were to use an additional router.)