Cisco ASA S2S IKEv2 to Palo Alto Tunnel Unstable

[Akmal Zamin]

Hi All, 

I've configured tunnel from Cisco Asa to Palo Alto device. The tunnel is established but then once they reached the tunnel time out and try to establish the tunnel again it, the tunnel down/unstable.

This is my config for Cisco ASA: 
Phase 1:
IKE encryption: AES256
IKE Hash: SHA256
Lifetime: 8hrs

DH Group: Group 14

Phase 2:
Encryption: AES256
Hash: SHA256

Lifetime: 1hr

DH Group: Group 14

From pcap file generated from palo,

I can see palo alto is trying to request the create child sa with a payload(lentgh) of 570 to cisco asa but then from cisco asa it replies with a different payload which is 122. Is this triggering the tunnel to fail/unstable when it try to establish again?

[Sheraz.Salim]

Hi. Could you please confirm what are the setting are configured at the remote side Palo Alto firewall. for Ikev1 you need to match the phase 1 lifetime setting. in case if one of the side is using lower life time. the lower life time has a more priority to get agreed but when rekey exchange happens it could cause the tunnel to go down.

[Akmal Zamin]

Hi Sheraz, I have confirmed that the remote side already configured the same lifetime setting as me. All the encryption at the remote side has already matched and the tunnel is able to establish. Then, by the time the tunnel reached the lifetime and try to establish again, it fails. Btw, I forgot to mention that this tunnel is using Ikev2 only not Ikev1.

I'm still trying to figure out on how does the create_child_sa works. Does the create_child_sa response payload(length) has to be the same as the request payload that causing the tunnel to be failing?

[Sheraz.Salim]

My bad i did not realized it is indeed a IKev2. I miss read it. how long the tunnel stay up? could you get the logs on the firewalls at both ends?

[MARK BAKER]

Akmal,

Did you get this working? I believe I am currently running into the same issue and it looks like we have the same settings configured. The majority of IKEv2 rekeys happen without a problem, but I see an issue with it every few days and the tunnel is down for around a minute before it stabilizes. There are IKEv2 failure logs during the time it is trying to come back up. Unfortunately, the log messages aren't very clear on what is failing.

Thank you,
Mark

[RyanB]

Me too, i have no idea what the issue is. Rekeying succeeds like 90% of the time, but every few days the tunnel will drop during the rekey. Then for anywhere between 15 seconds and 15 minutes, both sides will continually try to rebuild/delete the tunnel before it eventually succeeds on both sides.

[MARK BAKER]

I changed to IKEv1 and it is stable now. When I configured the ASA for v1, it said one side had to be responder only. The Palo was set to responder only. I wonder if Setting the Palo to responder only with IKEv2 would have worked also. I couldn’t test this in my change window.

The same Palo also had a IKEv2 rekey issue to a Juniper. IKEv1 fixed that issue too.

[shane.ryan]

I have similar seen issues with IKEv2 tunnels between ASA and PA. Most of these instances I have found that the Palo Alto end of the tunnel is configured for AES-256 (GCM) either as a primary or secondary policy and not the Cisco default AES-256 (CBC). The exchange is handled differently with GCM and does not allow the tunnel to renegotiate. Switching the PA side to AES-256-CBC only has seemed to fix this issue.