cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
536
Views
0
Helpful
5
Replies

Redundant VPN connectivity for customers

switched switch
Level 1
Level 1

Hi All.,
i am looking at building up an environment to support a number of our customers that required IPSEC VPNs into our service provider environment.
I want to build up a redundant pair of routers that will be used for customers to setup IPSEC VPNs from the HQ and
route across our network for services.

Being that the redundant pair need to be somehow highly available, I wanted to confirm the correct solution for the requirements.


Each customer is given a VLAN behind the routers and I would need separation on this traffic, so thinking VRFs to prevent customers terminating their VPNs
and connecting into other equipment.

I believe redundant IPSEC traffic with crypto maps might be the only solution here, but not having done this before
I wanted to ask the experts. This looks like an old solution, and wondering if some more recent technology can help solve this.
I dont beleive we can run GRE tunnels and have that failover but need to have someone confirm.


1 Accepted Solution

Accepted Solutions

Marvin Rhoads
Hall of Fame
Hall of Fame

If your headend is ASAs, you can have high availability between two appliances with a simple HA pair.

If they aren't ASAs or you want to perhaps also have more separation like completely separate providers and IP addresses then you can setup two routers, each connected to its own Internet provider. Thus facing your customers you have two completely seprate ways to access the same resources. They can have an automatic slection at their end. Here's a bit of what that would look like at their end:

crypto map Outside_map 10 set peer 10.10.10.1 20.20.20.1 

That means your primary peer is at 10.10.10.1 and, if it is down, their device will try your peer at 20.20.20.1.

Facing your equipment:

If it's ASAs, then just use subinterfaces with each customer on a distinct VLAN/subnet where the ASA is the layer 3 gateway. Do not permit "same security inter-interface" and they will not have the abilitiy to reach addresses on other subnets in your data center.

If you have routers and not ASAs then you could do it with VRFs (a bit more complexity there) or you could also use subinterfaces and IOS zone-based firewall feature (with its own complexity). Here's some more on that setup:

https://supportforums.cisco.com/document/51931/vrf-aware-ipsec-cheat-sheet

View solution in original post

5 Replies 5

Marvin Rhoads
Hall of Fame
Hall of Fame

If your headend is ASAs, you can have high availability between two appliances with a simple HA pair.

If they aren't ASAs or you want to perhaps also have more separation like completely separate providers and IP addresses then you can setup two routers, each connected to its own Internet provider. Thus facing your customers you have two completely seprate ways to access the same resources. They can have an automatic slection at their end. Here's a bit of what that would look like at their end:

crypto map Outside_map 10 set peer 10.10.10.1 20.20.20.1 

That means your primary peer is at 10.10.10.1 and, if it is down, their device will try your peer at 20.20.20.1.

Facing your equipment:

If it's ASAs, then just use subinterfaces with each customer on a distinct VLAN/subnet where the ASA is the layer 3 gateway. Do not permit "same security inter-interface" and they will not have the abilitiy to reach addresses on other subnets in your data center.

If you have routers and not ASAs then you could do it with VRFs (a bit more complexity there) or you could also use subinterfaces and IOS zone-based firewall feature (with its own complexity). Here's some more on that setup:

https://supportforums.cisco.com/document/51931/vrf-aware-ipsec-cheat-sheet

switched switch
Level 1
Level 1

Hi Marvin,

Thanks for the reply. In our example we are using IOS routers for the VPN termination in our SP network, and not ASA.
In the example, I note the outside interface is put within a VRF. Is there any reason for this? Definately our customers should be part of a VRF but wanting to confirm the internet or dirty side can infact be standard global table.

Being that we want to run redundancy, is there no way we can run VTIs, or is this not supported? Or do we need to support crypto maps for the purpose of those that might connect with an ASA for example?

You're welcome.

I do know that the outside interface does not need to be in a VRF. If you note further down in the linked doc the author states as much.

I'm not sure about VTIs myself as I mostly deal with ASAs. However the Cisco documentation and a few older threads seem to indicate you can use them with VRF-aware IPsec tunnels on IOS:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_vpnips/configuration/15-2mt/sec-ipsec-virt-tunnl.html#GUID-E70E6449-063B-4338-80A6-920089646930

https://supportforums.cisco.com/discussion/11743996/vrf-aware-ipsec-dynamic-vti

Thank you Marvin. It sounds like we need to support both options on our routers for customers to connect to us.

for customers with ASAs our only option is interfaces crypto maps as they don't support tunnel interfaces and for those that are using IOS based routers we can support VTI as a preference.

My next question is, is we have dual head end routers, is it best to run HSRP on our inside and outside interfaces on our VPN routers and allow HSRP to failover. I would imagine a single public ip range for both the routers outside (part of same /29) interface for HSRP that we can have many customers terminate onto and then on the inside each customer HSRP interface and allow the IPSec to just follow the VIP of HSRP?

I haven't seen anybody use HSRP failover for the client-facing VPN headend.

Probably because it doesn't retain connection state between the HSRP group members and thus the failure conditions would be very "non-graceful". That's one advantage of an ASA HA pair.