FPR 2130 (ASA-Image): Unable to change S2S-Tunnel from IKEv1 to IKEv2

[swscco001]

Hello everybody,

our customer has a Firepower 2130 running ASA-image rel. 9.14(3)18 and it has 
hundrets of S2S tunnels configured.

We are in the process to change all S2S tunnels from IKEv1 to IKEv2 and
in the most cases it is not a problem.

But this time the peer is a Palo Alto firewall and we were unable to bring a IKEv2 tunnel up
even if we have identical parameters (see attached) in both phases and the same PSK.

In the ASA logging I don't see something for the peer IP 195.225.32.241.

I took a debug output (attached) of the commands:

debug crypto ikev2 platform 255
debug crypto ikev2 protocol 255
debug crypto ipsec 255
debug crypto cond peer 195.225.32.241

I just can find the output:

IKEv2-PLAT-5: (2232): SENT PKT [IKE_SA_INIT] [185.247.62.10]:500->[195.225.32.241]:500 InitSPI=0x82ebe38ee0175179 RespSPI=0x0000000000000000 MID=00000000
IKEv2-PROTO-7: (2232): SM Trace-> SA: I_SPI=82EBE38EE0175179 R_SPI=0000000000000000 (I) MsgID = 00000000 CurState: I_WAIT_INIT Event: EV_NO_EVENT

Seems that the peer does not reply and showing the SPI=0000000000000000.

How would you interpret the outputs to this peer IP address?

Thanks a lot for your hints!



Bye
R.

[Rob Ingram]

@swscco001 What PRF cipher is configured on both sides? SHA256?

There are several authentication failed messages in the logs, can you re-enter the PSK on both sides and try again.

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

IKEv2-PROTO-4: (14650): Verification of peer's authentication data FAILED

(14650): Security protocol id: IKE, spi size: 0, type: AUTHENTICATION_FAILED

(6537): NOTIFY(AUTHENTICATION_FAILED)(6537): Next payload: NONE, reserved: 0x0, length: 8

[swscco001]

Hi Rob,

thanks for your reply!

The same PSK has worked before as the tunnel was still IKEv1 und after the failed attempt
it worked again with IKEv1. We can try it with re-entering the PSK on both sides or make
a test with a simple short PSK:

Thanks a lot!



Bye
R.

[MHM Cisco World]

Identical parameters <<- this need to check

First check encrypt algorithms' the cisco used it name not standard name of algorithms 

For example aes 128 the cisco named it aes-cbs 128 

So share excatly named of algorithms (encrypt and hash) for both 

Second the DH group you use group 14 which I dont think it available in all other vendor. 

All above make auth failed 

MHM

[swscco001]

Hi MHM,

we have tried all variants of AES and the peer's Palo Alto firewall has DH14 too.

But anyway we didn't get a tunnel up.

Is there any other test we could try?

Thnks a lot!



Bye
R.

[MHM Cisco World]

Sorry  for late reply' I see your reply now.

Ok' the policy is match in both side.

Can ypu share same debug but one by one' when you enable all debug It be difficult to detect issue.

Enable one the  copy result the  enable second etc.

Thanks 

MHM

[Aref Alsouqi]

Could you please share the sanitized screenshot of the tunnel configs of the Palo and the sanitized config snippet of that tunnel from the ASA for review?