1.4 Site-to-Site VPN Tunnels: IPSec, GRE, and Quantum-Resistant Cryptography
Key Takeaways
- PAN-OS site-to-site IPSec VPNs pair an IKE Gateway (Phase 1 identity and negotiation) with an IPSec Tunnel interface bound to an IPSec Crypto Profile (Phase 2 security associations) and traffic-selector proxy IDs.
- IKEv2 is the recommended negotiation protocol for new tunnels; it supports Multiple Key Exchanges (RFC 9370) and IKE_INTERMEDIATE (RFC 9242), which are required to carry large post-quantum key shares without IP fragmentation.
- PAN-OS 11.2 and later adds Post-Quantum Key Exchange (PQ KEM) hybrid keys that combine a classical Diffie-Hellman secret with a quantum-resistant KEM such as Kyber (ML-KEM, NIST FIPS 203) to protect against Harvest Now, Decrypt Later attacks.
- Generic Routing Encapsulation (GRE) tunnels are Layer 3 overlay tunnels used to transport multicast and dynamic routing protocols across networks that strip them, and they can be protected by IPSec when confidentiality is required.
- Quantum-resistant VPNs fall back automatically to classic IKEv2 when a peer has not been upgraded, allowing incremental rollout without breaking existing connectivity.
1.4 Site-to-Site VPN Tunnels: IPSec, GRE, and Quantum-Resistant Cryptography
Site-to-site VPN tunnels are a core PAN-OS networking competency on the NGFW Engineer blueprint (task 1.6). Engineers must build IKE/IPSec tunnels that establish trust between peers, negotiate encryption parameters, define which traffic is protected, and increasingly harden key exchange against future quantum computers. Mastery requires understanding the Phase 1 / Phase 2 object model, the tunnel interface, proxy IDs (traffic selectors), and the post-quantum enhancements introduced in PAN-OS 11.2.
IPSec Tunnel Object Model
A PAN-OS site-to-site IPSec VPN is composed of three configuration objects that map to the two IKE phases.
| Object | Purpose | Key Settings |
|---|---|---|
| IKE Gateway | Phase 1 peer identity and negotiation | Peer IP, pre-shared key or certificate, IKE version (IKEv1/IKEv2), IKE Crypto Profile, local/peer identity, extended authentication |
| IPSec Crypto Profile | Phase 2 security association parameters | ESP encryption (AES-GCM/AES-CBC), authentication, Diffie-Hellman group, lifetime |
| Tunnel Interface | Logical dataplane interface that carries decrypted traffic | Tunnel interface number (e.g. tunnel.1), assigned virtual router and security zone |
The tunnel interface is the crucial conceptual link: the IPSec tunnel terminates on a tunnel.N interface, and that interface is placed in a security zone and a virtual router exactly like a physical interface. Traffic is routed into the tunnel with a static route whose next hop is the tunnel interface, and security policies govern flow into and out of the tunnel zone.
Proxy IDs and Traffic Selectors
Proxy IDs (IKEv1) or Traffic Selectors (IKEv2) define the local and remote subnets that the SA protects. A common operational failure is a proxy-ID mismatch: both peers must agree on local and remote network prefixes or the Phase 2 negotiation never completes even though Phase 1 succeeds. When only one side defines proxy IDs and the other is set to 0.0.0.0/0, the tunnels may still come up only for the subnet the initiator advertises.
IKEv1 vs IKEv2
IKEv2 is the modern default and the only protocol that supports post-quantum key exchange. It uses fewer exchanges than IKEv1, natively supports MOBIKE (mobility), and uses separate Traffic Selectors. IKEv1 remains for backwards compatibility with older peers. Engineers should prefer IKEv2 for all new tunnels.
GRE Tunnels
Generic Routing Encapsulation (GRE) creates a stateless Layer 3 overlay tunnel that encapsulates one network protocol inside another. GRE is used when the underlying network strips traffic that IPSec alone cannot carry:
- Multicast and broadcast: IPSec transport does not natively carry multicast, so routing protocols such as OSPF and EIGRP that use multicast hello packets require a GRE overlay.
- Dynamic routing across the tunnel: GRE interfaces behave like real point-to-point interfaces and can run OSPF/BGP over them.
- IPSec over GRE: When confidentiality is also required, the GRE packet can be encrypted by an IPSec tunnel (
IPSec over GRE), or GRE can be encapsulated inside IPSec (GRE over IPSec).
A PAN-OS GRE tunnel is configured as a tunnel interface of type GRE, with a source interface/IP, peer GRE IP, GRE TTL, and an assigned virtual router and zone. Keepalives detect peer loss for the otherwise stateless tunnel.
Quantum-Resistant Cryptography (PAN-OS 11.2+)
The certification blueprint explicitly includes quantum-resistant cryptography under task 1.6.2. Palo Alto Networks implemented this as Post-Quantum Key Exchange (PQ KEM) using hybrid IKEv2.
The Threat: Harvest Now, Decrypt Later
A sufficiently powerful quantum computer running Shor's algorithm can break classical Diffie-Hellman and RSA key exchange. Adversatives can record encrypted VPN traffic today and decrypt it years from now once quantum computers mature. This is the Harvest Now, Decrypt Later (HNDL) attack. Post-quantum key exchange prevents it by mixing a quantum-resistant secret into the IPSec key derivation so that recorded traffic remains protected even against a future quantum adversary.
Standards and Mechanism
| RFC | Title | Role in PAN-OS PQ VPN |
|---|---|---|
| RFC 9370 | Multiple Key Exchanges in IKEv2 | Lets IKEv2 perform several key-exchange rounds in one negotiation |
| RFC 9242 | Intermediate Exchange in IKEv2 | Provides IKE_INTERMEDIATE messages that carry large PQC key shares without IP fragmentation |
| RFC 8784 | Mixing Preshared Keys in IKEv2 | Earlier stopgap using an extra post-quantum preshared key (PPK) |
The hybrid key combines a classical Diffie-Hellman group secret (for example group 19, 20, or 21) with a post-quantum Key Encapsulation Mechanism (KEM) such as Kyber (the precursor to ML-KEM, standardized as NIST FIPS 203). Both secrets are mixed into the IKEv2 key derivation so the tunnel remains secure if either the classical or the quantum component resists attack.
Configuration Locations
PQ KEM is enabled in three places, mirroring the classic crypto-profile workflow:
- IKE Gateway Advanced Options - PQ KEM tab: Check Enable Post-Quantum Key Exchange to turn on hybrid key mode (disabled by default).
- IKE Crypto Profile - Advanced Options: Select the Additional Key Exchange (AKE) KEMs (e.g. Kyber-512/768/1024).
- IPSec Crypto Profile - Advanced Options: Match the PQC parameters across peers.
Interoperability and Fallback
PAN-OS automatically falls back to classic IKEv2 (per RFC 8784 behavior) when the remote peer has not been upgraded, so engineers can roll out quantum-resistant VPNs incrementally without breaking existing classic connections. Best practice is to replace vulnerable classical ciphers in all new IKEv2 peerings rather than leaving them enabled alongside the quantum-resistant ones.
Operational Verification
Use the following operational checks when a tunnel will not establish:
show vpn ike-saandshow vpn ipsec-saconfirm Phase 1 and Phase 2 status.show vpn flowshows which tunnel IDs carry active traffic.show vpn ipsec-tunnelslists negotiated SAs, lifetimes, and selectors.less mp-log ikemgr.log(orikemgr-ng.logon PAN-OS 11.1+) is the primary troubleshooting log for IKE negotiation, including PQC key-exchange failures.- A Phase 1 up / Phase 2 down state almost always points to a proxy-ID or Traffic Selector mismatch, not an IKE Crypto Profile problem.
An NGFW engineer must harden site-to-site IPSec tunnels against a future quantum computer that could break classical Diffie-Hellman. Which PAN-OS 11.2 feature directly addresses Harvest Now, Decrypt Later attacks without requiring a full protocol migration?
Which two RFCs does PAN-OS 11.2 rely on to carry large post-quantum key shares during IKEv2 negotiation? (Select all that apply)
Select all that apply
A site-to-site VPN shows IKE Phase 1 established but IPSec Phase 2 never comes up. The IKE Crypto Profile and IPSec Crypto Profile match between peers. What is the most likely cause?