|
|
|
|
|
|
|
|
|
|
|
|
|
Choose auto, aggressive, or main. In auto mode (default), the device can accept both main mode and aggressive mode negotiation requests; however, whenever possible, it initiates negotiation and allows exchanges in main mode. You must configure the peer device with the same exchange mode to allow it to accept negotiation requests initiated from the first device.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
•
|
When you enable Strict Cookie Validation, IKEv2 cookie validation is always enforced; the initiator must send an IKE_SA_INIT containing a cookie.
|
|
•
|
When you disable Strict Cookie Validation (default), the system will check the number of half-open SAs against the global Cookie Activation Threshold, which is a VPN Sessions setting. If the number of half-open SAs exceeds the Cookie Activation Threshold, the initiator must send an IKE_SA_INIT containing a cookie.
|
|
|
|
Enable IKEv2 Fragmentation when using PQC KEMs to handle the large key sizes and data payloads. Both VPN termination devices should be set to the same fragmentation values. The default MTU values are IPv4: 576 and IPv6: 1280.
|
|
|
The IKEv2 Liveness Check is always on; all IKEv2 packets serve the purpose of a liveness check. Click this box to have the system send empty informational packets after the peer has been idle for a specified number of seconds. Range: 2-100. Default: 5.
|
|
|
|
|
Enable Post-Quantum Pre-Shared Key (PPK)—To use post-quantum pre-shared keys (PPKs) to create post-quantum VPNs that resist attacks by quantum computers, enable PPKs and configure them in VPNs that support IKEv2. PPKs aren't supported for IKEv1. Enable Post-Quantum Pre-Shared Key (PPK) is disabled by default.
|
•
|
Preferred—If the responding peer supports PPKs ( RFC 8784), it uses PPKs. If the peer doesn't support RFC 8784, the IKEv2 handshake falls back to the classic key exchange (Diffie-Hellman). This is the default Negotiation Mode.
|
|
•
|
Mandatory—The responding peer must support RFC 8784 PPKs. If the responding peer doesn't support RFC 8784, the initiating peer aborts the connection.
|
PPK KeyID—A name that identifies the associated PPK. The initiating peer PPK transmits the PPK KeyID to the responding peer so the responding peer can look up the associated PPK.
Post-Quantum Pre-shared Key (PPK)—The secret key, which is associated with its KeyID. The PPK is never transmitted between peers, so it isn't natively vulnerable to a Harvest Now, Decrypt Later attack and it isn't vulnerable to Shor's algorithm.
Activate—Shows which PPKs the firewall can use. You must activate at least one PPK. The firewall randomly selects a PPK from the activated PPKs to initiate IKEv2 peering with the responding peer. You activate and deactivate PPKs when you Add them or when you edit them. In accordance with RFC 8784, once the firewall selects a PPK, the firewall uses that PPK for the duration of the IKEv2 gateway's lifetime, including through IKE rekeys. The firewall excludes deactivated PPKs from selection.
You can Add up to ten PPK KeyID plus PPK pairs. In the Add Post-Quantum Pre-shared Key dialog box:
|
•
|
PPK KeyID—The name that identifies the PPK Secret (the pre-shared key string). You can use any string value, such as "PPK_ID1" or "Super_Strong_PPK5".
|
|
•
|
PPK Secret—A string that can range from 32-128 characters (16-64 bytes). The longer the string, the stronger the key. The PPK Secret is associated with its PPK KeyID. You can enter a string of your choosing or you can have the firewall automatically Generate Strong PPK.
|
|
•
|
Confirm PPK Secret—The PPK Secret string must exactly match the string you entered in the PPK Secret field.
|
|
•
|
Activate—Check this box to activate the PPK for use for IKEv2 peering. New PPKs are activated by default. Uncheck the box to deactivate a PPK. You can activate and deactivate PPKs when you Add them and when you select and edit them.
|
|
•
|
PPK length (characters)—If you choose to have the firewall generate a strong PPK Secret for you instead of typing in a PPK Secret, the field sets the length of the automatically generated PPK sting. The default is 32 characters (the minimum length) but for best security, generate strings that are at least 64 characters (32 bytes) in length.
|
|
•
|
Generate Strong PPK—Click to make the firewall generate a PPK Secret string of the length specified in the PPK length (characters) field.
|
When you let the firewall generate a strong PPK Secret, the result appears in the Strong PPK Secret dialog box. Select and copy the string, then paste the string into the PPK Secret and Confirm PPK Secret fields, and save the secret in a secure location so that you can communicate it to the peer's administrator to install it on the peer. Copy only the hexadecimal string, don't copy the "PPK:" that precedes it. For example, if the generated PPK displays as:
|
|
|
|
|
Enable Post-Quantum Key Exchange to use IKEv2 KEM hybrid keys. To create post-quantum VPNs that resist attacks by quantum computers, enable hybrid keys and configure them in VPNs that support IKEv2. Configure the IKE Crypto profile to select the KEMs to use for the hybrid key. Enable Post-Quantum Key Exchange is disabled by default.
Select Block IKEv2 if vulnerable cipher is used to block IKE peering when a known vulnerable cipher is the only available cipher. The setting is enabled by default.
|