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.
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) |
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] |
|
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:
|
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. |
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:
|
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). |
Perform these tasks to test VPN connectivity using the Palo Alto Networks CLI. These steps help verify IKE Phase 1 and Phase 2 status.
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
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).
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
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).
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
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
This diagram provides a general flow to follow when troubleshooting VPN connectivity issues.
General VPN Troubleshooting Decision Tree
This sequence diagram illustrates the IKE negotiation process and where common errors occur.
IKE Phase 1 & 2 Negotiation Flow with Troubleshooting Notes