VPN & Connectivity
Site-to-Site VPNs (IKE/IPSec) 31
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
IPSec deliberately splits into two phases because they're solving two genuinely different problems: first, "can I trust that I'm actually talking to the real peer, not an impersonator on the public internet," and only after that's settled, "let's actually build the tunnel that carries real data." Trying to do both at once would mean negotiating data-plane crypto with a peer you haven't verified yet.
- Phase 1 — IKE Gateway object — "establish and authenticate the relationship." This negotiates who the peer is (peer IP/identity) and proves it's really them, via either a pre-shared key or certificate authentication, plus the IKE crypto profile (which encryption/hashing/DH-group proposals are acceptable). Nothing about actual user traffic is carried yet — this phase produces a secure, authenticated channel that Phase 2 then runs inside.
- Phase 2 — IPSec Tunnel object (Network > IPSec Tunnels) — "now actually build the data tunnel." This can only happen once Phase 1's relationship exists, because it's negotiated through that already-authenticated channel. It defines the tunnel interface binding, the IPSec crypto profile for the actual data encryption, and — for policy-based peers specifically — Proxy IDs, which are traffic selectors that both ends must define identically to agree on which traffic the tunnel is actually supposed to carry. A mismatch here is one of the most common reasons Phase 2 fails even after Phase 1 succeeds.
Once the tunnel is actually up, it behaves like an ordinary tunnel interface from routing's perspective — normal Security Policy and zone assignment apply to traffic crossing it exactly as they would for any physical interface, which is why nothing about how you write security rules needs to change just because the traffic happens to be tunneled. Tunnel status, restart, and refresh are all managed from that same IPSec Tunnel configuration point.
Diagrams: Palo Alto Networks Learning Center, PAN-OS course: Site to site vpns. Click an image to enlarge.
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. Checkshow 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?
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?
Build, route & troubleshoot an IPSec tunnel — exam drill
The three objects, in order:
- Tunnel interface (
Network > Interfaces > Tunnel) — assign to a security zone and a virtual/logical router. IP address is optional but required for tunnel monitoring or running OSPF/BGP over the tunnel. - IKE Gateway — Phase 1: peer IP/identity, IKEv2 (preferred), authentication (pre-shared key or certificate), and the IKE Crypto profile (encryption, hash, DH group, lifetime).
- IPSec Tunnel object — binds the IKE Gateway + the IPSec Crypto profile (Phase 2: ESP/AH, encryption, hash, PFS/DH group, lifetime) + the Tunnel Interface. Add Proxy IDs (one pair per local/remote subnet combination) for policy-based peers (Cisco ASA, most non-PAN devices).
Then: add a route to the remote network via the tunnel interface, and write Security policy.
Security policy — two rules are involved: (1) a rule allowing
ike and ipsec (or ipsec-esp/
ipsec-esp-udp, UDP 500/4500) between the Untrust zone and the firewall itself
(intrazone/local) so the tunnel can establish; (2) a rule permitting the actual
user traffic between the internal zone and the tunnel interface's zone.
| Symptom | Cause the exam wants |
|---|---|
| Tunnel never comes up; log says "NO-PROPOSAL-CHOSEN" in Phase 1 | IKE Phase 1 mismatch — encryption, hash/auth, or DH group differ between peers (also check PSK, peer identity) |
| Phase 1 up, Phase 2 won't establish | IPSec Phase 2 mismatch — crypto proposal, PFS group, lifetime, or Proxy IDs not mirrored |
| Tunnel intermittently drops / re-negotiates | IPSec SA lifetime values mismatched between the two devices |
| Phase 1 and Phase 2 both "up" but no traffic passes | Missing route into the tunnel interface, missing/incorrect Proxy ID, or missing Security policy for the data traffic — not a crypto problem |
| First subnet pair works; a newly added remote subnet fails (peer is policy-based / Cisco ASA) | Missing Proxy ID pair for the new subnet combination |
| Large packets / some apps fail across the tunnel | Fragmentation — lower the tunnel interface MTU (and/or set TCP MSS adjustment) to allow for encapsulation overhead |
Tunnel health monitoring: enable Dead Peer Detection (DPD) in the IKE Gateway, and/or a Tunnel Monitor profile (pings an IP across the tunnel and can fail over / disable the route). Pinging from the MGT interface does not test the data-plane tunnel.
| Tunnel Type | Use Case | Key Characteristics | Exam Troubleshooting Rules |
|---|---|---|---|
| IPSec | Secure site-to-site & remote access | Full payload encryption, IKEv1/IKEv2, supports Post-Quantum PSK (PPK, RFC 8784) | Phase 1 establishes secure management channel; Phase 2 establishes data-carrying SAs. Both proposals must match identically. |
| GRE | Multiprotocol / routing encapsulation | Encapsulates packets, no native encryption, supports multicast / routing protocols (OSPF, BGP) | Usually paired as GRE-over-IPSec when routing protocol transit must be encrypted. |
CLI Verification & Troubleshooting Commands
Exam traps
- Tunnel down = crypto/proposal/PSK mismatch. Tunnel up but no data = routing / Proxy ID / Security policy. Don't conflate them.
- The tunnel interface IP is normally a private address (or none), never a public IP — the public IP lives on the physical interface / IKE Gateway.
- "Best way to monitor an IPSec tunnel's health" → DPD (or Tunnel Monitoring), not Application Override, not session logging, not MGT-interface ping.
- Aggressive Mode and disabling PFS are not security improvements — reject those answers.
Source: ngfw/help/11-1/network/network-ipsec-tunnels; Palo Alto Next-Gen Firewall (NGFW) Master Cheat Sheet Domain 1.6
Quantum-Resistant & Quantum-Ready VPN 32
Learning objectives
- Explain the "harvest now, decrypt later" threat that motivates quantum-safe VPN
- Configure post-quantum cryptography on an IPSec tunnel: hybrid key exchange, PQ pre-shared key (RFC 8784), and additional PQC key-exchange rounds (RFC 9370)
- Describe how Quantum Key Distribution (QKD) plugs into an existing IPSec tunnel
Post-Quantum Cryptography (PQC) on IKEv2 — the exam's focus
Classical key exchange (RSA, Diffie-Hellman, ECDH) is broken by Shor's algorithm on a large quantum computer. Symmetric ciphers like AES-256 are only weakened (Grover's algorithm) — so the fix targets the key exchange, not the data cipher, and it requires IKEv2. PAN-OS offers three combinable options, configured in the IKE Crypto profile and the IKE Gateway > Advanced Options:
- Hybrid / composite key exchange — combine a classical DH group with a post-quantum KEM (e.g. Kyber / ML-KEM) so the session key is safe if either one holds. This is the NIST-recommended transitional approach and the usual "correct answer".
- Post-Quantum Pre-Shared Key (PPK) — RFC 8784 — mixes an out-of-band PQ pre-shared key into IKEv2 key derivation. Enabled in the IKE Gateway with a PPK ID and value.
- Additional key-exchange rounds — RFC 9370 — IKEv2 "multiple key exchanges": add one or more extra PQC key-exchange Rounds in the IKE Gateway Advanced Options / IKE Crypto profile.
Watch: short GUI walkthroughs
Clips from the Palo Alto Networks Learning Center. They load only when you press play.
Exam traps (PQC)
- Right answers: "hybrid key exchange (classical + PQC)", "use NIST-approved PQC algorithms", "IKEv2 with a PQ KEM such as Kyber", "post-quantum pre-shared key", "add PQC rounds in the IKE Gateway".
- Wrong answers: "ECDH is quantum-safe", "RSA-2048/3072/4096 resists quantum", "AES-128/256-GCM is inherently quantum-resistant", "disable PFS", "use IKEv1", "switch to SSL/TLS VPN because it's quantum-resistant". Disabling PFS is always wrong — it matters more post-quantum.
- QKD requires physical KME hardware; PQC does not. A question that says "no additional hardware" points to PQC.
Quantum Key Distribution (QKD) — hardware key sourcing
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
Why classical Diffie-Hellman is the actual weak point. Standard IPSec key exchange (classical Diffie-Hellman) is secure today only because factoring/discrete-log problems are computationally infeasible for classical computers — but a sufficiently powerful quantum computer is specifically expected to break exactly that class of math. An adversary doesn't need a working quantum computer right now to be a threat: they can capture and store today's encrypted traffic, then decrypt it retroactively once quantum computing catches up. For data that needs to stay secret for years, that future capability is a present-day risk.
How QKD actually replaces the weak link, without replacing the whole system. Quantum Key Distribution 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. The reason this doesn't require a whole new VPN architecture: QKD only replaces how the key material is generated and delivered, not the IPSec tunnel model itself, so everything downstream (the tunnel interface, security policy, zone assignment) works completely unchanged.
Setting this up means defining a QKD profile (Device > Setup > Quantum) that points at a specific KME: its URL, the firewall's own Security Application Entity (SAE) ID (identifying this firewall to the KME), and a full certificate trust chain between firewall and KME (local certificate, KME CA certificate, KME server certificate) — because the key delivery channel itself has to be authenticated, or you'd just be trading one trust problem for another. Once configured, the quantum-safe keys the KME hands over feed directly into the site-to-site IPSec tunnel's key material, hardening that tunnel against future quantum cryptanalysis today, years before the actual quantum threat materializes.
Diagrams: Palo Alto Networks Learning Center, PAN-OS course: Quantum ready virtual private networks. Click an image to enlarge.
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?
Q2. Which two categories of things does a QKD profile need to define to connect a firewall to a KME?
Source: ngfw/help/12-1/device/device-setup-quantum
GlobalProtect Portals, Gateways & Split Tunneling 33
Learning objectives
- Configure GlobalProtect Portal & Gateway roles, SSL/TLS profiles, and client authentication
- Implement Single Sign-On via Authentication Override Cookies between Portal and Gateway
- Master Split Tunneling configuration for Subnets, Domains, Applications, and High-Bandwidth Video
- Avoid common deployment pitfalls (IP Pool mutual exclusivity, dual-location data collection)
GlobalProtect provides enterprise remote-access VPN by separating configuration delivery (Portal) from network tunnel termination (Gateway). Understanding how these components interact and how split tunneling conserves bandwidth is critical for the NGFW Engineer exam.
Why
Remote users need secure access to internal resources while avoiding latency and bandwidth bottlenecks caused by backhauling non-sensitive public web or streaming video traffic.How
Portal vs. Gateway Roles:
- Portal (Control Plane): Exposes port 443 on its assigned interface. Provides the web application for downloading the agent client software and pushes client app configurations (gateway lists, authentication profiles, HIP collection rules, disconnect timeouts).
- Gateway (Data Plane / Tunnel Termination): Exposes port 443 and IPSec (UDP 500/4500). Terminates IPSec/SSL tunnels, assigns IP addresses from client IP pools, and routes traffic through logical tunnel interfaces (e.g.
tunnel.2) bound to security zones (e.g.,GP-Users).
Single Sign-On with Authentication Override Cookies:
To avoid requiring users to enter credentials twice (once for the portal and once for the gateway), configure the Portal to Generate cookie and the Gateway to Accept cookie. Both must use the exact same certificate to encrypt/decrypt the cookie payload. If portals and gateways reside on separate appliances, this certificate must be imported onto both devices.
Split Tunneling Architecture:
- Include Subnets / Domains / Apps: Explicitly specifies traffic that must enter the VPN tunnel for firewall security policy inspection.
- Exclude Subnets / Domains / Apps: Directs traffic (such as
*.office365.comorMicrosoft Teams) to bypass the tunnel and egress directly via the client's local internet gateway. - Video Traffic Exclusion: Uses App-ID signatures (e.g., YouTube, Dailymotion) to strip video streaming out of the tunnel, preventing bandwidth exhaustion on enterprise WAN links.
Pros
- App-ID video and SaaS exclusions prevent corporate tunnel bandwidth exhaustion
- Authentication override cookies eliminate redundant credential prompts for end users
- Tunnel mode allows applying stateful Security Policies to remote user zones
Cons
- Configuring IP pools in both global gateway settings and client settings causes commit errors
- Registry key data collection requires configuration in two separate portal menus
- Embedded browser may fail with complex SAML IdP redirects unless default browser is enabled
Exam trap & Configuration Gotchas
- IP Pool Mutual Exclusivity: Client IP pools can be defined globally on the Gateway tab or inside individual Agent Client Settings profiles, but not both. Configuring pools in both locations causes a commit validation failure.
- Dual-Location Host Data Collection: When collecting custom registry keys or processes for HIP, the registry paths must be added in two places:
Portal > Data CollectionandPortal > Agent > App Config > Data Collection. - App-ID Security Rule Dependencies: When permitting GlobalProtect through a firewall rule, allow
panos-globalprotect(which automatically pullsssldependency) ANDipsec-esp-udpfor tunnel mode.
Self-check
Q1. What happens if an engineer configures client IP pools both globally on the Gateway tab and inside an Agent Client Settings profile?
Q2. Which split tunneling option allows YouTube traffic to bypass the VPN tunnel without unencrypting client web traffic?
Source: Palo Alto Professional Video Series (VID5, VID6, VID7); ngfw/help/11-1/globalprotect
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?
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?
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?
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.)
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?
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?
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?
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.)
9. Which two statements correctly describe the Security policy requirements for an IPSec tunnel to a third-party gateway? (Choose two.)
10. A site-to-site IPSec tunnel to a third-party gateway (e.g. a Cisco ASA) is failing to establish, and routing to the peer is confirmed correct. What's the most likely cause?
11. For which two purposes does a tunnel interface need an IP address assigned? (Choose two.)
12. Which IKE Gateway configuration enables post-quantum key exchange for a VPN between two PAN-OS firewalls?