Palo Alto Site-to-Site IPsec VPN: CLI Configuration

Palo Alto firewalls are usually configured through Panorama or the web UI, but the CLI is faster to clone and easier to script - the official Palo Alto Networks knowledge base even recommends CLI commands for duplicating VPN tunnels. This guide walks through a complete route-based site-to-site IPsec VPN in PAN-OS CLI: creating the tunnel interface and zone, defining the IKE gateway and IPsec tunnel with crypto profiles, adding the static route, and verifying the tunnel state.

Before You Begin: Prerequisites and Naming

You need PAN-OS 10.1 or later (the command structure below is unchanged through 11.x), an administrative SSH session in configuration mode, and both firewalls reachable from each other on their public addresses with UDP 500 and UDP 4500 permitted end to end. If the peers sit behind NAT on either side, note it now - it changes the local-address you configure and whether you need NAT-T explicitly.

Decide on names before typing. PAN-OS CLI object names are case-sensitive and are referenced in several places, so a mismatch between the IKE gateway name and the name used inside the IPsec tunnel block produces a commit error that reads as if a profile is missing. The convention used here is NewYork-VPN for the gateway and tunnel, IPsec_Profile for the phase 2 crypto profile, and IKE_Profile for phase 1. Local subnet 192.168.2.0/24, remote subnet 192.168.3.0/24, local public address 100.100.100.1, peer 100.100.100.2.

One more decision: route-based or policy-based. This guide builds a route-based VPN with a tunnel interface, which is what you want when you plan to run dynamic routing, multiple subnets, or traffic that needs selective steering. Policy-based VPNs are covered briefly later as a comparison.

Step 0: Create the IKE and IPsec Crypto Profiles

The tunnel configuration references two profiles that must already exist. If your firewall has defaults you can skip this, but creating explicit profiles makes the crypto policy auditable and identical on both ends:

set network ike crypto-profiles ike-crypto-profile IKE_Profile encryption [ aes-256-cbc ]
set network ike crypto-profiles ike-crypto-profile IKE_Profile hash [ sha256 ]
set network ike crypto-profiles ike-crypto-profile IKE_Profile dh-group [ group14 ]
set network ike crypto-profiles ike-crypto-profile IKE_Profile lifetime hours 8
set network ike crypto-profiles ipsec-crypto-profile IPsec_Profile esp encryption [ aes-256-cbc ]
set network ike crypto-profiles ipsec-crypto-profile IPsec_Profile esp authentication [ sha256 ]
set network ike crypto-profiles ipsec-crypto-profile IPsec_Profile dh-group [ group14 ]
set network ike crypto-profiles ipsec-crypto-profile IPsec_Profile lifetime hours 1

Both ends must agree on every value in these lists. A DH-group mismatch is the single most common phase 1 failure, and PAN-OS reports it as a generic IKE negotiation failure with no hint about which parameter disagreed.

Step 1: Create the Tunnel Interface and Zone

set network interface tunnel units tunnel.10 comment "NewYork VPN"
set zone vpn network layer3 tunnel.10
set network interface tunnel units tunnel.10 zone vpn
set network interface tunnel units tunnel.10 ipv4 ip 172.19.9.2/24

With static routing a tunnel interface IP is optional (the firewall uses the tunnel as next-hop automatically), but assigning one enables tunnel monitoring.

A tunnel interface is a logical interface, so no commit is needed for the encapsulation itself to work. What does need to be right is the zone: a tunnel interface with no zone, or in the wrong zone, generates a commit warning and traffic will not match your security policy. Give the tunnel its own zone rather than adding it to trust or untrust - it makes the rule base readable and lets you write one policy pair that governs all site-to-site traffic.

Step 2: Define the IKE Gateway

set network ike gateway NewYork-VPN local-address interface ethernet1/1
set network ike gateway NewYork-VPN local-address ip 100.100.100.1
set network ike gateway NewYork-VPN peer-address ip 100.100.100.2
set network ike gateway NewYork-VPN protocol version ikev2
set network ike gateway NewYork-VPN protocol ikev2 pre-shared-key key <secret>
set network ike gateway NewYork-VPN protocol ikev2 dpd enable yes

Point the local-address at the interface that carries the Internet/VPN traffic, and set the peer to the remote firewall's public IP.

The local-address interface and local-address ip lines work together: the interface selects the outgoing path while the IP pins the identity the peer will see. On a firewall whose WAN address changes, omit the explicit IP and let the interface address be used - but on a stable circuit, pinning it prevents surprises when an interface has multiple addresses or when a return path exists on a second ISP.

Also attach the IKE profile here if you created one explicitly (some PAN-OS versions accept protocol ikev2 ike-crypto-profile IKE_Profile), and decide whether dead peer detection should be aggressive. DPD with a short interval fails over quickly when the peer dies, but a DPD configured tighter than the WAN's jitter tolerance tears down healthy tunnels during congestion.

Step 3: Create the IPsec Tunnel (Auto-Key)

set network tunnel ipsec NewYork-VPN tunnel-interface tunnel.10
set network tunnel ipsec NewYork-VPN auto-key ike-gateway NewYork-VPN
set network tunnel ipsec NewYork-VPN auto-key ipsec-crypto-profile IPsec_Profile
set network tunnel ipsec NewYork-VPN anti-replay yes
set network tunnel ipsec NewYork-VPN tunnel-monitor enable yes

Make sure the IKE crypto profile and IPsec crypto profile referenced here exist; if not, create them with set network ike crypto-profiles ike-crypto-profile ... and set network ike crypto-profiles ipsec-crypto-profile ... first.

Two options deserve a word. Anti-replay protects against replayed ESP packets and should stay enabled in a normal design, but it can drop legitimate packets on a path with heavy reordering or on a heavily load-balanced link. Tunnel monitoring (which requires the tunnel interface IP from step 1) lets the firewall withdraw the route when the tunnel drops, so traffic fails over instead of black-holing into a dead tunnel.

Step 4: Attach the Tunnel to the Virtual Router and Add the Route

set network virtual-router "Virtual Router 1" interface [ ethernet1/1 ethernet1/2 tunnel.10 ]
set network virtual-router "Virtual Router 1" routing-table ip static-route Route_to_NewYork destination 192.168.3.0/24
set network virtual-router "Virtual Router 1" routing-table ip static-route Route_to_NewYork interface tunnel.10
set network virtual-router "Virtual Router 1" routing-table ip static-route Route_to_NewYork metric 10

The tunnel interface must appear in the virtual router's interface list, otherwise the route has no valid egress and the commit fails with a "next hop unreachable" style error. Add one static route per remote subnet - a route for 0.0.0.0/0 pointed at a tunnel is almost always a mistake and will black-hole internet traffic the moment the tunnel comes up.

If both sites run the same dynamic routing protocol, replace the static route with a BGP or OSPF session over the tunnel interface and let the remote subnets be learned. Static routes are simpler to reason about for a two-site design; dynamic routing pays off from the third site onwards.

Step 5: Security Policy and Commit

Route-based VPNs still need a security policy allowing traffic between the source zone and the vpn zone, then a commit: commit. Verify with:

show vpn ipsec-sa tunnel NewYork-VPN
show vpn ike-sa gateway NewYork-VPN
ping 192.168.3.1 source 192.168.2.1

Write the policy in both directions, or use one rule with the zones in both fields if your policy model allows it. The application must be explicit - any will work for a test but leaves you blind to what actually traverses the tunnel. If you tightened security with profiles on the internet-facing rule, do not blindly reuse those profiles on the VPN rule; URL filtering and antivirus on intra-company traffic is a policy decision, not a technical requirement.

Step 6: NAT for Internet-Based VPN Peers

Traffic leaving the tunnel implementation is not NATed by the outbound masquerade rule if your no-NAT rule is correct, but the ordering matters. A site-to-site VPN on this firewall commonly needs:

set rulebase nat rules NoNat_VPN from trust to vpn source any destination 192.168.3.0/24
set rulebase nat rules NoNat_VPN source-translation disabled
set rulebase nat rules NoNat_VPN destination-translation disabled

Without an explicit no-NAT rule above the internet masquerade rule, the firewall happily translates VPN-bound traffic to its WAN address, the peer sees packets from an unexpected source, and the tunnel appears up while nothing passes. This is the second most common "the VPN is established but broken" cause after a missing route.

If a peer is behind NAT, the local-address you configure must be the pre-NAT private address (unless the firewall is itself the NAT device), and the peer should identify by IP rather than by FQDN to avoid responder-side identity mismatches.

Step 7: Verify, and Know What Good Looks Like

show vpn ike-sa
show vpn ipsec-sa
show vpn flow name NewYork-VPN
test vpn ike-sa gateway NewYork-VPN
test vpn ipsec-sa tunnel NewYork-VPN
show routing route destination 192.168.3.0/24

An established phase 1 shows a valid IKE SA with the negotiated encryption, hash and DH group, plus the remaining lifetime. Phase 2 shows the matching ESP SA with its own lifetime, a nonzero packet counter once traffic flows, and the correct SPI pair. The flow table shows which security policy matched - if it shows no flow, the traffic never entered the tunnel and the fault is a policy, NAT or route problem, not a crypto problem.

Watch the byte counters over a minute of real traffic. A tunnel that establishes and then shows zero counters in the outbound direction is usually a routing issue; counters growing in one direction only is almost always a proxy-ID or route-target mismatch on the remote side.

Troubleshooting: Phase 1 versus Phase 2 Failures

The quickest way to cut the search space is to determine which phase fails:

• Phase 1 never establishes. Check reachability of UDP 500/4500 first with ping and a packet capture, then compare the proposals on both ends. Peer address wrong, pre-shared key mismatch, or a proposal (encryption, hash, DH group) that the two sides do not share are the usual suspects.
• Phase 1 establishes, phase 2 fails. Almost always proxy-ID or selector mismatch on a policy-based design, or an IPsec crypto profile mismatch on a route-based one. Compare the ESP encryption, authentication and PFS settings on both sides.
• Both phases establish, no traffic. This is the routing and NAT class: missing static route, tunnel interface not in the virtual router, a NAT rule translating VPN traffic, or a security policy that does not cover the source zone.
• Traffic flows, then stops. Look for a rekey collision or a lifetime mismatch between the two ends. Different lifetimes on peers cause periodic renegotiation storms that look like random packet loss.

Enable IKE logging while you test - debug ike global on debug and the corresponding less mp-log ikemgr.log - but turn it off afterwards, because verbose IKE debugging on a busy firewall is expensive. The log names the exact stage of the negotiation that failed, which is worth more than any amount of guessing at configuration.

Route-Based versus Policy-Based on PAN-OS

A policy-based VPN uses an IPsec tunnel defined directly inside a security rule and needs no tunnel interface and no route. It is faster to stand up for a single subnet pair, and it works on older PAN-OS releases. The drawbacks show up as soon as the design grows: no dynamic routing over the tunnel, no tunnel monitoring, no clean way to steer traffic from a routing protocol, and duplicated configuration for every additional subnet.

The route-based design in this article costs four extra commands and buys you routing-protocol support, monitoring-driven failover, cleaner policy, and a tunnel that behaves like any other interface. For anything beyond a two-site, two-subnet deployment, build it route-based from the start.

Commit, Validate and Config Management Tips

Two habits save time on Palo Alto firewalls. First, use validate full before committing on a change window, so configuration errors surface without a commit cycle. Second, capture a config backup with show config running or the export option before making VPN changes, since a botched tunnel configuration can drop management reachability if the tunnel and management share a path.

Cloning is where the CLI really shines: to build a second tunnel to a different branch, duplicate the gateway and tunnel blocks with new names and change the peer address, local subnet and remote subnet. Change the crypto profile names only if the branch requires different crypto. Run rename carefully - a rename that misses one reference produces a commit error pointing at a line you did not edit.

FAQ

Do I need an IP address on the tunnel interface? No for static routing, but yes if you want tunnel monitoring or dynamic routing over the tunnel. Assign one from an unused range that is not advertised anywhere.

Can I use the same IKE gateway for several tunnels? Yes, one gateway with several auto-key tunnels is normal when a peer has multiple remote subnets. Each tunnel needs its own proxy-ID if the design is policy-based.

Why does the tunnel drop every hour? Lifetime mismatch. Make the phase 1 lifetime on one side shorter than on the other, and keep phase 2 lifetimes shorter, so one end always rekeys before the other's SA expires.

Is a route-based VPN enough, or do I still need a security policy? You still need a policy. The tunnel interface provides the path; the security policy provides the permission. Both are required.

Key Takeaways

A PAN-OS site-to-site IPsec VPN is five objects and a route: tunnel interface and zone, IKE gateway, IPsec tunnel with auto-key, virtual router membership, static route, plus the security policy. Verify in order - IKE SA, IPsec SA, flow table, byte counters - and when something breaks, decide first whether phase 1, phase 2, or the routing/NAT layer is failing. That single question turns a vague "the VPN is down" into a specific command to run.

Related Guides on This Site

Compare implementations across vendors: Juniper SRX route-based IPsec, FortiGate IPsec phase 1/2 and MikroTik RouterOS 7 IPsec. For the same design on Cisco hardware see Cisco ASA site-to-site IPsec VPN CLI configuration.

原文链接：https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHsCAK