Palo Alto Site-to-Site IPsec VPN Configuration with a Branch Office Example

Connecting geographically separated office locations securely across the public internet is a core requirement for enterprise networks. Setting up a Palo Alto site to site IPsec VPN allows organizations to build encrypted, route-based tunnels between Next-Generation Firewalls (NGFW). Route-based VPNs decouple the network topology from the encryption mechanism, simplifying routing policies and security rule management.

This technical guide demonstrates how to configure, verify, and troubleshoot a route-based IPsec VPN connecting a Head Office firewall to a remote Branch Office firewall. The example uses explicit lab IP addressing and step-by-step instructions to ensure a production-ready deployment.

Real-Life Scenario

A growing financial services firm needs to connect its Head Office network to a newly opened Branch Office. Remote users and local servers at both sites require secure, bi-directional communication across the untrusted public internet.

Key operational requirements include:

• Encrypted connectivity between the HQ internal subnet (10.10.10.0/24) and the Branch internal subnet (10.20.20.0/24).
• Route-based IPsec architecture using dedicated tunnel interfaces to support future dynamic routing policies.
• Strong cryptographic standards compliant with current security benchmarks (AES-256-GCM, SHA-256, Diffie-Hellman Group 19).
• Isolating VPN traffic into a dedicated logical security zone for fine-grained access control.

Lab Topology

The network topology consists of two Palo Alto Networks firewalls connected via public IP addresses over an internet gateway path. Dedicated virtual tunnel interfaces handles the IPsec encapsulations.

[ Head Office LAN ]                                                      [ Branch Office LAN ]
  10.10.10.0/24                                                            10.20.20.0/24
       |                                                                        |
 (eth1/2 - Trust Zone)                                                    (eth1/2 - Trust Zone)
[ PA-HQ-FW ]                                                             [ PA-BO-FW ]
 (eth1/1 - Untrust Zone: 198.51.100.1)                                   (eth1/1 - Untrust Zone: 203.0.113.1)
  [ tunnel.1 - VPN Zone: 10.255.255.1/30 ]                                 [ tunnel.1 - VPN Zone: 10.255.255.2/30 ]
       |                                                                        |
       +====================== IPsec Tunnel (Internet) =========================+

Example Addressing and Objects

The table below outlines the network addresses, zones, and parameters used throughout this configuration. Example public IP addresses use official documentation ranges reserved by RFC 5737 (198.51.100.0/24 and 203.0.113.0/24). Adapt these values to match your WAN allocation.

Prerequisites

Before initiating the VPN configuration, verify that the following environment criteria are met:

• Static public IPv4 addresses assigned to the external interface of each firewall.
• Upstream ISPs allow UDP port 500 (IKE), UDP port 4500 (IKE NAT-Traversal), and IP Protocol 50 (ESP).
• Administrative access to both firewalls with rights to commit configuration changes.
• A secure, pre-shared key (PSK) generated for tunnel authentication.

Palo Alto Site to Site IPsec VPN Configuration Steps

The configuration steps below detail the setup process on the Head Office firewall (PA-HQ-FW). Apply the symmetric configuration to the Branch Office firewall (PA-BO-FW) by swapping local and remote IP addresses.

Step 1: Create the Tunnel Interface

Route-based VPNs use logical tunnel interfaces to pass traffic into the IPsec processing engine.

1. Navigate to Network > Interfaces > Tunnel.
2. Click Add at the bottom of the screen.
3. In the Config tab, set the interface Name to tunnel.1.
4. Assign the interface to a Virtual Router (e.g., default).
5. Assign the Security Zone. Create a dedicated zone named VPN-Zone (Layer 3 type) for simplified security management.
6. In the IPv4 tab, click Add and assign 10.255.255.1/30.
7. Click OK.

Step 2: Define the IKE Crypto Profile (Phase 1 Parameters)

The IKE Crypto Profile defines the encryption, authentication, and Diffie-Hellman algorithms used during Phase 1 tunnel negotiation.

1. Navigate to Network > Network Profiles > IKE Crypto.
2. Click Add and name the profile IKE-Crypto-Corporate.
3. Set DH Group to group19.
4. Set Encryption to aes-256-gcm.
5. Set Authentication to sha256.
6. Set Lifetime to 8 Hours (default).
7. Click OK.

Step 3: Define the IKE Gateway

The IKE Gateway configures the identity and authentication parameters of the remote peer.

1. Navigate to Network > Network Profiles > IKE Gateways.
2. Click Add and set the name to IKE-GW-Branch.
3. In the General tab:
   • Set Version to IKEv2 only mode (or IKEv2 preferred mode).
   • Set Address Type to IPv4.
   • Set Interface to ethernet1/1 (the WAN interface).
   • Set Local IP Address to 198.51.100.1/24.
   • Set Peer Address to 203.0.113.1.
   • Select Pre-shared Key under Authentication, then enter and confirm your secret key.
4. In the Advanced Options tab:
   • Set IKE Crypto Profile to IKE-Crypto-Corporate.
   • Enable Enable NAT Traversal if either endpoint resides behind dynamic NAT.
5. Click OK.

Step 4: Define the IPsec Crypto Profile (Phase 2 Parameters)

The IPsec Crypto Profile specifies encryption and authentication protocols for protecting user payload data.

1. Navigate to Network > Network Profiles > IPsec Crypto.
2. Click Add and name the profile IPsec-Crypto-Corporate.
3. Set IPsec Protocol to ESP.
4. Set Encryption to aes-256-gcm.
5. Set Authentication to sha256.
6. Set DH Group (Perfect Forward Secrecy) to group19.
7. Set Lifetime to 1 Hours.
8. Click OK.

Step 5: Create the IPsec Tunnel

The IPsec Tunnel object binds the tunnel interface, the IKE Gateway, and the Phase 2 crypto parameters together.

1. Navigate to Network > IPSec Tunnels.
2. Click Add and name the tunnel IPsec-Tunnel-Branch.
3. Select Tunnel Interface tunnel.1.
4. Select IKE Gateway IKE-GW-Branch.
5. Select IPsec Crypto Profile IPsec-Crypto-Corporate.
6. Proxy IDs (Optional): Leave Proxy IDs blank when connecting two Palo Alto firewalls using route-based configurations. If connecting to a policy-based firewall (such as older legacy systems), explicitly define local and remote subnets in the Proxy ID tab.
7. Click OK.

Step 6: Configure Static Routes

Traffic must be routed to the tunnel interface for the firewall to perform IPsec encapsulation.

1. Navigate to Network > Virtual Routers and select your virtual router (e.g., default).
2. Click Static Routes, then click Add.
3. Set Name to Route-To-Branch.
4. Set Destination to 10.20.20.0/24 (the Branch internal subnet).
5. Set Interface to tunnel.1.
6. Set Next Hop to None (or specify 10.255.255.2).
7. Click OK.

Step 7: Define Security Policies

Because traffic passes between distinct security zones (Trust and VPN-Zone), security policy rules must permit flow in both directions.

1. Navigate to Policies > Security.
2. Add a rule named Allow-HQ-To-Branch:
   • Source Zone: Trust
   • Source Address: 10.10.10.0/24
   • Destination Zone: VPN-Zone
   • Destination Address: 10.20.20.0/24
   • Application/Service: any (or specify required applications)
   • Action: Allow
3. Add a reciprocal rule named Allow-Branch-To-HQ:
   • Source Zone: VPN-Zone
   • Source Address: 10.20.20.0/24
   • Destination Zone: Trust
   • Destination Address: 10.10.10.0/24
   • Action: Allow
4. Click Commit to save and activate the configuration.

CLI Commands

The PAN-OS command line interface provides efficient verification and management of IPsec configurations. The following validated CLI commands allow administrators to view tunnel state and clear active Security Associations (SAs) during testing.

To view active Phase 1 IKE gateways and status:

show ike gateway

To view Phase 1 IKE Security Associations (IKE-SAs):

show vpn ike-sa

To view Phase 2 IPsec Security Associations (IPsec-SAs):

show vpn ipsec-sa

To view operational details for a specific IPsec tunnel:

show vpn flow name IPsec-Tunnel-Branch

To manually initiate IKE Phase 1 negotiation for testing:

test vpn ike-sa gateway IKE-GW-Branch

To manually initiate IPsec Phase 2 negotiation:

test vpn ipsec-sa tunnel IPsec-Tunnel-Branch

To clear a running IKE gateway session:

clear vpn ike-sa gateway IKE-GW-Branch

To clear an active IPsec SA session:

clear vpn ipsec-sa tunnel IPsec-Tunnel-Branch

How the Traffic Flows

Understanding packet flow through the Palo Alto Networks architecture helps when auditing traffic and writing firewall rules. The step-by-step path for an outbound packet originating from the HQ local area network is detailed below:

1. Ingress Lookup: A host at 10.10.10.50 sends a packet destination-bound to 10.20.20.100. The packet arrives at interface ethernet1/2 (Zone: Trust).
2. Routing Lookup (Pre-NAT): The virtual router evaluates its Forwarding Information Base (FIB). The best matching static route for 10.20.20.0/24 dictates the egress interface as tunnel.1.
3. Security Policy Evaluation: The firewall checks security policies using the original (pre-NAT) addresses and zones. The flow context matches Source Zone: Trust to Destination Zone: VPN-Zone. The packet is permitted.
4. IPsec Encapsulation: The packet enters interface tunnel.1. The IPsec engine encapsulates the original IP packet inside an Encapsulating Security Payload (ESP) header using symmetric keys negotiated during Phase 2.
5. Outer Packet Forwarding: The firewall constructs a new outer IP header. The outer source address is 198.51.100.1, and the outer destination address is 203.0.113.1.
6. Egress Routing Lookup: The virtual router evaluates the path for the outer destination address (203.0.113.1). The route points out interface ethernet1/1 (Zone: Untrust).
7. Egress Transmission: The encapsulated ESP packet is sent over the internet to the Branch Office firewall.

Verification

Confirm proper tunnel initialization using both the Web Interface and the CLI.

1. Web Interface Status Checks

Navigate to Network > IPSec Tunnels. Look at the status indicators next to the tunnel name:

• Status Icon (IKE Phase 1): Green indicates that Phase 1 IKE negotiation is active and authenticated.
• Tunnel Status Icon (IPsec Phase 2): Green indicates that Phase 2 IPsec SAs are active and established.

2. CLI Verification Commands

Run the operational commands to confirm active key associations:

admin@PA-HQ-FW> show vpn ike-sa

IKEv2 SAs
Gateway             ID           Peer IP          Role  State    Algorithm
-------             --           -------          ----  -----    ---------
IKE-GW-Branch       101          203.0.113.1      Init  ESTAB    AES256-GCM/SHA256/DH19

Next, verify Phase 2 IPsec Security Associations:

admin@PA-HQ-FW> show vpn ipsec-sa

ID     Name                Gateway        Interface   State   Encapsulation
--     ----                -------        ---------   -----   -------------
201    IPsec-Tunnel-Branch IKE-GW-Branch  tunnel.1    active  ESP

3. Data Plane Testing

Initiate traffic from a device on the HQ local subnet to an internal IP address on the Branch local subnet. Alternatively, run an extended ping test directly from the firewall CLI, ensuring you specify the source IP address matching the local Trust interface:

ping source 10.10.10.1 host 10.20.20.1

Troubleshooting

When an IPsec tunnel fails to connect or drops packets, isolate the failure to Phase 1, Phase 2, or general forwarding issues using this structured troubleshooting sequence.

Phase 1 Failure (IKE Gateway Issues)

• Symptom: IKE status light remains red/gray; show vpn ike-sa returns no active SAs.
• Common Causes: Pre-shared key mismatch, incorrect Peer IP, mismatched IKE versions, or upstream intermediate devices dropping UDP 500 / UDP 4500 traffic.
• Action: Check system logs for detailed error messaging:

  show log system feature eq ike direction backward

  Look for messages indicating Authentication failed (PSK mismatch) or No response from peer (routing/firewall block).

Phase 2 Failure (IPsec Tunnel Issues)

• Symptom: Phase 1 status is green, but Phase 2 status remains red/gray.
• Common Causes: IPsec profile parameters mismatch (mismatched DH group or hash settings), mismatched Proxy ID configurations when interconnecting with policy-based systems, or proposal rejections.
• Action: Run the operational CLI test to force negotiation and observe output errors:

  test vpn ipsec-sa tunnel IPsec-Tunnel-Branch

Traffic Passing Failure (Data Plane Issues)

• Symptom: Both Phase 1 and Phase 2 status indicators show green, but traffic fails to traverse the tunnel.
• Common Causes:
  • Missing static route pointing destination subnets to the tunnel.x interface.
  • Security policies dropping traffic between Trust and VPN-Zone.
  • Unintended NAT policies translating local source addresses into public egress interface addresses prior to tunnel entry.
  • Missing reverse routes on the destination network firewall.
• Action: Inspect active sessions in the traffic log under Monitor > Logs > Traffic. Search for destination subnets to confirm whether traffic is being allowed or dropped by security policies.

Common Mistakes

1. Incorrect Security Policy Zones: Placing the tunnel interface in the Untrust zone instead of a dedicated VPN-Zone. Assigning tunnel interfaces to a dedicated zone makes writing clean security policies easier and prevents unintended access rules.
2. Overlapping NAT Rules: Failing to exclude VPN subnets from outbound Internet Source NAT policies. Check that generic outbound NAT rules do not match traffic destined for remote internal VPN networks.
3. Ignoring Path MTU and TCP MSS: Large packets transmitted across IPsec tunnels experience extra overhead from ESP encapsulation. If the resulting packet exceeds the WAN MTU, packets fragment or drop. Set TCP MSS adjustment on the logical tunnel interface to prevent PMTU black-hole issues:
   1. Navigate to Network > Interfaces > Tunnel and select tunnel.1.
   2. In the Advanced tab, enable Adjust TCP MSS.
   3. Set IPv4 MSS value to 1350 (or 1400).
4. Proxy ID Mismatches with Legacy Peers: Route-based VPNs do not strictly require Proxy IDs when both firewalls use route-based designs. However, connecting to a policy-based firewall requires configuring matching Proxy IDs explicitly under the IPsec Tunnel settings.

Production Considerations

When deploying IPsec site-to-site tunnels in business-critical enterprise environments, consider applying these operational optimizations:

Tunnel Monitoring and Failover

Enable Tunnel Monitoring on critical IPSec connections. Tunnel Monitoring sends periodic ICMP pings across the tunnel to an IP address at the far end (e.g., the remote tunnel IP address). If the remote host fails to reply, the firewall marks the tunnel down. This action can automatically clear static routes or initiate a path failover to a backup link.

To enable this, navigate to Network > IPSec Tunnels > [Tunnel Name] > Auto Key > Tunnel Monitor, specify the destination monitor IP (e.g., 10.255.255.2), and assign a failover profile.

Cryptography Standard Guidelines

Avoid legacy algorithms that are cryptographically vulnerable or computationally inefficient on modern platforms. Avoid using MD5, SHA-1, DES, 3DES, or Diffie-Hellman Groups 1, 2, and 5. Standardize on modern proposals such as AES-256-GCM or AES-128-GCM combined with DH Group 19 (ECDH 256-bit) or Group 20 for efficient hardware acceleration and security.

Dynamic Routing over IPsec

In environments with multiple branch offices or dynamic path requirements, consider running BGP across the tunnel interfaces instead of relying entirely on static routes. Using dynamic routing simplifies policy updates, offers fast path convergence, and automates failover when redundant IPsec tunnels are deployed.

Related Palo Alto Guides

• Palo Alto IPsec VPN troubleshooting
• Palo Alto GlobalProtect
• Palo Alto Syslog/SIEM

Summary

Configuring a Palo Alto site to site IPsec VPN requires setting up a logical tunnel interface, matching Phase 1 and Phase 2 crypto profiles, binding these components within an IPsec tunnel configuration, and defining clear routing and security policies. Isolating VPN traffic into a dedicated security zone gives you precise visibility and granular access control over corporate networks.