L2L IPSec not negotiating properly for ASA to ISR router

[baskervi]

We are trying to bring up a tunnel with a partner with an ASA on our end and an ISR 4451 router on theirs. We've compared configurations several times but can't come up with any misconfiguration. Pertinent configurations for both ends are at the bottom. Both sides have multiple IKEv2 IPSec tunnels active with no issues.

Our ASA will show phase 1 and phase 2 are negotiated for a minute or so before it renegotiates the tunnel, and the ASA will typically show 2-12 packets encrypted. The router never shows phase 1 as active. After 20 minutes or so, the ASA will start throwing up authentication failures as shown below. We even tried "Password" as the PSK, exact same behavior. The router may occasionally see phase 1 negotiating although generally not.

Does anyone have a suggestion? Thanks

(39): 

IKEv2-PROTO-2: (39): Received Packet [From 206.227.221.173:4500/To 10.10.10.10:4500/VRF i0:f0]

(39): Initiator SPI : BE72713DE996BDAD - Responder SPI : 548AA3DBE356CF92 Message id: 1

(39): IKEv2 IKE_AUTH Exchange RESPONSEIKEv2-PROTO-3: (39): Next payload: ENCR, version: 2.0 (39): Exchange type: IKE_AUTH, flags: RESPONDER MSG-RESPONSE (39): Message id: 1, length: 80(39): 

Payload contents:

IKEv2-PROTO-1: decrypt queued(39): 

(39): Decrypted packet:(39): Data: 80 bytes

IKEv2-PROTO-1: Asynchronous request queued

IKEv2-PROTO-1:

(39): REAL Decrypted packet:(39): Data: 8 bytes

IKEv2-PROTO-5: Parse Notify Payload: AUTHENTICATION_FAILED NOTIFY(AUTHENTICATION_FAILED)  Next payload: NONE, reserved: 0x0, length: 8

    Security protocol id: Unknown - 0, spi size: 0, type: AUTHENTICATION_FAILED

IKEv2-PROTO-5: (39): SM Trace-> SA: I_SPI=BE72713DE996BDAD R_SPI=548AA3DBE356CF92 (I) MsgID = 00000001 CurState: I_WAIT_AUTH Event: EV_RECV_AUTH

IKEv2-PROTO-5: (39): Action: Action_Null

IKEv2-PROTO-5: (39): SM Trace-> SA: I_SPI=BE72713DE996BDAD R_SPI=548AA3DBE356CF92 (I) MsgID = 00000001 CurState: I_PROC_AUTH Event: EV_CHK4_NOTIFY

IKEv2-PROTO-2: (39): Process auth response notify

IKEv2-PROTO-1: (39):

IKEv2-PROTO-5: (39): SM Trace-> SA: I_SPI=BE72713DE996BDAD R_SPI=548AA3DBE356CF92 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_FAIL

IKEv2-PROTO-2: (39): Auth exchange failed

IKEv2-PROTO-1: (39): Auth exchange failed

IKEv2-PROTO-1: (39): Auth exchange failed

IKEv2-PROTO-5: (39): SM Trace-> SA: I_SPI=BE72713DE996BDAD R_SPI=548AA3DBE356CF92 (I) MsgID = 00000001 CurState: EXIT Event: EV_ABORT

IKEv2-PROTO-5: (39): SM Trace-> SA: I_SPI=BE72713DE996BDAD R_SPI=548AA3DBE356CF92 (I) MsgID = 00000001 CurState: EXIT Event: EV_CHK_PENDING_ABORT

IKEv2-PROTO-5: (39): SM Trace-> SA: I_SPI=BE72713DE996BDAD R_SPI=548AA3DBE356CF92 (I) MsgID = 00000001 CurState: EXIT Event: EV_UPDATE_CAC_STATS

IKEv2-PROTO-2: (39): Abort exchange

IKEv2-PROTO-2: (39): Deleting SA

=== ISR Config ===
crypto ikev2 proposal XXX
encryption aes-cbc-256
integrity sha256
group 14

crypto ipsec transform-set ESP-AES256-SHA256 esp-aes 256 esp-sha256-hmac
mode tunnel

crypto ikev2 profile profile-XXX
match fvrf any
match address local 1.1.1.1
match identity remote address 2.2.2.2 255.255.255.255
authentication local pre-share
authentication remote pre-share
keyring local keyring-XXX

crypto map outside-crypto XXX ipsec-isakmp
set peer 2.2.2.2
set security-association lifetime seconds 86400
set transform-set ESP-AES256-SHA256
set ikev2-profile profile-XXX
match address encrypt-acl-XXX

ip access-list extended encrypt-acl-XXX
permit ip 3.3.3.0 0.0.0.255 4.4.4.0 0.0.0.255

=== /ISR Config ===

=== ASA Config ===
access-list VPN-INTERESTING-TRAFFIC extended permit ip 4.4.4.0 255.255.255.255 3.3.3.0 255.255.255.255

crypto ipsec ikev2 ipsec-proposal VPN-TRANSFORM
 protocol esp encryption aes-256
 protocol esp integrity aes256

crypto map CRYPTO-MAP 10 match address VPN-INTERESTING-TRAFFIC
crypto map CRYPTO-MAP 10 set peer 1.1.1.1
crypto map CRYPTO-MAP 10 set ikev2 ipsec-proposal VPN-TRANSFORM
crypto map CRYPTO-MAP 10 set security-association lifetime seconds 86400

crypto ikev2 policy 1
 encryption aes-256
 integrity sha256
 group 14
 prf sha256

 lifetime seconds 86400

tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key ***
 ikev2 local-authentication pre-shared-key ***
=== /ASA Config ===

[Rob Ingram]

Hi,

Check your pre-shared key is correct on both devices.

On the ASA, for the ipsec-proposal you have the integrity as aes256, this should be sha-256

On the router, under the ikev2 profile remove the match address local 1.1.1.1 and add identity local address 1.1.1.1

HTH

[baskervi · Accepted solution]

Thanks for your input.

Pre-shared key is the same. We used "Password" just to confirm. 20 minutes, and authentication issues occur. Change the PSK, and it works another 20 minutes. At least on our side.

My bad on the ASA config in the original post. I was 2 remote sessions away from the ASA - I could type but not copy and paste. The config change you noted was part of the initial running configuration.

The remote site made the router change. No change in behavior. 

[baskervi]

We have the problem resolved, and I left out a key piece of information. I didn't realize this until after the fact. The company has implemented the VPN ASA to be behind another ASA, and the public IP of the VPN ASA is an RFC 1918 address. After multiple days of trying to get the tunnel up, the folks at the remote end agreed to turn on debugging. The authentication issue was that the router was seeing the ASA as advertising it's identity with the private iP.

40608193: IKEv2:(SESSION ID =,SA ID = ):Searching policy based on peer's identity '10.10.10.10' of type 'IPv4 address'

The interesting thing is that we have a handful of tunnels to other devices (both IKEv1 and v2), and they are working fine. We have to figure out a way around this, because the company on the other end of the tunnel won't permit them to include a "remote identity" statement in the config, but that's another issue.

Thanks

[pboynton1]

Rob!!!!!

Just a solid thankyou as you NAILED my problem after daysssss of searching.  It is so annoying that cisco made these 2 commands sound like the same thing.  Sounds like you know your cryptoing!  Any insight in to the difference in these two commands?