Assessing the impact of enabling DR mode

Carefully read the next section to assess the impact of enabling DR mode on an SNS firewall, and on the entire architecture.

Interoperability

When DR mode is enabled on a firewall in an SNS version that complies with the ANSSI's IPsec DR recommendations, VPN tunnels can only be negotiated with peers that also comply with these recommendations. This implies that all IPsec DR-compatible peers in the architecture (SNSfirewalls, third-party devices and VPN clients) must comply with the ANSSI's IPsec DR recommendations.

For example, firewalls in an SNS version that complies with these recommendations, and on which DR mode is enabled:

  • Can set up VPN tunnels in DR mode with peers (SNS firewalls, third-party devices and VPN clients) that comply with the ANSSI's IPsec DR recommendations,

  • Cannot set up VPN tunnels:

    • With any peers that do not comply with these recommendations, even if DR mode is enabled on them. This includes SNS versions that are not mentioned below,

    • With any peers in standard IPsec mode.

SNS versions that comply with the ANSSI's IPsec DR recommendations

  • SNS in 4.3.21 LTSB and higher versions of 4.3 LTSB,

  • SNS in 4.7 and higher versions.

Compatibility of Stormshield IPsec VPN clients with DR mode

Only SN VPN Client Exclusive 7.4.018 (and higher versions) can set up VPN tunnels in DR mode with firewalls in an SNS version that complies with the ANSSI's IPsec DR recommendations.

If you are using Stormshield standard VPN clients, enabling DR mode requires it to be uninstalled to make way for SN VPN Client Exclusive (a specific license must be purchased).

Impact on the network

IPsec VPN tunnel negotiation packets and ESP packets are exchanged exclusively over UDP port 4500.

If the firewall that will be configured in DR mode is separated from its peer by other security devices, UDP port 4500 must be allowed on these devices between the SNS firewall and its peer.

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 of key pairs and signatures:

  • 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 to the entire trust chain, i.e., beginning from the peer certificate up 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=Lille,O=Stormshield,OU=Doc,CN=DR-Firewall),
  • Subject Alternative Name (SAN). This is one of the aliases that may be defined when the peer certificate is created (e.g., DR-Firewall.stormshield.eu).

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.

The CRLrequired configuration token must be set to 1 or auto in the firewall's VPN policy configuration in order for this mechanism to be enabled.

In addition to certificate revocation verification, the CRL must be present and valid at all times so that negotiation can function.

Hardware

On SN-S-Series-220, SN-S-Series-320, SN510, N-M-Series-520, SN710, SN-M-Series-720, SN910, SN-M-Series-920, SN1100, SN2000, SN2100, SN3000, SN3100, SN6000, SN6100, SNi20, SNi40 and SNxr1200 firewalls, DR mode allows the use of the coprocessor's cryptographic hardware instruction sets. "AES-NI" instructions are exempt as they are made up of only “simple acceleration instructions” of certain cryptographic operations.

On SN160, SN160W, SN210, SN210W, and SN310 firewalls, DR mode will force such instruction sets to be disabled, causing performance to slow down during encryption.