cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
822
Views
5
Helpful
5
Replies

ISR, IKEv2 Site-to-Site, wrong ikev2-profile, AUTHENTICATION_FAILED

maxnetstat
Level 1
Level 1

Hi!
I don't know IPSec very well and I'm asking for help in solving an authentication problem.
I have a crypto map, to which I add the settings of another peer (sequence 300):

interface Port-channel1.1000
encapsulation dot1Q 1000
ip address yyy.yyy.yyy.77 255.255.255.252
ip nat outside
crypto map crypto-map-1000

crypto map crypto-map-1000 100 ipsec-isakmp
set peer xxx.xxx.xxx.11
set transform-set ESP-AES256-SHA256-HMAC
set ikev2-profile peer1-via-1000
match address peer1-list

crypto map crypto-map-1000 200 ipsec-isakmp
set peer xxx.xxx.xxx.22
set transform-set ESP-AES-SHA-HMA
set pfs group5
match address peer2-list

crypto map crypto-map-1000 300 ipsec-isakmp
set peer xxx.xxx.xxx.33
set transform-set ESP-AES256-SHA256-HMAC
set pfs group14
set ikev2-profile peer3-via-1000
match address peer3-list

Debug shows:

SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_WAIT_AUTH Event: EV_GET_POLICY_BY_PEERID
IKEv2-INTERNAL:(5): Choosing IKE profile peer1-via-1000
IKEv2-INTERNAL:% Getting preshared key by address xxx.xxx.xxx.33
IKEv2-INTERNAL:% Getting preshared key by address xxx.xxx.xxx.33
IKEv2-INTERNAL:Adding Proposal proposal-1 to toolkit policy
IKEv2-INTERNAL:Adding Proposal proposal-2 to toolkit policy
IKEv2-INTERNAL:(SA ID = 5):Using IKEv2 profile 'peer1-via-1000'
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_WAIT_AUTH Event: EV_SET_POLICY
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):Setting configured policies
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_WAIT_AUTH Event: EV_VERIFY_POLICY_BY_PEERID
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_WAIT_AUTH Event: EV_CHK_AUTH4EAP
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_WAIT_AUTH Event: EV_CHK_POLREQEAP
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_CHK_AUTH_TYPE
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_GET_PRESHR_KEY
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):
SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_VERIFY_AUTH
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):Failed to compute authentication data
IKEv2-ERROR:(SESSION ID = 1161619,SA ID = 5):: Failed to authenticate the IKE SA
IKEv2-INTERNAL:(SESSION ID = 1161619,SA ID = 5):SM Trace-> SA: I_SPI=46619F60E8047DD2 R_SPI=D147D5161FE56C88 (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_AUTH_FAIL
IKEv2-INTERNAL:Construct Notify Payload: AUTHENTICATION_FAILED
Payload contents:
NOTIFY(AUTHENTICATION_FAILED)
Next payload: NONE, reserved: 0x0, length: 8
Security protocol id: Unknown - 0, spi size: 0, type: AUTHENTICATION_FAILED



I don’t understand why the Peer1-via-1000 profile is selected for Peer3 if Peer3-via-1000 is specified in the config.

Just in case, I will show the settings of these profiles:

crypto ikev2 profile peer1-via-1000
match identity remote any
authentication remote pre-share
authentication local pre-share
keyring local keyring-peer1-via-1000

crypto ikev2 keyring keyring-peer1-via-1000
peer peer1
address xxx.xxx.xxx.11
pre-shared-key iphooxi0IChi

crypto ikev2 profile peer3-via-1000
match identity remote any
authentication remote pre-share
authentication local pre-share
keyring local keyring-peer3-via-1000
lifetime 28800

crypto ikev2 keyring keyring-peer3-via-1000
peer peer3
address xxx.xxx.xxx.33
pre-shared-key vahN0if0eegh

Thanks!

P.S. This is my first post.
P.S. Sorry for the English, it is not my native language.

1 Accepted Solution

Accepted Solutions

@maxnetstat like I said you have nothing in your IKEV2 profiles to distinguish between the peers, because you are matching the remote identity on any hence why the connection matches on peer1-via-1000 ikev2 profile. If you want to use multiple IKEv2 profiles, then match the remote identity address. Example:

crypto ikev2 profile peer1-via-1000
 match identity remote address  xx.xx.xx.11 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keyring-peer1-via-1000

crypto ikev2 profile peer3-via-1000
 match identity remote address  xx.xx.xx.33 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keyring-peer3-via-1000
 lifetime 28800

Using one IKEV2 profile and keyring per peer is not scalable with a large number of VPNs. As an alternative you could just use one IKEv2 profile (matching on any) and one IKEv2 keyring, but define multiple peers (matching on the peer IP addresses to distinguish between the peers) in the single keyring, with a unique PSK per peer.

View solution in original post

5 Replies 5

@maxnetstat there is nothing to distinguish between ikev2 profile peer1-via-1000 and ikev2 profile peer3-via-1000 because you are matching on the remote identity any. You can just use the one IKEv2 profile and rely on the IKEv2 keyring with the multiple entries to authenticate the peers.

Reset the PSK for peer3 on both your router and the peer device

M02@rt37
VIP
VIP

Hello @maxnetstat,

Regarding the debug output you've provided, it appears that the IKEv2 negotiation is failing due to an authentication issue. The selected profile for Peer1 is being used for Peer3, which is likely causing the authentication failure.

The debug logs indicate that the IKEv2 profile "peer1-via-1000" is being selected for Peer3, which is not expected based on your configuration. It seems there might be a mismatch or misconfiguration that is leading to this behavior.

--Modify the IKEv2 profiles to ensure that the correct keyring is associated with each profile. In your provided configuration, it seems that both the "peer1-via-1000" and "peer3-via-1000" profiles are using the same keyring "keyring-peer1-via-1000". Make sure that each profile is associated with its corresponding keyring.

--Update the "peer3-via-1000" profile to use the correct keyring associated with Peer3's IP address:

crypto ikev2 profile peer3-via-1000
match identity remote any
authentication remote pre-share
authentication local pre-share
keyring local keyring-peer3-via-1000
lifetime 28800

--Create a separate keyring for Peer3 with the correct pre-shared key associated with Peer3's IP address:

crypto ikev2 keyring keyring-peer3-via-1000
peer peer3
address xxx.xxx.xxx.33
pre-shared-key Your_Peer3_PSK_Here

--Do "clear crypto session" command to clear these associations.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

maxnetstat
Level 1
Level 1

I'm sorry, but I made a typo in the config and therefore misled you.
For peer 3, not keyring-peer1-via-1000 is used, but keyring-peer3-via-1000 (corrected in the first post)

the profile is correct, but another one is selected

@maxnetstat like I said you have nothing in your IKEV2 profiles to distinguish between the peers, because you are matching the remote identity on any hence why the connection matches on peer1-via-1000 ikev2 profile. If you want to use multiple IKEv2 profiles, then match the remote identity address. Example:

crypto ikev2 profile peer1-via-1000
 match identity remote address  xx.xx.xx.11 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keyring-peer1-via-1000

crypto ikev2 profile peer3-via-1000
 match identity remote address  xx.xx.xx.33 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keyring-peer3-via-1000
 lifetime 28800

Using one IKEV2 profile and keyring per peer is not scalable with a large number of VPNs. As an alternative you could just use one IKEv2 profile (matching on any) and one IKEv2 keyring, but define multiple peers (matching on the peer IP addresses to distinguish between the peers) in the single keyring, with a unique PSK per peer.

I did as you advised - it helped.
I didn't expect such behavior - I'll go further to read the documentation.
Thank you)