cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1108
Views
3
Helpful
12
Replies

Can we build a Site to Site VPN tunnel with an ASA HA pair?

ajc
Level 7
Level 7

I have a 5516-X standalone node with a S2S VPN Tunnel to Azure working fine. I would like to know if I can add a second ASA, create an HA pair AND the S2S tunnel would still work. Looks like it is doable and my understanding is that I do not need a public + internal IP configured on the standby ASA, only the parameters related to failover interface and statelink interface as per the following link so once the Primary ASA fails the standby node assumes the "transferred" configuration from the active ASA and resumes the S2S VPN tunnel to Azure (the standby ASA has physical connections to the Internal and Internal networks).

I would expect a brief outage because the ARP table in the internal and external sw changes to the value of the new mac coming from the standby ASA inside / outside interfaces which now use the same IP's from primary.

https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/ha_failover.html#30332

Configuring the Secondary Unit for Active/Standby Failover

The only configuration required on the secondary unit is for the failover link. The secondary unit requires these commands to communicate initially with the primary unit. After the primary unit sends its configuration to the secondary unit, the only permanent difference between the two configurations is the failover lan unit command, which identifies each unit as primary or secondary.

ciscoasa(config)# failover lan interface folink gigabitethernet0/3 INFO: Non-failover interface config is cleared on GigabitEthernet0/3 and its sub-interfaces ciscoasa(config)# failover interface ip folink 172.27.48.1 255.255.255.0 standby 172.27.48.2

ciscoasa(config)# interface gigabitethernet 0/3

no shutdown

ciscoasa(config)# failover link statelink gigabitethernet0/4

INFO: Non-failover interface config is cleared on GigabitEthernet0/4 and its sub-interfaces ciscoasa(config)# failover interface ip statelink 172.27.49.1 255.255.255.0 standby 172.27.49.2

ciscoasa(config)# interface gigabitethernet 0/4

no shutdown ciscoasa(config)# failover ipsec pre-shared-key a3rynsun ciscoasa(config)# failover

After the failover configuration syncs, save the configuration to flash memory: ciscoasa(config)# write memory

 

1 Accepted Solution

Accepted Solutions

Correct - S2S IPsec VPN with an ASA HA pair works just fine. I've setup dozens of them, including to Azure and AWS.

Nothing special needs to be setup on the Secondary unit other than the basic failover config that you noted already. When a failover occurs, the newly active unit issues a gratuitous ARP - so traffic through the system as a whole only sees a subsecond interruption and usually the higher level protocols don't even notice the blip.

View solution in original post

12 Replies 12

I will run lab and test this case 
I will update you soon with LAB and result and config you need. 
thanks 
MHM

Hi MHM, 

I changed my original post to be more specific. I posted some clarifications. thanks for replying.

failover ipsec pre-shared-key a3rynsun <<- but this only for failover link it not effect s2s vpn' it encrypt secure data transfer via failover link.

What I want to check in my lab is are IPsec config is synced from one FW to other.

Azure will form s2s vpn to active OUTside IP

But if active failed then I need to check if SA if IPsec is sync and traffic not drop.

hi MHM, that's  correct, the shared-key is for the failover link and it is not mandatory to have it. This parameter I know has nothing to do with the S2S VPN tunnel.

Correct - S2S IPsec VPN with an ASA HA pair works just fine. I've setup dozens of them, including to Azure and AWS.

Nothing special needs to be setup on the Secondary unit other than the basic failover config that you noted already. When a failover occurs, the newly active unit issues a gratuitous ARP - so traffic through the system as a whole only sees a subsecond interruption and usually the higher level protocols don't even notice the blip.

Thanks Marvin,

I have a S2S VPN tunnel in my lab going to Azure with an standalone ASA 5516X , I will give a try there.

@ajc I don't think you mean cluster if you are configured as Active/Standby failover pair. In which case an Active/Standby failover supports Site-to-Site VPN.

There is no difference in configuration required. https://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/214109-configure-asa-ipsec-vti-connection-to-az.html

https://community.cisco.com/t5/security-blogs/site-to-site-vpn-between-cisco-asa-and-microsoft-azure-virtual/ba-p/3099317

 

Hi Rob,

to be more specific, I changed my original post. My understanding from ASA HA active/standby is that I do not need any IP configuration on the standby ASA other than statelink and failover interfaces so when the primary fails, the standby uses the same public and internal IP of the primary and the S2S VPN tunnel to Azure can be reestablished (I assume there is an expected short outage because the ARP table for the internal and external routers are updated with the standby inside / outside interface MAC).

When primary ASA fails, its configuration is already applied to the standby ASA including crypto map, peer, shared key, etc so nothing has to be configured on this standby ASA at all.

 

sorry just to confirm, you dont need lab any more ?

thanks 

MHM 

Hi MHM, thanks for offering to test it in your lab, please proceed if you want. I will try as well on my side and I will post the tests results here including actual failover when primary fails and how long it takes to resume the tunnel once interesting traffic is generated. 

My intention is to test:

1.-Primary is completely down

2.-Primary Outside interface is down

3.-Primary Inside interface is down.

Using: 

ASA(config)#monitor-interface INSIDE

ASA(config)#monitor-interface OUTSIDE

I am aware what happens when the failover/state link is down.

Screenshot (924).pngScreenshot (925).png

you can play with 
failover interface-policy % <> 
this can make force standby to be active immediate if one link is down
Screenshot (958).png