>
    Strata Copilot
    Configure Post-Quantum IKEv2 VPNs with RFC 8784 PPKs
    Focus
    Download PDF
    Focus
    1. Home
    2. Network Security
    3. Configure Quantum Resistant IKEv2 VPNs
    4. Configure Post-Quantum IKEv2 VPNs with RFC 8784 PPKs
    Download PDF
    Network Security

    Configure Post-Quantum IKEv2 VPNs with RFC 8784 PPKs

    Table of Contents

    Configure Post-Quantum IKEv2 VPNs with RFC 8784 PPKs

    Post-quantum RFC 8784 pre-shared keys make IKEv2 VPNs resistant to attacks by quantum computers.
    Where Can I Use This?What Do I Need?
    • PAN-OS
    • PAN-OS 11.1 or later.
    Post-quantum IKEv2 VPNs based on RFC 8784 work by transmitting a pre-shared secret separately (out-of-band) from the initial peering exchange (the IKE_SA_INIT Exchange). Instead of transmitting the pre-shared secret in the peering exchange, which an attacker could compromise or harvest now and decrypt later, the peering exchange only transmits a Key ID. A Key ID and a pre-shared secret comprise a unique pair called a post-quantum pre-shared key (PQ PPK).
    Each IKEv2 peer uses the Key ID to look up the pre-shared secret, which is transmitted securely between administrators or pushed by Panorama, and stored locally on each IKEv2 peer. The pre-shared key is never part of the peering exchange and never traverses the post-quantum VPN, so an attacker using a quantum computer can't steal it, crack it, and use it to decrypt data harvested from a VPN.
    Both IKEv2 peers must have the same active pairs of Key ID plus pre-shared secret so that when peers negotiate the connection, each peer can look up the same Key ID and retrieve the same pre-shared secret. If the responding peer doesn't have a matching Key ID or if the pre-shared secret associated with the Key ID differs from the initiator, the connection is aborted.
    Set up IKEv2 peering and an IPSec tunnel before configuring post-quantum components. Additionally, ensure you have Security policy rules that permit the IKEv2 and IPSec traffic between the firewalls and enable logging.
    Dynamic peer IKE gateways on the same local IP address must use the same IKE Crypto profiles and have identical Enable NAT Traversal, Post-Quantum Pre-Shared Key (PPK), Enable Post-Quantum Pre-Shared Key (PPK), and Negotiation Mode settings.
    To make your IKEv2 VPNs resistant to quantum attacks:
    1. Select NetworkNetwork ProfilesIKE Gateways, and then Add a new gateway.
      For Version, select either IKEv2 only mode or IKEv2 preferred mode.
      In IKEv2 only mode, if the peer doesn't support IKEv2, the firewall aborts the connection. In IKEv2 preferred mode, if the peer doesn't support IKEv2, the firewall falls back to IKEv1. However, the VPN must negotiate IKEv2 to use the post-quantum VPN features, so if the firewall falls back to IKEv1, those features aren't available.
      IKEv1 is considered to be weak. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select IKEv2 only mode to ensure adequate levels of security and the ability to use PQ VPNs.
    2. Configure non-quantum Advanced Options for your IKEv2 VPN.
      • If you selected IKEv2 preferred mode as the Version (in step 1), there are tabs for IKEv1 and IKEv2; select IKEv2.
      • If you selected IKEv2 only mode as the Version, only IKEv2 options display.
      Dynamic peer IKE gateways on the same local IP address must use the same IKE Crypto Profile and have the same Enable NAT Traversal and IKEv2 Fragmentation settings.
      1. Select Advanced OptionsIKEv2General.
      2. (Optional) Select an IKE Crypto Profile.
        Otherwise, the default profile is used.
      3. (Optional) Enable IKEv2 Fragmentation and set the MTU (Maximum Transmission Unit) value.
        The maximum fragmented packet size is 576 bytes.
      4. (Optional) Enable Liveness Check.
        For Interval (sec), enter a number from 2 to 100 (default is 5).
    3. Configure the post-quantum Advanced Options.
      1. Select Advanced OptionsIKEv2PQ PPK (post-quantum pre-shared key).
      2. To use post-quantum resistance features on the VPN, Enable Post-Quantum Pre-Shared Key (PPK). This option is disabled by default.
        Select (or deselect) this option for all dynamic peer IKE gateways on the same local IP address.
        For IKEv2 negotiation and to support RFC 8784, configure and activate at least one PPK.
      3. Set the Negotiation Mode to Preferred or Mandatory.
        Enable the same mode for dynamic peer IKE gateways on the same local IP address.
        • Preferred (default mode)—When the firewall negotiates with the peer, the firewall first attempts to negotiate using PQ PPKs. If the peer doesn't support RFC 8784, the firewall falls back to a classical key exchange for the connection. If you don't know or don't have control over whether the peer supports RFC 8784, Preferred mode preserves backward compatibility to ensure connections fall back instead of dropping.
        • Mandatory—When the firewall negotiates with the peer, the peer must support RFC 8784 PQ PPKs. If the responding peer doesn't support RFC 8784, the firewall aborts the connection. Use Mandatory mode when you know the peer supports RFC 8784 PQ PPKs.
          For maximum security, use Mandatory mode when possible.
      4. Add and Activate up to 10 unique PQ PPKs.
        A PQ PPK consists of two paired elements: a PPK KeyID and a PPK Secret. The PPK KeyID is a unique string that identifies the PPK Secret and can be anything you want up to 31 characters, such as PPK-1 or Super Strong PPK. The PPK Secret is the random pre-shared key, which is never transmitted through the VPN because the administrators of both peers share the key using a secure communication method and configure it on the peers out-of-band. The firewall only transmits the KeyID in the IKEv2 VPN so that the peer can look up the PPK Secret locally.
        The number of PQ PPKs you can define depends on what the IKE peer can support. Some vendors' implementations allow fewer than 10 unique PQ PPKs; some implementations even allow only one. Don't define more PQ PPKs than the peer can support because both peers must have exactly the same PQ PPKs available.
        Configure multiple active PQ PPKs for peers that support multiple PQ PPKs. The firewall chooses randomly from the active PQ PPKs, which adds an element of randomness to the IKEv2 negotiation.
        Configuring multiple PQ PPKs is most secure because it adds a random element to PQ PPK selection.
        You can create the PPK Secret manually or use the firewall to generate a strong secret for you. Configure the PPK Secret manually if you want to generate the key yourself or if you receive a PQ PPK from a peer's administrator and you need to configure it on your firewall. The longer the PPK Secret, the greater the number of entropy bits, which makes the PPK Secret harder to crack.
        To configure the PPK Secret manually, which you can specify using ASCII characters:
        1. Specify a unique PPK KeyID of up to 31 characters.
        2. Specify a unique, random PPK Secret string. The string can be from 32-128 characters (16-64 bytes, which equates to 128-512 bits of entropy).
          Specify a PPK Secret that is at least 64 characters (32 bytes, or 256 bits of entropy) in length to create a strong key.
        3. Specify exactly the same string in Confirm PPK Secret.
          Store the PPK secret securely. The PPK secret is not displayed in cleartext, so if you don't store it now, you can't retrieve it later. (You can delete the PQ PPK and configure another one if necessary.) Because the IKEv2 peer must have the same PQ PPK (KeyID plus PPK Secret), you might need to communicate the PPK secret to another administrator. If so, make sure the communication method used is cryptographically secure and make sure the PPK secret is securely stored.
          The NSA publishes guidance on how to handle pre-shared keys safely, including RFC 8784 quantum pre-shared keys.
        4. Activate is selected by default so the firewall can use the PPK KeyID and PPK Secret pair (the PQ PPK) to negotiate with the peer. If you don't want the firewall to use this PPK KeyID and PPK Secret pair when negotiating with peers, uncheck Activate.
          For example, if you configure a new PQ PPK on a firewall, you might want to deactivate it until the peer's administrator can add the same PQ PPK to the peer to avoid a connection failure because the initiator uses a PQ PPK that isn't installed on the peer yet.
        5. Click OK. The PQ PPK tab shows the PPK KeyID in cleartext, hides the pre-shared key, and shows the activated state of the PQ PPK.
          To configure the PPK Secret using the firewall's automatic strong PPK generation, which uses hexadecimal characters:
          1. Specify a unique PPK KeyID of up to 31 characters.
          2. Set the PPK length (characters) to the length you want to generate for the PPK Secret. The default is 32 characters (16 bytes).
            Set PPK length (characters) to at least 64 characters (32 bytes, or 256 bits of entropy) in length to generate a strong key.
          3. Click Generate Strong PPK. The firewall generates and displays a strong PPK secret of the length specified in PPK length (characters).
            This is the only time the PPK secret is displayed in cleartext. If you do not securely store the secret, you can't retrieve it. (You can delete the PQ PPK and configure another one if necessary.) Because the IKEv2 peer must have the same PQ PPK (KeyID plus PPK Secret), you might need to communicate the PPK secret to another administrator. If so, make sure the communication method used is cryptographically secure and make sure the PPK secret is securely stored.
            Copy the PPK secret, click OK, and paste it into the PPK Secret and Confirm PPK Secret fields.
          4. Activate is selected by default so the firewall can use the PPK KeyID and PPK Secret pair (the PQ PPK) to negotiate with the peer. If you don't want the firewall to use this PPK KeyID and PPK Secret pair when negotiating with peers, uncheck Activate.
            For example, if you configure a new PQ PPK on a firewall, you might want to deactivate it until the peer's administrator can add the same PQ PPK to the peer to avoid a connection failure because the initiator uses a PQ PPK that isn't installed on the peer yet.
          5. Click OK. The PQ PPK tab shows the PPK KeyID in cleartext, hides the pre-shared key, and shows the activated state of the PQ PPK.
      5. Click OK to create the VPN.
    4. Commit the configuration.
      The Post-Quantum IKEv2 RFC 8784 Configuration Example topic provides an example of a simple topology and how to configure post-quantum IKEv2 VPN support for the topology.
    5. If you aren't the administrator of both IKEv2 peers, securely communicate the PQ PPK (KeyID plus PPK Secret) to the peer's administrator for installation on the peer. Secure PQ PPK communication and storage are critical for securing your data.
      Both IKEv2 peers must have the same active Key IDs and associated pre-shared secrets to bring up the post-quantum VPN connection.

    © 2026 Palo Alto Networks, Inc. All rights reserved.