 IPSec VPN Palo Alto PA-5050 (with NAT-T) to Azure VNG failing initial connection

Felix Moleele 0 Reputation points
2025-06-05T18:38:45.4133333+00:00

Has anyone managed to get a IPSec VPN tunnel operational between a Palo Alto PA-5050 and an Azure Virtual network gateway?

PA-5050 (running PANOS 8.1.26-h1):

User's image

Azure Virtual Network Gateway:

local_network_gateways = {
  lg01 = {
 x"
    gateway_address   = "217.135.163.65"
    address_space     = ["10.44.0.0/16"]
    remote_bgp_settings = {
      asn                 = "65010"
      bgp_peering_address = "217.135.163.65"
      peer_weight         = 10
    }
    connection = {
      name = "vpn-cua-az-ux-01"
      ipsec_policies = [{
        dh_group         = "DHGroup14"
        ike_encryption   = "AES256"
        ike_integrity    = "SHA256"
        ipsec_encryption = "AES256"
        ipsec_integrity  = "SHA256"
        pfs_group        = "PFS14"
      }]
      mode       = "Default"
      shared_key = "duwQnroU4ogBhTZM7Jmdgtye9SCdxKp0"
Azure VPN Gateway
Azure VPN Gateway
An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
1,808 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Praveen Bandaru 5,520 Reputation points Microsoft External Staff Moderator
    2025-06-05T20:01:47.1+00:00

    Hello Felix Moleele

    I understand you're experiencing difficulties establishing an IPSec VPN tunnel between your Palo Alto PA-5050 and the Azure Virtual Network Gateway.

    • Ensure that both the Azure Virtual Network Gateway and the Palo Alto device are configured for IPSec (IKEv2). Azure’s policy supports route-based configurations, so confirm that your setup is not using policy-based (IKEv1).
    • Make sure the IP definition for the Local Network Gateway in Azure matches the external IP address of the PA-5050. Also, verify that the Azure gateway IP is correctly defined in the Palo Alto device.
    • Double-check that the shared key in the Palo Alto configuration matches the one configured in the Azure VPN Gateway, as a mismatch can cause the tunnel to fail.
    • If PFS is enabled on the PA-5050, consider disabling it temporarily to see if it resolves the issue, as it can lead to disconnections or failures.

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

    1. Share the parameters for both phase 1 and phase 2 of your Azure and on-prem VPN configurations screen shot.
    2. Please ensure that the on-prem private address prefixes are properly configured on the LNG.
    3. 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 you're using. https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#devicetable
    4. 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
    5. 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
    6. Provide the IP range's of your on-premises network and azure that connects via Site-to-Site VPN.
    7. 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
    8. 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.
    9. 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 issuehttps://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.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.