cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
23079
Views
10
Helpful
7
Replies

IKEv2 Doesn't support Multiple Peers action to take

andre even
Level 1
Level 1

Hi,

I have to establish a tunnel from the local FW to a remote FW in L2L

In case of failure of the remote FW, a tunnel has to be opened with the backup remote FW.

I have proposed to use IKEv2

But with following config i get the message: %ASA-4-752009: IKEv2 Doesn't support Multiple Peers

.............

crypto map local-map 30 set peer 22.22.22.22 33.33.33.33

...............

So i have created two crypto maps:

crypto map local-map 30 set peer 22.22.22.22

crypto map local-map 40 set peer  33.33.33.33

The primary tunnel with peer 22.22.22.22 works fine  but with the backup tunnel with peer 33.33.33.33

The tunnel IPSEc is up  but no interesting traffic enters the tunnel:

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 28, #pkts decrypt: 28, #pkts verify: 28

 

I have first taken a capture on the inside interface  and i see the counter of the access-list incrementing

but when i take a capture on the outside interface, i don't see any interesting traffic.

I have tried the clear crypto command but no way.

Equipment: Cluster of Cisco ASA 5510 at rel 8.4.7

Do i have to reboot the FW or may be the two crypto maps that i have created are not the good solution.

As an alternative if i want to maintain both peers on the same line i can replace IKEv2 by IKEv1.

 

Best regards.

 

Andre

 

 

 

 

 

 

 

 

 

 

7 Replies 7

iai-admins
Level 1
Level 1

Hello Andre, this is a confirmed issue with Cisco. There is an official bug listed as "ENH: Multiple Peers support for IKEv2 CSCud22276" (Cisco customer login required to view bug). See also the Cisco TAC Document "Migration of IKEv1 to IKEv2 L2L Tunnel" with the following quote:

"Multiple peers used for redundancy is not supported with IKEv2 on the ASA. In IKEv1, for redundancy purposes, one can have more than one peer under the same crypto map when you enter the set peer command. The first peer will be the primary and if it fails, the second peer will kick in. Refer to Cisco bug ID CSCud22276 (registered customers only) , ENH: Multiple Peers support for IKEv2."

Here's an excerpt from the Bug Enhancement Request regarding how to work around the issue.

"Either:
1) remove all but one peer from the crypto map
or
2) use IKEv1 instead of IKEv2
"

Hopefully this helps, it would be a great feature for Cisco to add for better migration from IKEv1. I guess a more complicated alternative might be to use BGP and multiple WAN connections to have more than one valid path for the same WAN IP of your IPSec IKEv2 peer.

Hi,

Thanks for the answer.

Since the remote solution with 2 ISP's will be in few times replaced by a solution from Security Keepers which has a single public ip address for two routers in hsrp, I think I will stay in IKEv2.

Best regards.

 

Hi All, 

Do we have fix for the this reported bug CSCud22276.

or any work around. 

I am using 9.2.x

Regards / Ramesh M

You can consider using route-based VPN. You will need 4 VTI interfaces to support the 4 possible combinations of source/destination. (Primary->Primary, Primary->Secondary, Secondary->Primary, Secondary->Secondary). I believe this template contains most, if not all, of the commands you would need. Of course you can adjust as you want to make it fit your environment.

 

sysopt connection tcpmss 1350
sysopt connection preserve-vpn-flows

crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 2
 prf sha256
 lifetime seconds 28800
crypto ikev2 enable OUTSIDE
 
crypto ipsec ikev2 ipsec-proposal S2S_PROPOSAL
 protocol esp encryption aes-256
 protocol esp integrity sha-256
!
crypto ipsec profile S2S_PROFILE
 set ikev2 ipsec-proposal S2S_PROPOSAL
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key key123
 ikev2 local-authentication pre-shared-key key123
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
 ikev2 remote-authentication pre-shared-key key123
 ikev2 local-authentication pre-shared-key key123
!
interface tunnel 1
 nameif A_TO_B_VPN_1
 description "PRIMARY LINK TO SITE B MAIN IP"
 ip address 192.168.168.1 255.255.255.252
 tunnel source interface OUTSIDE
 tunnel destination 1.1.1.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile S2S_PROFILE
!
interface tunnel 2
 nameif A_TO_B_VPN_2
 description "SECONDARY LINK TO SITE B MAIN IP"
 ip address 192.168.168.5 255.255.255.252
 tunnel source interface BACKUP
 tunnel destination 1.1.1.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile S2S_PROFILE
!
interface tunnel 3
 nameif A_TO_B_VPN_3
 description "PRIMARY LINK TO SITE B ALTERNATE IP"
 ip address 192.168.168.1 255.255.255.252
 tunnel source interface OUTSIDE
 tunnel destination 2.2.2.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile S2S_PROFILE
!
interface tunnel 4
 nameif A_TO_B_VPN_4
 description "SECONDARY LINK TO SITE B ALTERNATE IP"
 ip address 192.168.168.5 255.255.255.252
 tunnel source interface BACKUP
 tunnel destination 2.2.2.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile S2S_PROFILE
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key key123
 ikev2 local-authentication pre-shared-key key123
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
 ikev2 remote-authentication pre-shared-key key123
 ikev2 local-authentication pre-shared-key key123
!
route A_TO_B_VPN_1 10.0.0.0 255.255.255.0 1.1.1.1 1 track 1
route A_TO_B_VPN_2 10.0.0.0 255.255.255.0 1.1.1.1 10 track 2
route A_TO_B_VPN_3 10.0.0.0 255.255.255.0 2.2.2.2 20 track 3
route A_TO_B_VPN_4 10.0.0.0 255.255.255.0 2.2.2.2 30

sla monitor 1
 type echo protocol ipIcmpEcho 1.1.1.1 interface OUTSIDE
 num-packets 3
 frequency 10

sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability
!
sla monitor 2
 type echo protocol ipIcmpEcho 1.1.1.1 interface BACKUP
 num-packets 3
 frequency 10

sla monitor schedule 2 life forever start-time now

track 2 rtr 2 reachability
!
sla monitor 3
 type echo protocol ipIcmpEcho 2.2.2.2 interface OUTSIDE
 num-packets 3
 frequency 10

sla monitor schedule 3 life forever start-time now

track 3 rtr 3 reachability
!
sla monitor 4
 type echo protocol ipIcmpEcho 2.2.2.2 interface BACKUP
 num-packets 3
 frequency 10

sla monitor schedule 4 life forever start-time now

track 4 rtr 4 reachability

Same issue in 9.4.2

Roman Valenta
Cisco Employee
Cisco Employee
Looks like this got finally addressed in 9.14.x based on this document.

https://www.cisco.com/c/en/us/td/docs/security/asa/roadmap/asa_new_features.html

IKEv2 Support for Multiple Peer Crypto Map
You can now configure IKEv2 with multi-peer crypto map—when a peer in a tunnel goes down, IKEv2 attempts to establish the SA with the next peer in the list.

No modified commands.

New/Modified screens: Configuration > Site-to-Site VPN > Advanced > Crypto Maps > Create / Edit IPsec Rule > Tunnel Policy (Crypto Map) - Basic

Simply amazing it took them this long to implement this. Another thing to consider, is this throws IKEv2 failover out the window for ASA 5506-X running FirePower, because you cannot have anything higher than 9.9.2.x. You would have to replace it with FirePower 1010 device, which comes with it's own complications. The only way around this with the 5506 would be to give up FirePower, then you could move to a higher version.