Set Up a Site-to-Site IPsec VPN on a Palo Alto Firewall

Before you run this

This guide builds a route-based site-to-site IPsec VPN on a Palo Alto firewall: an encrypted tunnel between your firewall and a remote peer so two private subnets can talk over the public internet. You configure it entirely as candidate configuration in the web GUI and make it live with a Commit.

Privileges: you need a firewall admin account with a superuser role (or a device-admin role permitted to edit Network and Policies). No shell or sudo — this is the appliance's own management plane.

This changes live forwarding. Adding a tunnel interface, a static route, and a security rule will move production traffic. A wrong route or an over-broad security rule can black-hole traffic or open a path you did not intend. Treat it as a production change:

Keep a separate out-of-band path open — a console cable, or an SSH/HTTPS session to the management interface on a different link than the one you are reconfiguring. A bad route or zone change can cut you off from the box and drop production traffic at the same time.
Back up first. In the GUI go to Device > Setup > Operations and use Export named configuration snapshot (save the XML off-box), and Save named configuration snapshot so you have a named on-box copy to load later.
Do it in a maintenance window, and read every value before you commit.
Rollback path: PAN-OS is a candidate/commit model, so nothing is live until you Commit. Before committing you can use Config > Revert Changes (top menu) to throw away the candidate and return to the running config. After a bad commit, go to Device > Setup > Operations > Load named configuration snapshot, pick the snapshot you saved, then Commit to restore it.

Test against a lab pair or a non-production peer first if you can. Don't paste crypto values you haven't confirmed the far end agrees to — a mismatch is the single most common reason a tunnel won't come up.

Assumptions

PAN-OS 11.1 on a single firewall (not managed by Panorama).
Route-based VPN with a tunnel interface (the standard Palo Alto approach). Policy-based peers are supported via Proxy IDs, mentioned at the end.
The remote peer has a static public IP. Pre-shared key authentication. IKEv2.
Your outside interface is ethernet1/1 in zone untrust; your inside subnet is 10.10.0.0/24; the remote subnet is 10.20.0.0/24; the remote peer public IP is 203.0.113.10. Replace all of these with your real values.

Menu paths and field names move between PAN-OS versions. If a screen doesn't match, check the PAN-OS Administrator's Guide section "Set Up Site-to-Site VPN" for your exact version rather than guessing.

1. Create the tunnel interface

Network > Interfaces > Tunnel > Add.

Interface Name: tunnel.1
Virtual Router: your existing router (e.g. default)
Security Zone: create or pick a zone for VPN traffic, e.g. vpn. (Create it under Network > Zones as a Layer3 zone if it doesn't exist.)
Leave the IP unset for a numbered-less route-based tunnel, or assign a /32 from a transit range if your design uses one. Static routing to the remote subnet works without an IP on the tunnel interface.

Putting the tunnel in its own zone keeps its traffic under explicit security policy rather than folding it into trust.

2. Create the IKE Crypto profile (Phase 1)

Network > Network Profiles > IKE Crypto > Add.

Pick values you have confirmed the far end will match. A standard, widely interoperable set:

DH Group: group14
Authentication: sha256
Encryption: aes-256-cbc
Key Lifetime: 8 hours (the default is fine)

If both ends support it, aes-256-gcm is a good modern choice — GCM handles authentication internally, so the authentication field behaves differently. Only use it if you're certain the peer matches.

3. Create the IPSec Crypto profile (Phase 2)

Network > Network Profiles > IPSec Crypto > Add.

IPSec Protocol: ESP
Encryption: aes-256-cbc
Authentication: sha256
DH Group: group14 (this enables PFS; set to no-pfs only if the peer requires it)
Lifetime: 1 hour (default)

4. Create the IKE Gateway

Network > Network Profiles > IKE Gateways > Add.

Name: ike-gw-siteB
Version: IKEv2 only mode
Interface: ethernet1/1 (your outside interface)
Local IP Address: your outside interface's IP
Peer IP Address Type: IP, Peer Address: 203.0.113.10
Authentication: Pre-Shared Key — enter the PSK, agreed out-of-band with the far end. Use a long random string.
On the Advanced Options tab, select the IKE Crypto Profile from step 2.

If your firewall sits behind NAT, or the peer's public IP is dynamic, the local/peer identification fields change — see the IKE Gateway section of the Administrator's Guide for those cases.

5. Create the IPSec Tunnel

Network > IPSec Tunnels > Add.

Name: ipsec-siteB
Tunnel Interface: tunnel.1
Type: Auto Key
IKE Gateway: ike-gw-siteB (from step 4)
IPSec Crypto Profile: from step 3

If the remote device is policy-based, open the Proxy IDs tab, Add one, and set Local 10.10.0.0/24 and Remote 10.20.0.0/24. For a route-based peer you can usually leave Proxy IDs empty (which negotiates 0.0.0.0/0). Match whatever the far end expects — mismatched proxy IDs cause Phase 2 to fail.

6. Add the route to the remote subnet

Network > Virtual Routers > [your router] > Static Routes > Add.

Name: to-siteB
Destination: 10.20.0.0/24
Interface: tunnel.1
Next Hop: None (point out the tunnel interface)

7. Allow the traffic in Security policy

Policies > Security > Add. Traffic across the tunnel is subject to policy just like anything else.

Source Zone: trust, Source Address: 10.10.0.0/24
Destination Zone: vpn, Destination Address: 10.20.0.0/24
Application: start with any to prove the tunnel, then tighten to real apps
Action: Allow

Add a matching return rule for the reverse direction (source vpn / 10.20.0.0/24, destination trust / 10.10.0.0/24) if your reply traffic needs it. Keep both scoped to these subnets, not any.

8. Commit

Use Commit > Commit (top right). Consider Preview Changes first to confirm you're pushing only what you expect. Nothing above is live until this succeeds.

Verify it worked

Traffic must be interesting (something on 10.10.0.0/24 sending to 10.20.0.0/24) before the tunnel builds. Generate a ping across it, then check.

In the GUI: Network > IPSec Tunnels — the status light should be green; hover for tunnel and IKE state.

From the CLI (SSH to the management interface):

# Phase 1 — is the IKE security association up?
show vpn ike-sa

# Phase 2 — is the IPSec SA established?
show vpn ipsec-sa

# Actively test negotiation for a named gateway/tunnel
test vpn ike-sa gateway ike-gw-siteB
test vpn ipsec-sa tunnel ipsec-siteB

If Phase 1 won't come up, suspect the PSK, peer IP, or IKE Crypto mismatch. If Phase 1 is up but Phase 2 isn't, suspect the IPSec Crypto profile or Proxy IDs. Confirm end-to-end reachability with a data-plane ping sourced from the inside interface:

ping source 10.10.0.1 host 10.20.0.1

Undo / rollback

Because this is a candidate/commit model, the cleanest reversal depends on how far you got:

Before you committed: Config > Revert Changes discards everything back to the running config.
To disable without deleting: on Network > IPSec Tunnels, edit the tunnel and clear its enable state (or remove the static route in step 6), then Commit — traffic stops using the tunnel.
To fully restore: Device > Setup > Operations > Load named configuration snapshot, choose the pre-change snapshot you saved in "Before you run this", then Commit.

Remove objects in reverse dependency order if you delete by hand — security rule and route first, then the tunnel, gateway, crypto profiles, and finally the tunnel interface — or PAN-OS will flag the ones still in use.