Share via

IPsec Tunnel from On-Prem Palo Alto to Azure VPN Gateway — Tunnel Up but No Traffic Flow

Nico J 0 Reputation points
2025-06-11T11:48:32.92+00:00

Hi there, just seeking if anyone has a similar setup or has gone through a similar issue with site to site VPN's and then traffic flow once connected.

Environment Overview:

  • On-premises: Palo Alto PA-850 (Palo B) behind a Mikrotik 4G router with DDNS
  • Azure: Palo Alto VM-Series (Palo A) in Hub VNet
  • VPN Gateway deployed in Spoke VNet (Route-based)
  • VNet peering between Hub and Spoke
  • Tunnel is initiated from Palo B and successfully establishes (all 3 status lights green)

Tunnel Configuration:

  • IPsec/IKE policy: Azure default (not custom)
  • Proxy IDs / Traffic Selectors:
    • Local: 172.16.44.0/22 (on-prem)
      • Remote: 172.20.0.0/20 (Azure)
      • Static routes and UDRs in place:
        • GatewaySubnet routes 172.16.44.0/22 to Palo A (172.20.0.68)
          • All other subnets route 0.0.0.0/0 to Palo A
          • Palo A has a route for 172.16.44.0/22 via eth2 (no next hop)
          • Security policies on both firewalls are open and logging is enabled

Symptoms:

  • Tunnel is up (IKE and IPsec SAs established)
  • No traffic is seen in logs or packet captures on either firewall
  • ICMP and TCP traffic from both sides show “no response”
  • Packet captures show no ingress traffic from the other side
  • Azure VM subnet has UDR pointing to Palo A for on-prem traffic
  • NSGs are not blocking traffic
  • Azure VM OS firewall is open for ICMP

Suspected Issue:

  • Azure VPN Gateway may not be forwarding traffic to Palo A or receiving it from on-prem
  • Possibly a misconfiguration in Azure VPN Gateway or routing behavior

What else can I check or configure in Azure to ensure traffic from the VPN Gateway is properly routed to Palo A and back? Are there known limitations or diagnostics I can enable to trace traffic through the Azure VPN Gateway?

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 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Praveen Bandaru 11,465 Reputation points Microsoft External Staff Moderator
    2025-06-11T16:52:28.53+00:00

    Hello Nico J

    I understand that you're experiencing issues with your VPN connection between your on-prem Palo Alto to Azure VPN 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. 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 Palo Alto, consider disabling it temporarily to see if it resolves the issue, as it can lead to disconnections or failures.
    • 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 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

    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. The IPSec lifetime values for your VPN setup screen shot.
    3. 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

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

    Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Your answer

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