VPN Concepts, Troubleshooting, and Testing

🔄 Route-Based VPNs vs. Policy-Based VPNs

Palo Alto Networks firewalls exclusively support route-based VPNs and do not natively support policy-based VPNs . However, they can interoperate with policy-based VPN peers by configuring appropriate Proxy IDs .

In a route-based VPN :

This approach provides flexibility and scalability, especially in complex network topologies.

In contrast, policy-based VPNs define "interesting traffic" (what to encrypt) using specific security policies or access lists. Traffic is not routed to a tunnel interface but is processed by these policies.

📊 Comparison: Route-Based vs. Policy-Based VPNs

Feature Route-Based VPNs Policy-Based VPNs
Tunnel Interface Required Not used
Routing Decision Based on routing table Based on security policy/access list
Dynamic Routing Support Supported Not supported
NAT Support Supported Limited
Scalability High Limited due to multiple SAs/policies
Vendor Support Examples Palo Alto Networks, Juniper SRX, Cisco (VTI) Cisco ASA (pre-9.7 without VTI), Check Point (traditional mode)

🛠️ Troubleshooting VPNs

Test and troubleshoot your IPSec VPN connection for its maximum performance. Before testing the VPN connectivity familiarize yourself with the common VPN error messages. The following table lists some of the common VPN error messages that are logged in the system log on Palo Alto Networks firewalls, along with recommended troubleshooting steps.

Syslog Error Message Recommended Action

IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: x.x.x.x[500]-y.y.y.y[500] cookie:84222f276c2fa2e9:0000000000000000 due to timeout.

or

IKE phase 1 negotiation is failed. Couldn’t find configuration for IKE phase-1 request for peer IP x.x.x.x[1929]

  • Verify that the public IP address for each VPN peer is accurate in the IKE Gateway configuration.

  • Verify that the IP addresses can be pinged and that routing issues aren’t causing the connection failure. Ensure firewalls/devices in the path are not blocking UDP 500 (or 4500 if NAT-T is expected).

Received unencrypted notify payload (no proposal chosen) from IP x.x.x.x[500] to y.y.y.y[500], ignored...

or

IKE phase-1 negotiation is failed. Unable to process peer’s SA payload.

Check the IKE Crypto profile configuration to verify that the proposals on both sides have a common encryption, authentication, and DH Group proposal. Ensure lifetimes also match (though sometimes non-matching lifetimes are accepted).

pfs group mismatched:my: 2peer: 0

or

IKE phase-2 negotiation failed when processing SA payload. No suitable proposal found in peer’s SA payload.

Check the IPSec Crypto profile configuration to verify that:

  • PFS is either enabled or disabled on both VPN peers, and if enabled, the DH Groups proposed by each peer have at least one DH Group in common.

  • The encryption and authentication algorithms in the IPsec proposals match on both sides.

IKE phase-2 negotiation failed when processing Proxy ID. Received local id x.x.x.x/x type IPv4 address protocol 0 port 0, received remote id y.y.y.y/y type IPv4 address protocol 0 port 0.

This error is common when a Palo Alto Networks firewall (route-based) is connecting to a policy-based VPN peer. You must configure Proxy IDs on the Palo Alto Networks firewall under the IPsec Tunnel configuration that exactly match the traffic selectors (often defined by an Access List or Crypto Map) on the policy-based peer.

See  Create a Proxy ID to identify the VPN peers .

Commit error: Tunnel interface tunnel.x multiple binding limitation (xx) reached.

This indicates you have exceeded the maximum number of Proxy IDs allowed to be bound to a single tunnel interface on your firewall model.

To resolve this:

  • Review your firewall model's specifications for the maximum Proxy ID limit per tunnel.

  • If possible, Supernet the IP addresses used in the Proxy IDs (e.g., use 10.0.0.0/8 instead of multiple /16 or /24 networks) to reduce the number of required Proxy IDs.

  • If supernetting isn't feasible or sufficient, configure additional tunnel interfaces (with the same Phase 1/Phase 2 settings) and distribute the Proxy IDs across them.

Proxy ID mismatch

Proxy ID  mismatch is a common cause of Phase 2 failure. Configure Proxy IDs on both VPN peers such that they are exact mirrors or opposites of each other.

For example: If Firewall A has Local ID 192.0.2.0/24 and Peer ID 10.0.0.0/24, Firewall B must have Local ID 10.0.0.0/24 and Peer ID 192.0.2.0/24.

Remember that Proxy IDs on Palo Alto Networks firewalls correspond to Access Lists or Traffic Selectors used by other vendors (like Cisco ASA or Check Point).

Test VPN Connectivity Steps (Palo Alto Networks CLI)

Perform these tasks to test VPN connectivity using the Palo Alto Networks CLI. These steps help verify IKE Phase 1 and Phase 2 status.

  1. Initiate IKE phase 1 by either pinging a host across the tunnel (traffic initiates negotiation) or using the following CLI command:

    test vpn ike-sa gateway
  2. Enter the following command to check if IKE phase 1 is established:

    show vpn ike-sa gateway

    Look for a state indicating the SA is active (e.g., `ST_ACTIVE`). If it's not active, review the system logs for messages related to IKE negotiation to identify the cause (refer to the error table above).

  3. Initiate IKE phase 2 (IPsec SA) by either pinging a host from across the tunnel (using traffic matching the Proxy IDs) or using the following CLI command:

    test vpn ipsec-sa tunnel
  4. Enter the following command to check if IKE phase 2 is established:

    show vpn ipsec-sa tunnel

    Look for the SA status and check encapsulation/decapsulation counters. If SAs are not formed, review system logs for IPsec negotiation errors (refer to the error table above, especially regarding Proxy IDs and IPsec proposals).

  5. To view the VPN tunnel's operational status and associated flow information, use the following command:

    show vpn flow

    This command shows configured tunnels and their current state (e.g., active, down). It's useful for quickly seeing if the tunnel is up.

    Example output:

    total tunnels configured:              1
    filter - type IPSec, state any
    
    total IPSec tunnel configured:       1
    total IPSec tunnel shown:            1
    
    name             id   state   local-ip     peer-ip     tunnel-i/f
    -----------------------------------------------------------------------------------
    vpn-to-siteB     5    active  100.1.1.1    200.1.1.1   tunnel.41
                
  6. Use packet capture and traffic logs to verify if traffic is hitting the firewall, being correctly identified, and routed through the tunnel interface, and if encrypted/decrypted packets are seen on the external interface.

    debug ike pcap start
    debug ike pcap stop
    view-pcap debug-pcap ikemgr.pcap
    debug flow basic filter match source destination
    show counter global filter packet-filter yes delta yes | match tunnel

General VPN Troubleshooting Flow

This diagram provides a general flow to follow when troubleshooting VPN connectivity issues.

General VPN Troubleshooting Decision Tree

IKE Phase 1 & 2 Negotiation Flow with Troubleshooting Points

This sequence diagram illustrates the IKE negotiation process and where common errors occur.

IKE Phase 1 & 2 Negotiation Flow with Troubleshooting Notes

💡 VPN Troubleshooting Quiz

1. Based on the troubleshooting table, if you see the error "IKE phase-1 negotiation is failed as initiator... due to timeout," what is one of the first things you should verify?

2. The error message "Received unencrypted notify payload (no proposal chosen)..." typically indicates a mismatch in which part of the VPN configuration?

3. If a Palo Alto Networks firewall is connecting to a policy-based VPN peer and IKE Phase 2 fails with a message about "processing Proxy ID," what is the recommended action?

4. Which CLI command sequence is used to first attempt to bring up IKE Phase 1 and then verify its status on a Palo Alto Networks firewall?

5. According to the troubleshooting information, how should Proxy IDs be configured between two VPN peers (e.g., Firewall A and Firewall B) for them to successfully negotiate Phase 2 when Proxy IDs are required?