Gateway peer information
Select a peer from the list to display information about it.
Comments | Description given of the local peer. |
Remote gateway | Object selected to represent the remote IP address during the creation of the peer via the wizard. |
Local address | External interface presented to set up the tunnel with the peer shown. |
IKE profile | This option offers three preconfigured profiles as the protection model associated with Phase 1 of your VPN policy: StrongEncryption, GoodEncryption and Mobile. Other profiles can be created or modified in the tab Encryption profiles. |
IKE version | This option allows selecting the version of the IKE protocol (IKEv1 or IKEv2) that the peer uses. |
Identification
Authentication method | This field will show the authentication method selected during the creation of your peer via the wizard. You may modify your choice by selecting another method from the drop-down list. NOTE |
Certificate |
If you have chosen certificate-based authentication, this field will display the certificate to display to the peer to set up the IPsec tunnel. The If you had opted for the pre-shared key method, this field will not appear. |
Local ID (Optional) | This field represents an IPsec VPN tunnel endpoint, and shares the “secret” or the PSK with the “Peer ID”, the other endpoint. You are represented by the “Local ID”. Full Qualified Domain Name) or an e-mail address (user@fqdn). This identifier must be in the form of an IP address, a domain name (FQDN: |
Peer ID (Optional) | This field represents an IPsec VPN tunnel endpoint, and shares the “secret” or the PSK with the “Local ID”, the other endpoint. The “Peer ID” represents your peer. The format is the same as the previous field. |
Pre-shared key (ASCII) | In this field your PSK appears in the format you had selected earlier when creating the peer via the wizard: ASCII or hexadecimal characters (the format can be selected in the checkboxes below the field if you wish to change formats). |
Edit | This button makes it possible to directly edit the pre-shared key that was used to set up the IPsec tunnel with this peer. |
Post-quantum pre-shared keys (PPK)
The computing power of quantum computers will very likely allow it to decrypt keys that were negotiated using the Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) methods, therefore endangering the security of the IKEv2 protocol.
Malicious users would now be able to carry out "store now, decrypt later" attacks, by intercepting IPsec communications and storing them in order to decrypt them later using a quantum computer.
Clients who wish to protect themselves against such attacks can already use post-quantum pre-shared keys (PPK) to protect the exchange of data encryption keys.
To find out more on the use of post-quantum pre-shared keys for the IKEv2 protocol, please refer to RFC 8784.
In line with these recommendations, SNS versions 4.8 and higher offer the option of setting post-quantum pre-shared keys for peers using the IKEv2 protocol with certificate-based authentication.
NOTE
To be effective, these PPKs must have a sufficiently high entropy (minimum 256 bits according to RFC 8784).
PPK ID |
Full Qualified Domain Name) or an e-mail address (user@fqdn). This identifier must be in the form of an IP address, a domain name (FQDN: If this ID matches the ID of a PPK that has already been defined on the firewall (Identification tab in the IPsec VPN module), this PPK will automatically be used. In this case, there is no need to use the PPK passphrase field. This field is mandatory if the PPK required checkbox has been selected. |
PPK passphrase | If the PPK ID entered earlier does not match any PPK defined on the firewall (Identification tab in the IPsec VPN module), click on Edit to open the dialog box to enter the password (also called a secret) for this new PPK. This password can either be in ASCII or hexadecimal. |
PPK required | If this option is selected, it means that a PPK must be used to set up a tunnel with the peer. |
Advanced configuration
Do not initiate the tunnel (Responder only) | If this option is selected, the IPsec server will be put on standby. It won't initiate tunnel negotiation. This option is used in the case where the peer is a mobile host. |
IKE fragmentation | With this checkbox, IKE fragmentation can be enabled when IKE packets exceed the standard packet size configured on the firewall. |
DPD | This field makes it possible to configure the DPD (Dead Peer Detection) feature on VPNs, which checks whether a peer is still operational. When DPD is enabled on a peer, requests (R U there) are sent to test the availability of the other peer , which will need to acknowledge the requests in order to confirm its availability (R U there ACK). These exchanges are secured via ISAKMP (Internet Security Association and Key Management Protocol) SAs (Security Associations). If it is detected that a peer is no longer responding, the negotiated SAs will be destroyed. IMPORTANT Four choices are available for configuring DPD:
The value delay defines the period after a response is received before the next request is sent. The value retry defines the time to wait for a response before sending the request again. The value maxfail is the number of requests sent without receiving responses before the peer is considered absent. |
DSCP | In this field, you can specify the value of the DSCP field assigned to IKE network packets sent to this peer. Select one of the proposed values or specify a customized DSCP field (integer between 0 and 63 inclusive). |
Encapsulate ESP traffic in UDP | This field appears only when DR mode compatibility is enabled. In this field, ESP traffic encapsulation can be enabled/disabled in UDP for each peer to comply with ANSSI recommendations. |
NOTE
For every field that contains “Gateway” and the icon , you can add an object to the existing database by specifying its name, DNS resolution, IP address and then clicking on Apply.