Understanding the impact of DR mode

This section explains several specific characteristics of DR mode, their impact on SNS firewalls, and on the IPsec architecture in question.

Interoperability

When DR mode is enabled on an SNS firewall that complies with the ANSSI's IPsec DR recommendations, under ordinary circumstances, VPN tunnels can only be negotiated with peers (SNS firewalls, third-party devices and VPN clients) that also comply with these recommendations.

The following SNS versions comply with these recommendations:

SNS in 4.3.21 LTSB and later versions of 4.3 LTSB,
SNS in 4.8 and later versions,
SNS in 5.0 and later versions.

In SNS version 5, a configuration containing IPsec tunnels that are not compatible with DR mode can progressively transition to a configuration that is exclusively made up of DR-compliant tunnels.

Compatibility of DR modes across SNS versions

IPsec "mode"	Standard			DR			DR transition
SNS version	3.x	4.3.21 LTSB and higher	5.x	3.x	4.3.21 LTSB and higher	5.x	5.x
3.x
4.x
5.x

: Compatible only with IPsec tunnels in standard mode

NOTE
DR mode in SNS 3.x versions is not compatible with DR mode in SNS 4.x and 5.x versions. As such, a firewall in a 3.x version that needs to set up tunnels in DR mode with firewalls in 4.x or 5.x versions has to be updated to SNS version 4.3 LTSB or 4.8 in advance.

Update paths

To update a firewall to version 4.3, 4.8 or 5 from an older version, intermediate updates may be required depending on the original version:

From a 3.X version	Update to the latest 3.7.X LTSB or 3.11.X LTSB version available
From a 4.0.X version	Update to version 4.1.6
From a 4.1.6 version or higher	No intermediate updates required
From a V/VS-VU firewall	See Migrating a V/VS-VU model virtual firewall to an EVA model

Compatibility of IPsec VPN clients with DR mode

The following IPsec VPN clients can set up tunnels in DR mode with SNS firewalls:

Stormshield Network VPN Client Exclusive 7.5.109 and later versions,
TheGreenBow VPN Client Édition Enterprise 7.5.109 and later versions.

If you were previously using Stormshield Network VPN Client Standard clients, in order for DR mode to be enabled, these clients have to be uninstalled to make way for one of the compatible clients listed above.

If you were already using Stormshield Network VPN Client Exclusive, ensure that each client is in version 7.5.109 or higher, and verify that their configurations match the description in the section Creating a DR-compliant tunnel on a mobile client .

NOTE
Further on in this document, the mobile VPN client that is used will reference one of the compatible clients listed above, and will be given a generic name "DR-compliant VPN client".

Impact on the network

IPsec VPN tunnel negotiation packets and ESP packets are exchanged by default over UDP port 4500, in order to comply with ANSSI recommendations on DR mode.

If there are other security devices between the firewall to be configured in DR mode and its peers, UDP port 4500 must be allowed between the SNS firewall and its peers on these intermediate devices.

However, you can revert to the standard UDP port 500 by using the following CLI/Serverd command sequence.

CONFIG IPSEC PEER UPDATE UDPEncapPreferred=0
CONFIG IPSEC ACTIVATE

More information about the command CONFIG IPSEC PEER UPDATE

Conditions to be met for a tunnel to be compatible with DR mode

IKE and IPsec encryption profiles

IKE and IPsec encryption profiles must meet the following constraints, which have been established by IPsec DR guidelines:

The Diffie-Hellman methods used must belong to either the DH19 NIST Elliptic Curve Group (256-bit) or DH28 Brainpool Elliptic Curve Group (256-bit).
The algorithms imposed for phase 1 (Parent Security Association) and the protection of phase 2 renewals (Child Security Association) must either be:
- AES_GCM_16. As this is an AEAD (Authenticated Encryption with Associated DATA) algorithm, it is not associated with any authentication algorithm.
- Or AES_CTR, which must be associated with SHA256.

IKE protocol

Only version 2 of the IKE protocol is allowed.

Peer authentication

Only certificate-based authentication is allowed. The following constraints apply to the generation and signature of key pairs:

The size of keys used in certificates has been set at 256 bits,
ECDSA or ECSDSA signature on an ECP 256 (SECP) or BP 256 (Brainpool) curve,
SHA256 as the hash algorithm.

IMPORTANT
These constraints apply by going up the chain from the peer certificate to the first trust anchor (first CA or sub-CA) that complies with these specifications.

The Peer ID field must also be filled in, by using one of the following formats:

Distinguished Name (DN). This is the subject of the peer certificate (e.g., C=FR,ST=Nord,L=Villeneuve d'Ascq,O=Stormshield,OU=Documentation,CN=DR-Compliant-Gateway-Peer.stormshield.eu),
Subject Alternative Name (SAN). This is one of the aliases that may be defined when the peer certificate is created (e.g., DR-Compliant-Gateway-Peer.stormshield.eu). When a peer's SAN has been entered in the Peer ID field, this SAN must also be entered in the Local ID field of the peer in question.

NOTE
The possible length of a certificate's subject may cause compatibility issues with third-party devices, such as encryption mechanisms, VPN gateways, etc. that are not SNS firewalls. In this case, you are strongly advised to define a SAN when creating the peer certificate, and to use this SAN as the Peer ID.

Certificate revocation verification

A mechanism to verify Certificate Revocation Lists (CRLs) on the entire trust chain (Root CA, sub-CA and certificates) must be enabled on the firewall.

To do so, the CRL Required field of a peer that is compatible with DR mode has to be set to Auto or Mandatory. Do note that by default (standard IPsec mode), the value of this field is Auto, and when DR mode is enabled, its value becomes Mandatory.

During the transition, it has to be set to Mandatory.

In addition to certificate revocation verification, the CRLs must be present and still valid so that negotiation can function.