Routing Issue over VPN IPsec (2 Peers)

[fabio Baruzzi]

Hy guys I have the following scenario and problem

ASA 5516-X

Cisco Adaptive Security Appliance Software Version 9.6(1) <context>
Device Manager Version 7.6(1)

Escenario:

I have a connection with one of our clients through VPN L2L with 2 different IPs, the idea is to have an active / backup scenario, As you probably know the idea is if the Active Peer have any problem our client is able to switch to the Backup Peer

• Active Peer 100.100.100.1
• Backup Peer 200.200.200.1

For Phase 1: both peers are UP

For Phase 2: Only Active Peer is UP

Phase 1 Status:

1 IKE Peer: 100.100.100.1
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE

2 IKE Peer: 200.200.200.1
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE

Phase 2 Status:

ASA-MDC-US-1/FW-QUALITA-US# show crypto ipsec sa peer 100.100.100.1 | inc #pkts

#pkts encaps: 2882, #pkts encrypt: 2882, #pkts digest: 2882
#pkts decaps: 2870, #pkts decrypt: 2870, #pkts verify: 2870
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

ASA# show crypto ipsec sa peer 200.200.200.1

There are no ipsec sas for peer 200.200.200.1

Problem:

When the Active Peer has problems, the client tries to switch to the Backup Peer (200.200.200.1) and phase 2 does not comes UP, it continues to send traffic to the Active Peer (100.100.100.1) even when we clear the tunnel

I cheked my VPN and route configuration and seems fine, unless Im missing something

VPN Configuracion for Phase 2:

crypto map INET_map2 2 match address INET_cryptomap_1
crypto map INET_map2 2 set peer 100.100.100.1 200.200.200.1
crypto map INET_map2 2 set ikev1 transform-set ESP-3DES-SHA
crypto map INET_map2 2 set security-association lifetime seconds 3600
crypto map INET_map2 2 set security-association lifetime kilobytes unlimited

I understand that the first IP should be the primary or active IP and the other the secondary, so I understand that it will prefer the 100.100.100.1 unless the client stop send traffic to that IP and starts sending traffic to the second IP "200.200.200.1"

Routing Configuracion:

route INET 0.0.0.0 0.0.0.0 192.168.1.1 1
route INET 100.100.100.1 255.255.255.255 192.168.1.1 5
route INET 200.200.200.1 255.255.255.255 192.168.1.1 10

For routing, we put the preferred peer to have a preferred route with better metric than the secondary peer

On the other side the client has two interfaces:

• Interface a: 100.100.100.1
• Interface b: 200.200.200.1

Normally its send all the traffic through Interface a.

The mecanism to execute the switchover its to send all the traffic through interface b

Regarding VPN configuracion they use the same mechanism as me

Thanks for all the support you can give me

Regards

[Cristian Matei]

Hi,

   Is the other side an ASA as well? Configure your side as "originate-only" and the remote side as "answer-only"; note that this is a per VPN tunnel connection, not globally per crypto-map, so it doesn't affect other tunnels build off the same crypto-map:

crypto map INET_map2 2 set connection-type originate-only on your side

crypto map XXX Y set connection-type answer-only on remote side

Regards,

Cristian Matei.

[fabio Baruzzi]

Hi @Cristian Matei thanks for the reply

I was testing this solution and the problem is that two peer cannot coexist on the same VPN configuration and I need it for redundancy, below I show you the output

ASA-(config)# crypto map INET_map2 10 set connection-type answer-only
WARNING: This will remove all but the first peer from the list
ASA-(config)#
ASA-(config)# crypto map INET_map2 10 set peer 107.21.150.22
ERROR: Multiple Peers cannot be specified with answer-only connections
ASA-US(config)#

Another thing we see very strange is that when, for some reason, the VPN goes down, only my side is able to send traffic and open the tunnel, the other side can't.

Finally answering your previous question, the other side of the tunnel is Amazon Web Services (AWS)

Regards

[Cristian Matei]

Hi,

   As i previously said, you need to configure your side as "originate-only", so you can configure the two peers and have fallback between the two peers. Yes, correct, you need to initiate the fallback, that's why i said you need to have isakmp keepalives on at the tunnel-group level, so that while your primary tunnel is active and there is a failure in the path, you detect that and try to bring up the tunnel with the second peer.

Regards,

Cristian Matei.

[fabio Baruzzi]

Hi @Cristian Matei thanks again for yor reply, I just want to comment that in the comunication behaivior im not really the one that originate the traffic  im the receiver, once mentioning this, your proposol still applies?

Regarding the keepalive I already have them configured on the both tunnel groups, bellow I show you the configuration of both peers at this moment

tunnel-group 100.100.100.1 type ipsec-l2l
tunnel-group 100.100.100.1 general-attributes
default-group-policy GroupPolicy_TunnelA
tunnel-group 100.100.100.1 ipsec-attributes
ikev1 pre-shared-key *****
isakmp keepalive threshold 10 retry 10
!
tunnel-group 200.200.200.1 type ipsec-l2l
tunnel-group 200.200.200.1 general-attributes
default-group-policy GroupPolicy_TunnelB
tunnel-group 200.200.200.1 ipsec-attributes
ikev1 pre-shared-key *****
isakmp keepalive threshold 10 retry 10
!
crypto map INET_map2 10 match address INET_cryptomap_10
crypto map INET_map2 10 set pfs 
crypto map INET_map2 10 set peer 100.100.100.1 200.200.200.1 
crypto map INET_map2 10 set ikev1 transform-set ESP-AES-256-SHA
crypto map INET_map2 10 set security-association lifetime seconds 3600
crypto map INET_map2 10 set security-association lifetime kilobytes unlimited
!

In this sense can you guide me wuth an example workaround that I can apply in my current scenario?

Thanks again

Regards