Palo AltoConfig925 downloads

Palo Alto Site-to-Site IPSec VPN

IKEv2 site-to-site IPSec VPN tunnel on Palo Alto PAN-OS. Generates IKE crypto profile, IPSec crypto profile, IKE gateway, IPSec tunnel, and tunnel interface.

↓ example.txt

What is it?

Palo Alto's IPSec VPN implementation uses the same two-phase approach as all IPSec: IKE Phase 1 negotiates the management channel, Phase 2 establishes the data tunnel. PAN-OS requires four objects: (1) IKE Crypto Profile (Phase 1 algorithms), (2) IPSec Crypto Profile (Phase 2 algorithms), (3) IKE Gateway (peer address and auth), and (4) IPSec Tunnel (links everything together on a tunnel interface). The tunnel interface is added to a dedicated VPN zone, and security policies control what traffic is allowed between the VPN zone and internal zones. The IKE version is not a detail: it changes which sub-tree of the IKE Gateway you configure ('protocol ikev1 ...' versus 'protocol ikev2 ...'), IKEv1 adds an exchange mode (main or aggressive) that IKEv2 does not have, and PAN-OS restricts AES-GCM for ESP and IKE fragmentation to IKEv2. Both ends must agree on the version — an IKEv2-only gateway facing an IKEv1-only peer never reaches Phase 1, and the log says only that no proposal was chosen.

When to use

·Site-to-site connectivity to branch offices over the internet
·Connecting to AWS, Azure, or GCP VPN Gateways
·Partner/vendor network connectivity where full SD-WAN is not justified
·Disaster recovery connectivity between primary and backup sites
·IKEv1 specifically: an old peer that does not speak IKEv2 at all, or a device whose IKEv2 implementation you do not trust. It still exists in the field and a tunnel that comes up beats a standard that does not

When NOT to use

·Remote user VPN — use GlobalProtect (SSL VPN) instead, which provides better user experience
·If both sites have Palo Alto firewalls — consider GlobalProtect Cloud Service or SD-WAN for better visibility
·Do not pick IKEv1 when the peer supports IKEv2. IKEv1 has no built-in liveness check (DPD is bolted on), no MOBIKE, a weaker rekey story, and it costs you AES-GCM for ESP and IKE fragmentation on PAN-OS
·Do not pick IKEv1 aggressive mode with a pre-shared key on a public address — it sends the identity and a PSK hash in the clear in the first exchange, which is offline-crackable. Aggressive mode exists for a peer with a dynamic IP, and even then main mode with a peer ID is usually possible

How it compares

vs Cisco IOS IPSecCisco uses crypto maps applied to physical interfaces. Palo Alto uses tunnel interfaces (tunnel.1, tunnel.2) in dedicated VPN zones — cleaner architecture and easier to apply security policies to VPN traffic.

vs Cisco ASA IPSecASA also supports both crypto maps and tunnel interfaces (VTI). Palo Alto's model is closer to ASA VTI — dedicated tunnel interface in a zone, security policy controls traffic.

vs IKEv1 instead of IKEv2 on the same PAN-OS gatewaySame objects, different sub-tree. IKEv1 adds an exchange mode (main protects the identity, aggressive does not) and needs one proxy-id per subnet pair; IKEv2 carries every traffic selector in one child SA, has liveness built in, and is the only version on which PAN-OS allows AES-GCM for ESP and IKE fragmentation. Choose IKEv1 only because the peer forces it.

vs GlobalProtect VPNGlobalProtect is Palo Alto's SSL VPN for individual remote users. IPSec site-to-site is for entire network-to-network connectivity. Different tools, different use cases.

Prerequisites

→A dedicated VPN zone must exist (e.g., 'vpn-zone') before tunnel interface can be assigned
→The virtual router must be configured to route traffic to the remote subnet via the tunnel interface
→IKE Phase 1 and Phase 2 parameters must match exactly with the remote peer — including the IKE version. Confirm with the far end which version they are configured for before you generate this
→AES-GCM for ESP and IKE fragmentation require IKEv2 on PAN-OS. On IKEv1, pick a CBC cipher plus an ESP authentication algorithm
→PAN-OS 7.1 or later for IKEv2 on the IKE Gateway; 8.1 or later for IKEv2 fragmentation
→Proxy IDs must be configured if the remote peer uses policy-based VPN (Cisco ASA, IOS)
→NAT exemption rule needed if source NAT is configured for internet traffic

Config Generator

Hostname *

Tunnel Interface ID *

Tunnel Zone *

Local Public IP *

Remote Peer IP *

Pre-Shared Key *

Virtual System

IKE Version

IKEv1 exchange mode (ignored on IKEv2)

IKE DH Group

IKE Encryption

IKE Authentication

ESP Encryption

ESP Authentication

Virtual Router

Proxy IDs (interesting traffic)

Verification commands

show vpn ike-sa

Verify IKE Phase 1 security association is established

ExpectedShows SA with peer IP, state 'established', and DH group. If empty, Phase 1 failed.

show vpn ipsec-sa

Verify IPSec Phase 2 tunnel and packet counters

ExpectedShows tunnel with encap/decap packet counts. Zero counts mean traffic isn't hitting the tunnel.

show vpn tunnel

Show all IPSec tunnels and their state

ExpectedTunnel status should show 'active'. State 'init' means Phase 2 has not completed.

Debug commands

test vpn ike-sa gateway GW-<peer-ip>

Initiate IKE negotiation to test Phase 1

Common mistakes & fixes

SymptomNo IKE SA at all, nothing in 'show vpn ike-sa', and the system log says only 'IKE protocol version mismatch' or 'no proposal chosen'

CauseThe two ends are configured for different IKE versions. An ikev2-only gateway silently drops an IKEv1 initiator, and vice versa — there is no fallback

FixRun 'show vpn ike-sa gateway GW-<peer-ip>' and compare 'protocol version' with the far end. Set both to the same version, or set this side to 'ikev2-preferred' by hand if you need it to answer either while a peer is migrated

SymptomCommit fails with an ESP encryption error, or the IPSec crypto profile will not accept aes-256-gcm

CauseAES-GCM for ESP is IKEv2-only on PAN-OS, and the gateway is set to IKEv1

FixEither move the gateway to IKEv2, or change ESP Encryption to aes-256-cbc and set an ESP Authentication algorithm — GCM is authenticated encryption, so the CBC path needs the separate hash back

SymptomIKEv1 tunnel comes up from one side only, or fails whenever the branch reboots with a new address

CauseExchange mode mismatch, or main mode against a peer with a dynamic IP that can only identify itself in aggressive mode

FixMatch exchange-mode on both ends. For a dynamic-IP peer use a peer ID (FQDN or KEYID) with main mode where the platform allows it, and only fall back to aggressive mode knowing it exposes the PSK hash

SymptomIKE SA not establishing — tunnel stays in 'init'

CauseUDP 500/4500 blocked, wrong PSK, or IKE proposal mismatch

FixVerify UDP 500 is reachable from outside. Check 'show vpn ike-sa gateway' for error messages. Verify pre-shared key matches on both sides.

SymptomPhase 1 up but Phase 2 not establishing

CauseIPSec proposal mismatch or proxy ID mismatch with policy-based VPN peer

FixVerify IPSec crypto profile matches remote peer. If remote uses policy-based VPN, add proxy IDs matching the remote peer's crypto ACL (mirror image).

SymptomVPN tunnel up but no traffic passing

CauseMissing static route to remote subnet via tunnel interface, or security policy blocking VPN zone traffic

FixAdd route to remote network via tunnel.X interface. Verify security policy allows traffic between vpn-zone and trust/untrust.

Further learning

Recommended books to go deeper on this topic.

Palo Alto Networks Firewall Deployment and Administration

Tom Piens · Packt · IPsec VPN on PAN-OS — IKEv1/v2, GlobalProtect, tunnel configuration

Kindle ↗Hardcover ↗Paperback ↗

Cisco ASA: All-in-One Next-Gen Firewall, IPS, and VPN Services

Jazib Frahim, Omar Santos, Andrew Ossipov · Cisco Press · IKE phase 1 & 2 deep dive — concepts apply to all vendors

Kindle ↗Hardcover ↗