Index › VPN & Connectivity
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

VPN & Connectivity

← Back to full guide index

~3 min read
Prerequisites: Access & Identity — GlobalProtect (remote-access VPN) is covered there; this module covers site-to-site.

Site-to-Site VPNs (IKE/IPSec) 31

PAN-OS course · Site-to-Site VPNs

Learning objectives

  • Explain the two-phase IKE/IPSec model (Phase 1 vs. Phase 2)
  • Map each phase to its firewall configuration object
  • Distinguish site-to-site VPN from GlobalProtect remote access

Where GlobalProtect secures individual remote users, site-to-site VPN connects two networks — branch to HQ, or on-prem to cloud — over an encrypted tunnel built with the industry-standard IKE/IPSec protocol pair.

Why

Sites need to exchange traffic over the public internet without exposing it in the clear, and without the cost/lead-time of dedicated private circuits for every location. IPSec is the standard, vendor-interoperable way to do that.

How

Two phases, two firewall objects: IKE Gateway (Phase 1) negotiates and authenticates the peer relationship — peer IP/identity, pre-shared-key or certificate authentication, and the IKE crypto profile. IPSec Tunnel (Phase 2, under Network > IPSec Tunnels) then builds the actual data-plane tunnel on top of that established Phase-1 relationship — tunnel interface binding, IPSec crypto profile, and (for policy-based peers) Proxy IDs that define which traffic selectors the tunnel carries. Once up, the tunnel appears to routing as a regular tunnel interface, so normal security policy and zone assignment apply to traffic crossing it just like any other interface. Tunnel status, restart, and refresh are managed the same place the tunnel is configured.
IKE Phase 1 gateway negotiation followed by IPSec Phase 2 tunnel establishment between two sites.
IKE Phase 1 gateway negotiation followed by IPSec Phase 2 tunnel establishment between two sites.

Pros

  • Standard IKE/IPSec interoperates with non-Palo-Alto VPN peers (routers, other vendors' firewalls, cloud VPN gateways)
  • Tunnel traffic lands on a normal tunnel interface — existing zone/policy model applies unchanged
  • Cheaper and faster to stand up than dedicated private circuits between sites

Cons

  • Phase 1/Phase 2 mismatches (proposals, lifetimes, Proxy IDs) are the single most common cause of tunnels that won't come up
  • Manually configuring many site-to-site tunnels doesn't scale — this is exactly the gap GlobalProtect LSVPN was built to close for branch-heavy deployments
  • No inherent QoS/path-selection intelligence — a single IPSec tunnel is one static path, unlike SD-WAN's dynamic path selection

Exam trap

A tunnel that stays down almost always traces back to a Phase 1 or Phase 2 mismatch, not a routing problem: mismatched IKE/IPSec crypto proposals, mismatched lifetimes, or — for policy-based peers — Proxy IDs that don't mirror each other exactly on both ends. Check show vpn ike-sa / show vpn ipsec-sa before assuming it's a zone or security-policy issue.
Self-check

Q1. A site-to-site tunnel to a third-party router negotiates Phase 1 successfully but Phase 2 never comes up. What's the most likely cause, and which two firewall objects would you compare against the peer's config?

A1. Most likely a Phase 2 (IPSec) mismatch — proposal/lifetime or Proxy ID disagreement. Compare the local IPSec Tunnel object's crypto profile and Proxy IDs against the peer's configuration; Phase 1 succeeding rules out the IKE Gateway object as the cause.

Q2. Why can a single site-to-site IPSec tunnel be a worse fit than GlobalProtect LSVPN for a company opening 200 new branch offices?

A2. Site-to-site IPSec tunnels are configured and maintained one peer relationship at a time, so 200 branches means 200 manually managed tunnels. LSVPN exists specifically to let branch/satellite devices auto-onboard against a portal instead of requiring hand-built IKE/IPSec objects per site.

Source: ngfw/help/11-1/network/network-ipsec-tunnels

Quantum-Ready VPN 32

PAN-OS course · Quantum Ready Virtual Private NetworksPAN-OS 12.1+

Learning objectives

  • Explain the "harvest now, decrypt later" threat that motivates quantum-safe VPN
  • Describe how Quantum Key Distribution (QKD) plugs into an existing IPSec tunnel

Traffic encrypted today with classical algorithms could be harvested and stored by an adversary now, then decrypted later once sufficiently powerful quantum computers exist — Quantum Key Distribution defends long-lived VPN traffic against that future risk today, not retroactively.

Why

"Harvest now, decrypt later" means data that needs to stay confidential for years (government, defense, long-term IP) is already at risk from classical-crypto interception, even though the decryption capability doesn't exist yet. Waiting until quantum computers are practical is too late for data captured today.

How

Quantum Key Distribution (QKD) support lets the firewall source its IPSec encryption keys from a dedicated quantum-safe hardware appliance — a Key Management Entity (KME) — instead of (or alongside) classical Diffie-Hellman key exchange. A QKD profile (Device > Setup > Quantum) defines the connection to a specific KME: its URL, the firewall's local Security Application Entity (SAE) ID, and the certificate trust between firewall and KME (local certificate, KME CA certificate, KME server certificate). Once configured, the resulting high-quality quantum keys feed into the site-to-site IPSec tunnel's key material, hardening it against future quantum cryptanalysis without changing the surrounding IKE/IPSec tunnel model.
Without QKD, an adversary can harvest classically-encrypted IPSec traffic today and decrypt it later once quantum computers break Diffie-Hellman; with QKD, a Key Management Entity feeds quantum-safe keys into the same IPSec tunnel model.
Without QKD: traffic harvested today is decryptable once quantum computers break classical key exchange. With QKD: a KME feeds quantum-safe keys into the same IPSec tunnel.

Pros

  • Defends against "harvest now, decrypt later" for traffic being captured today
  • Layers onto the existing IPSec tunnel model rather than requiring a new VPN architecture
  • Certificate-based trust to the KME keeps key delivery itself authenticated

Cons

  • Requires physical QKD hardware (a KME appliance) — this isn't a pure software/licensing feature
  • PAN-OS 12.1+ only, so it isn't available on older deployed code without an upgrade
  • Realistically relevant only for organizations with genuinely long-horizon confidentiality needs, not general-purpose VPN traffic

Exam trap

QKD in PAN-OS is a key-sourcing mechanism layered onto the existing IPSec tunnel model — it does not replace IKE/IPSec, add a new tunnel type, or work without physical KME hardware. Don't confuse it with a purely software/licensing feature.
Self-check

Q1. What specific future risk does "harvest now, decrypt later" describe, and why does it matter for data being encrypted today?

A1. An adversary captures and stores classically-encrypted traffic today, intending to decrypt it once a sufficiently powerful quantum computer exists. It matters now — not just in the future — because any data with a long confidentiality lifetime (years) is already exposed the moment it's captured, regardless of when it's eventually decrypted.

Q2. Which two categories of things does a QKD profile need to define to connect a firewall to a KME?

A2. (1) Connection details — the KME's URL and the firewall's local SAE ID; (2) certificate trust — the firewall's local certificate plus the KME's CA and server certificates.

Source: ngfw/help/12-1/device/device-setup-quantum

Module Quiz

1. An engineer builds a new site-to-site VPN to a partner organization's Cisco router as a policy-based peer. Phase 1 negotiates successfully, and the engineer has already confirmed the IPSec crypto proposal and lifetime match on both ends. Phase 2 still never establishes. What is the most likely remaining mismatch to check?

Phase 1 succeeding rules out the IKE Gateway/PSK; with crypto proposal and lifetime already confirmed to match, a Proxy ID mismatch is the classic remaining Phase 2 blocker for policy-based peers.

2. A retailer is opening 200 new branch stores over the next year and wants each new store's firewall to automatically establish a tunnel back to headquarters, without an engineer hand-building an IKE Gateway and IPSec Tunnel object for every site. Which approach fits, and why is manual site-to-site IPSec a poor match here?

LSVPN lets satellite firewalls auto-onboard against a portal instead of an engineer hand-building tunnel objects per site; manual IPSec tunnels don't scale to that headcount since each is its own object pair.

3. Once a site-to-site IPSec tunnel is up between HQ and a cloud VPC and traffic starts flowing across it, how does that traffic get evaluated for security policy?

The tunnel interface behaves like any other interface for zone assignment and Security Policy purposes — there is no separate VPN-only policy engine.

4. A newly built site-to-site tunnel refuses to come up. Before assuming it's a routing or zone problem, the on-call engineer runs show vpn ike-sa and show vpn ipsec-sa. Which two are genuinely common root causes worth checking first? (Choose two.)

A tunnel that stays down almost always traces back to a Phase 1/Phase 2 mismatch — crypto proposals, lifetimes, or Proxy IDs — not a management-interface or content-update issue.

5. A defense contractor transmits data today that must remain confidential for at least 20 years. Security argues the current classical-crypto VPN tunnels are already at risk, even though no quantum computer capable of breaking them exists yet. What threat model are they describing, and why does it matter now rather than only once quantum computers mature?

"Harvest now, decrypt later" means data with a long confidentiality lifetime is exposed the moment it's captured with classical crypto, regardless of when decryption capability eventually arrives.

6. An engineer is configuring Quantum-Ready VPN for the first time and needs to connect the firewall to a Key Management Entity (KME). What two categories of settings does the QKD profile need, and where does trust between firewall and KME come from?

A QKD profile defines connection details (KME URL, local SAE ID) and certificate trust (local cert plus KME CA and server certs) — the same certificate-based model used to authenticate other trusted infrastructure, applied here to key delivery.

7. A security architect is evaluating whether to enable Quantum-Ready VPN on a pair of firewalls running PAN-OS 11.1 that currently terminate a standard IPSec tunnel to a partner. What has to be true before this is even possible?

QKD has real prerequisites: PAN-OS 12.1+ and physical KME hardware. It is not a software-only toggle and it doesn't replace the existing IKE/IPSec tunnel model.

8. A company has exactly one always-on connection between its data center and a single cloud VPC, and separately a government contract requiring 25-year confidentiality for data crossing that link. Which two statements correctly describe how to design this? (Choose two.)

A single stable link is exactly what hand-configured IPSec is good at — LSVPN solves the many-sites onboarding problem, not confidentiality horizon. QKD layers quantum-safe key sourcing onto the existing tunnel model rather than replacing it.
← Access & IdentitySoftware Firewalls: Containers & Kubernetes →