Tunnel Rekey Failure Between Azure VPN Gateway and Palo Alto

Question

Tunnel Rekey Failure Between Azure VPN Gateway and Palo Alto

Vitor Garcia 20

We are experiencing recurring and random Phase 2 (IPSec) rekey negotiation failures between our Azure VPN Gateway and the customer's Palo Alto firewall. The initial establishment works as expected, but the second key exchange consistently fails, causing the tunnel to stop passing traffic after the Security Association (SA) expires.

We are using Microsoft’s recommended configuration on both the Azure and Palo Alto sides. We’ve tried setting both sides to passive, active, and default modes, including variations of DPD parity.

The tunnel does not disconnect — it remains in a connected state — but no traffic flows through it. It appears to be an SPI key asymmetry issue. On the Azure side, we are unable to see the current SPI in the Network Monitor (Workspace) logs — only the OLD value is available.

The customer’s PAN-OS is running version 10.

We have strictly followed Microsoft’s documentation, but the issue still persists.

This situation is becoming critical with the customer, and we urgently need to schedule a call with Microsoft support to troubleshoot and resolve this issue as soon as possible.

Praveen Bandaru 5,520 Pontos de reputação Equipe Externa da Microsoft Moderador

2025-05-08T21:57:18.0033333+00:00
Hello Vitor Garcia

I understand that you are encountering recurring and random Phase 2 (IPSec) rekey negotiation failures between our Azure VPN Gateway and the customer's Palo Alto firewall.

To assist with further investigation, could you please provide the following information:

Share the parameters for both phase 1 and phase 2 of your Azure and on-prem VPN configurations screen shot.

Please ensure that the on-prem private address prefixes are properly configured on the LNG.

Ensure that both your Azure VPN Gateway and Palo Alto firewall are listed as validated VPN devices. Check if there might be a compatibility issue with the specific version of PAN-OS (10) you're using. https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#devicetable

If you're using default parameters, the on-prem parameters should be listed as below. Please check the reference document for Default IPsec/IKE parameters

And also, from your local on-prem machine, run a continuous psping test to the azure VM private IP address and share the result. psping command: ( psping -t privateip:portno ) Reference document for PsPing

Provide the IP range's of your on-premises network and azure that connects via Site-to-Site VPN.

Some users have found that changing the Diffie-Hellman (DH) group in the IPSec Crypto settings to match the remote peer resolved similar Phase 2 negotiation failures. For Azure peers, setting the DH group to No PFS has been suggested. Refer to this article:https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000008Uj1CAE

Palo Alto's tunnel monitoring works by pinging a destination address on the other side of the tunnel. Rekeying child SAs should not cause the tunnel monitor to bring the tunnel down, but Palo Alto does not store a log of all rekeys unless debugging is enabled.

Microsoft Azure requires IKEv2 for dynamic routing (route-based VPN). If you're using IKEv1, it is restricted to static routing only. Ensuring that your Proxy IDs match the expected traffic selectors might help resolve the issue. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm6WCAS

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Praveen Bandaru 5,520 Pontos de reputação Equipe Externa da Microsoft Moderador

2025-05-09T16:40:36.3833333+00:00

Hello Vitor Garcia

Following up to see if the above suggestion was helpful. And, if you have any further query do let us know.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to "accept answer" and “up-vote” wherever the information provided helps you, this can be beneficial to other community member

Resposta aceita

0 respostas adicionais

Sua resposta

Praveen Bandaru 5,520 Pontos de reputação Equipe Externa da Microsoft Moderador

2025-05-09T16:40:36.3833333+00:00

Hello Vitor Garcia

Following up to see if the above suggestion was helpful. And, if you have any further query do let us know.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to "accept answer" and “up-vote” wherever the information provided helps you, this can be beneficial to other community member

Answer 1

Hello Vitor Garcia

I understand that you are encountering recurring and random Phase 2 (IPSec) rekey negotiation failures between our Azure VPN Gateway and the customer's Palo Alto firewall.

To assist with further investigation, could you please provide the following information:

Share the parameters for both phase 1 and phase 2 of your Azure and on-prem VPN configurations screen shot.
Please ensure that the on-prem private address prefixes are properly configured on the LNG.
Ensure that both your Azure VPN Gateway and Palo Alto firewall are listed as validated VPN devices. Check if there might be a compatibility issue with the specific version of PAN-OS (10) you're using. https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#devicetable
If you're using default parameters, the on-prem parameters should be listed as below. Please check the reference document for Default IPsec/IKE parameters
And also, from your local on-prem machine, run a continuous psping test to the azure VM private IP address and share the result. psping command: ( psping -t privateip:portno ) Reference document for PsPing
Provide the IP range's of your on-premises network and azure that connects via Site-to-Site VPN.
Some users have found that changing the Diffie-Hellman (DH) group in the IPSec Crypto settings to match the remote peer resolved similar Phase 2 negotiation failures. For Azure peers, setting the DH group to No PFS has been suggested. Refer to this article:https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000008Uj1CAE
Palo Alto's tunnel monitoring works by pinging a destination address on the other side of the tunnel. Rekeying child SAs should not cause the tunnel monitor to bring the tunnel down, but Palo Alto does not store a log of all rekeys unless debugging is enabled.
Microsoft Azure requires IKEv2 for dynamic routing (route-based VPN). If you're using IKEv1, it is restricted to static routing only. Ensuring that your Proxy IDs match the expected traffic selectors might help resolve the issue. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm6WCAS

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Compartilhar via

Tunnel Rekey Failure Between Azure VPN Gateway and Palo Alto

0 respostas adicionais

Sua resposta