cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2458
Views
0
Helpful
4
Replies

ASA Site-to-Site VPN with Secondary Peers for Failover

oddstar
Level 1
Level 1

Hi there!

Looking for advice and guidance on setting up a redundant site-to-site VPN to our remote overseas office. At the main site, we have a pair of ASA-5510's (9.x) running in a active/standby failover configuration, but at the remote site we have a pair of ASA-5510's (9.x) running independently with separate ISP connections (DSL-type using PPPoE). The gateway for all of the clients at the remote site is a Catalyst 3750 switch to which both firewalls are attached. Was thinking the best way to set up redundancy for the VPN connections would be to configure my crypto map at the main site with multiple peers and then set up IP SLA on that remote switch to monitor an internal IP at the main site to update the switch's gateway accordingly.

Does this sound like the best idea?

If I am correct, setting a secondary peer would mean that I'd need to set up the main site's crypto map connection-type as originate-only, right? Do the remote site crypto maps need to be answer-only, in that case?

At the remote site, would EIGRP be more efficient/faster at detecting a VPN cutover than IP SLA?

Finally, anything special I can/should do to deal with VoIP phone communication at the remote location?

Thanks very much!

1 Accepted Solution

Accepted Solutions

Joel
Level 1
Level 1

Hi Oddstar,

I would recommend DPD which basically sends R U THERE messages to monitor the existence and availability of IPsec peer devices.  If DPD fails with the current peer’s IP address, the Phase 1 and Phase 2 SAs are cleared and a failover to the next peer IP address is triggered.

In terms of routing at the remote site I would go with reverse route injection. Here's a guide http://www.petenetlive.com/KB/Article/0000982

I am presuming you have Cisco  VoIP. If you don't have a local call manager or SRST you will need to configure the DHCP options to find the TFTP server.

Cisco IP Phones download their configuration from a TFTP server. When a Cisco IP Phone starts, if it does not have both the IP address and TFTP server IP address preconfigured, it sends a request with option 150 or 66 to the DHCP server to obtain this information.

DHCP option 150 provides the IP addresses of a list of TFTP servers.
DHCP option 66 gives the IP address or the hostname of a single TFTP server.

Joel

View solution in original post

4 Replies 4

Joel
Level 1
Level 1

Hi Oddstar,

I would recommend DPD which basically sends R U THERE messages to monitor the existence and availability of IPsec peer devices.  If DPD fails with the current peer’s IP address, the Phase 1 and Phase 2 SAs are cleared and a failover to the next peer IP address is triggered.

In terms of routing at the remote site I would go with reverse route injection. Here's a guide http://www.petenetlive.com/KB/Article/0000982

I am presuming you have Cisco  VoIP. If you don't have a local call manager or SRST you will need to configure the DHCP options to find the TFTP server.

Cisco IP Phones download their configuration from a TFTP server. When a Cisco IP Phone starts, if it does not have both the IP address and TFTP server IP address preconfigured, it sends a request with option 150 or 66 to the DHCP server to obtain this information.

DHCP option 150 provides the IP addresses of a list of TFTP servers.
DHCP option 66 gives the IP address or the hostname of a single TFTP server.

Joel

Hi there, and thank you!  I set it up this weekend and followed your advice on the RRI with EIGRP which appears to have worked well for propagating the VPN routes from either ASA to the internal network. What is currently missing is a default gateway, however. I have one statically defined on the internal switch at the moment, but obviously that doesn't provide failover (IP SLA wasn't an option either given the BASE image on the 3750). For what it's worth, the ASA's use PPPoE setroute so I didn't need to define a static default route on them, but can I just add 0.0.0.0/0 to the Prefix Lists for that to be included in RRI, or is there a better way?

VoIP solution is not Cisco, but also a non-issue, it seems.

I marked your answer as correct. Thanks again!

Never mind--I added 0.0.0.0/0 to my existing prefix list and it works like a charm!

Excellent, glad it is working well.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card