Branch 5505, 1 ISP circuit, Dual-peer VPN Configuration to Data Center & Track Options

[Dean Romanelli]

Hi All,

I have a data center with two ISP lines for redundancy, and two ASA 5520's for VPN redundancy to my branches.  Each of my branches has 1 ASA 5505 with a base license, and 1 ISP circuit. Currently all of my VPN tunnels are built to the primary data center ISP circuit only, so if that one goes down, I am toast.  I need to fix that. Problem is, I'm not sure how I can control the fail-over on the branch 5505 with only 1 ISP line.  Please see my drawing for an example of how it looks right now.

So the issue is that the data center LAN my branch needs to get to is the same regardless what data center circuit it comes in on. And I know ASA rules say only 1 VPN tunnel can be active at a time if the flows are the same.  So in that case I know you typically do:

crypto map outside_map 1 set peer 12.x.xxx.20  50.xxx.xx.190

and then configure route tracking to control when to tear down the primary peer and turn up the back up peer. But in the case where I only have 1 ISP on the branch side, I am only going to have 1 default route: route outside 0.0.0.0 0.0.0.0 3.3.3.2 1, which will be used whether the active far-end peer is to primary or to secondary data center circuit. So since I don't have a second route, I can't configure route tracking on the primary route along with an SLA that sets the trigger conditions, because there's nothing to track.

How would one handle a situation like this? Are there any other features that can be tracked besides routes?  I really need to be able to set "num-packets 5" in the SLA so my sites aren't flapping all day, but again, without something to track, I can't really configure a meaningful SLA.  Any help is appreciated.

[Richard Burts]

You are quite welcome. When you do get it implemented please do post back to the forum and let us know what you wind up with and how it worked.

HTH

Rick

[Dean Romanelli]

Will do, thanks.  

One final follow up; I presented this solution to my manager this morning and he likes it, but he wants to wait until we swap out the data center 5520's with Next Gen 5525-X's. I am going to read up on it, but is there anything you know of that will change any part of this solution if the data center firewall becomes a next gen unit while the branch stays old gen 5505?

[Richard Burts]

I am not aware of any aspect of this solution that would be impacted or would work any different if the data center ASAs were upgraded to 5525s from 5520s. Certainly there are differences between 5520 and 5525 including more memory, more powerful processor, greater throughput, more features (such as FirePower). But as far as I know the functionality for site to site VPN, for routing EIGRP, and for RRI should remain the same and I would certainly expect no problem with operability between 5505 and 5525.

If the intent to wait to implement until the ASA are upgraded is based on management considerations (prioritization of Network Engineering resources, etc) then it is fine to wait. But if it reflects any concern about functionality of the ASAs then I see no reason to wait.

HTH

Rick

[Dean Romanelli]

Thanks Rick.  Much appreciated as always.

[Diego Lopez]

Hello,

What I understand is that you have 142 routes because you're doing "load balancing" between your two ISPs but now that you will have all your branches connected to a single ISP at the time you don't need to announce branch xxxx on ISP1 or branch yyyy on ISP2 you dont need all these static routes, now is going to be all branches on ISP1 or all branches on ISP2 so you just need to track the default gateway to ISP1 and the interesting traffic defined in the crypto maps will send the traffic to the correct peer "branch".

I would say that in this particular setup that you are trying to accomplish you don´t need 142 routes or dynamic routing you just need 2 default gateway one pointing to ISP1 and the other to ISP2 on the router and use SLA to track the primary route, that will do the trick :-).

I also want to clarify that a site to site vpn tunnel cant propagate dynamic protocols is one of its limitations in this case like Richard said GRE tunnels "on routers" can propagate this protocols because they have the ability to send multicast over a unicast.

[Diego Lopez]

Hello,

You can configure keepalives in the branch office ASA, so it can monitor the peer and in case the peer goes down it will drop the tunnel, since you configured a backup ip in the crypto map "crypto map outside_map 1 set peer 12.x.xxx.20  50.xxx.xx.190 " it will try to reestablish the tunnel with the backup IP. 

The SLA in the Data Center should bring the primary gateway backup once is operational and the ASA will switch back to the primary when the keepalives are not replied from the secondary peer. 

Keepalives are enabled by default here you can find more information about it:

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.html#solution07

Please rate, thanks.