As the advent of practical quantum computing draws closer, security vendors are increasingly introducing post-quantum cryptographic (PQC) algorithms to protect existing security architectures against future threats. One important use case is site-to-site VPN connectivity, where organisations must address the “harvest now, decrypt later” risk – the possibility that encrypted traffic captured today could be decrypted by quantum computers in the future.

To mitigate this threat, Palo Alto Networks has implemented several approaches for quantum-resistant VPN tunnels, including Post-Quantum Preshared Keys (PPK), Key Encapsulation Mechanisms (KEM), and Quantum Key Distribution (QKD). Each method offers a different balance of security, complexity, and operational requirements.

In this blog post, we will examine these approaches in detail, with a particular focus on KEM-based solutions, which are generally considered the preferred path forward. We will also demonstrate how to configure a site-to-site VPN tunnel that combines traditional Diffie-Hellman (DH) key exchange with post-quantum algorithms such as Kyber (standardised by NIST as ML-KEM), providing both classical and quantum-resistant security.

Post-Quantum Security for VPN-Tunnels

The primary challenge posed by quantum computers is their ability to break the asymmetric cryptographic algorithms that are widely used today for key exchange, most notably Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH). As a result, we need new ways to securely establish VPN session keys over an untrusted network, such as the Internet.

Palo Alto Networks currently supports three approaches to address this challenge:

PPK (Post-Quantum Preshared Key)

Specified in RFC 8747, PPK is the simplest approach. It introduces an additional secret, known only to both VPN peers, into the key derivation process. (Do not confuse this with the traditional VPN PSK used for authentication. The PPK serves a different purpose and contributes to key establishment.)

Because the PPK is a randomly generated secret and not derived from a mathematically solvable key exchange, it remains resistant to attacks from both classical and quantum computers. Even if an attacker were able to break the DH exchange in the future, they would still require knowledge of the PPK to derive the session keys.

The downside is scalability. Every VPN tunnel requires its own securely distributed PPK, creating an additional operational burden. Furthermore, if an attacker records VPN traffic today and later obtains the corresponding PPK, the recorded traffic may become decryptable. In other words, the strong forward secrecy properties (PFS) normally provided by ephemeral key exchanges are reduced.

KEM (Key Encapsulation Mechanism)

KEM-based key exchange is expected to become the preferred solution for most deployments. Instead of relying solely on classical DH or ECDH groups, a post-quantum algorithm is used to establish shared key material. In many implementations, including current VPN solutions, the post-quantum mechanism is combined with traditional DH/ECDH in a hybrid approach, providing protection against both classical and quantum attacks.

Several post-quantum KEM algorithms have been proposed over the years. NIST has standardised CRYSTALS-Kyber as ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), which is currently the leading candidate for widespread deployment. Additional algorithms, such as HQC, may be standardised in the future as alternative options.

When using post-quantum key exchange in IKEv2, the exchange is typically performed in a hybrid manner. A classical key exchange, such as ECDH Group 21, is combined with at least one additional post-quantum key exchange round (for example, ML-KEM). The resulting key material is derived from both exchanges, ensuring that the VPN remains secure as long as at least one of the underlying mechanisms remains uncompromised.

While a single classical and a single post-quantum exchange are sufficient for most deployments, IKEv2 allows multiple additional key exchange rounds to be performed. This can further diversify the cryptographic assumptions, although the practical security benefit quickly diminishes. For most environments, one classical and one post-quantum exchange strike a sensible balance between security and complexity; configuring multiple post-quantum rounds is generally considered a rather conservative – or perhaps slightly paranoid – approach. (The German way. 😂)

QKD (Quantum Key Distribution)

This is where things become truly futuristic. :)

QKD uses the principles of quantum mechanics to exchange cryptographic key material. Any attempt to observe or intercept the quantum transmission changes its physical properties, allowing eavesdropping attempts to be detected.

In practice, QKD requires specialised hardware and a dedicated quantum communication channel, typically a fibre-optic connection between the participating sites. The generated keys are then used by conventional VPN technologies running over normal network links.

While QKD offers fascinating security properties, it also introduces high cost and operational complexity. For this reason, it is currently limited to highly specialised environments. Personally, I do not expect to deploy many QKD-enabled VPNs in the next few years – at least not in my lab. 🙂

PQ-Variants in PAN-OS Versions

Note that PANW has implemented those variants sequentially. Depending on your PAN-OS version, you’ll see none up to all three of them. ;) Links: PAN-OS 11.1, PAN-OS 11.2.

Also note that with PAN-OS 11.2 and 12.1, the list of ciphers is different:

• PAN-OS 11.2 offers various pre-standardised ciphers such as Kyber, Bike, FrodoKEM, HQC, but *not yet* the NIST standard of ML-KEM.
• PAN-OS 12.1 offers all of them as well, but additionally the NIST standard ML-KEM.

Example: S2S-VPN between 2x Palos

For this lab, I’m using 2x PA-440, one with PAN-OS 11.2.12 “pa-home”, the other with 12.1.6 “pa-lab”. Hence, I can’t use ML-KEM (since it was only added with PAN-OS 12.1), but the underlying protocol Kyber. All following screenshots/listings are from PAN-OS 12.1.6.

The first step is to add the appropriate crypto profiles for IKE as well as for IPsec: [By the way: For AES-GCM with DH group 21, sha512 is used as the PRF. This is not documented anywhere 🤦 but a logical step since group 19 uses sha256 and group 20 uses sha384, which is documented here.]

Next is to tune the IKE Gateway. Assuming you already have a working site-to-site VPN setup, you need to set the following:

• IKE Crypto Profile with PQ ciphers set a minute ago
• IKEv2 Fragmentation (otherwise you’ll get an operation failed with “pq-kem constraints failed: IKEv2 fragmentation must be enabled for PQ KEM”) with a blank line, which then defaults to some values. (There is a bug with PAN-OS 12.1.6 which sets the value to 576 if left blank. Since I’m using IPv6, I’ve set it to 1280 manually.)
• PQ KEM: Enable Post-Quantum Key Exchange and “Block IKEv2 if vulnerable cipher is used”, whatever this means.

as well as the IPsec Crypto Profile at the IPsec Tunnel:

These are the (a little weird) system logs after the tunnel establishment:

Verify!

Of course, verification is key. Search for the “KYBER-1024” entries, respectively ML-KEM, or whatever algorithm you’ve chosen.

• show vpn ike-sa detail gateway <name>
• show vpn ipsec-sa tunnel <name>

Examples:

Soli Deo Gloria!

Photo by Dynamic Wang on Unsplash.