ASA 5506 with VPN Redundancy from Remote Sites to HQ and DR

[jonathanvanderzee]

We have two primary sites (HQ and DR) and many remotes sites.  All sites are using the ASAs as the STS VPN endpoint.  Remote sites have ASAs only, no router or layer 3 switch lays behind the ASA unit.  We are trying to use the best setup to provide redundant paths in case an ISP failure at either the HQ or DR site.  The HQ and DR are currently setup with a Cisco 3850 and a ASA 5506-X.  Both devices at HQ and DR site are running EIGRP.  The Cisco 3850s have a SM fiber link between sites and currently use a STS VPN tunnel on the ASAs in case the SM Fiber link is down.  My questions is: While trying to keep the design as simple as possible what is the best way to ensure the ASAs at the remote sites route traffic via VPN primarily to the HQ while using the DR via VPN as a backup path.  As an example if the ISP went down at the Primary Site, the VPN to the remote sites would switch to a VPN to DR.  Data could still be accessed at HQ via DR from these remote sites due to linkage between HQ and DR.

Diagram PDF is attached for clarity.  Appreciate the help.

[Philip D'Ath · Accepted solution]

Set the HQ and DR sites to be answer only.  Have them use reverse route injection to advertise when a VPN is up.  Re-distribute the reverse static route into EIGRP.

At the branch specify both the HQ as the primary peer and the DR as the backup peer.

[jonathanvanderzee]

Regarding your "answer only" comment, would it resemble a static to dynamic VPN setup (the remote site resembling the dynamic side) or is there a document you have for reference?

This is what I found:

ASA-to-ASA Dynamic-to-Static IKEv1/IPsec

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/119007-config-asa9x-ike-ipsec-00.html

[Philip D'Ath]

Go to this document and search for "answer":

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/c5.html

[Richard Burts · Accepted solution]

If I am understanding your post correctly your requirement has several parts. The first part is that there need to be redundant site to site connections from a remote site to HQ and to DR. The second part of the requirement is that it operate as a primary and a backup so that normally traffic uses the VPN to HQ. If there is a problem with using the primary VPN then traffic uses the backup VPN and when the primary VPN is available then traffic switches back to the primary.

I had a customer who had these requirements. For that project we accomplished the requirements using IOS routers. On the remote we configured two VTI interfaces. One VTI connected to HQ and the other VTI connected to DR. We ran EIGRP over the VPN tunnels and arranged the routing metrics so that HQ was preferred and DR was used as backup.

In release 9.7 Cisco has introduced support for VTI on the ASA. So it may be possible to do on your 5506s what we did on IOS routers. This is a new feature for the ASA and it might be that it does not yet support the full range of features that IOS does for VTI. You may find some details in this link

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/vpn/asa-97-vpn-config/vpn-vti.pdf

HTH

Rick

[jonathanvanderzee]

Richard, what you have explained is what I want to do.  I will look into the VTI setup as you describe, we are running 9.5 right now so all the devices would need to be upgraded.  

Do you feel the solution Philip D'Ath provided in this post will do the trick as well?

[Richard Burts]

There is a reason why in my initial response I divided your requirements into two parts. The first part (providing the ability to failover when the primary VPN stops working) is fairly straightforward. The traditional solution for ASA has been to have the remote ASA specify two peers in its crypto map set peer statement. Philip's suggestion of making the HQ and DR answer-only (implying that the remote is originate-only) is an enhancement on this and makes sure that the remote chooses which peer to negotiate with.

But the approach of the remote ASA specifying two peers (and the enhancement of answer-only and originate-only) only addresses the first part of your requirement. The remote ASA will start with HQ as primary and will failover to DR if HQ has problems. But there is not anything there that addresses failing back when HQ becomes available. So my assessment is that the suggestion from Philip solves only part of your requirement.

HTH

Rick

[Philip D'Ath]

I think it will failback when the next SA re-negotiation occurs.

[Richard Burts]

I used to think that also. But then I had an experience with a customer who had this type of VPN configuration where the remote had 2 peer addresses in the set peer statement. They realized that they were running on the "backup" VPN and had been there for almost two weeks (going through multiple SA negotiations). We did a clear crypto for ISAKMP and for IPsec to get them back onto the "primary" peer.

HTH

Rick