Comprendre l'impact du mode DR

Cette section permet de comprendre quelques spécificités du mode DR et leur impact sur un firewall SNS ainsi que sur l'architecture IPsec concernée.

Interopérabilité

Lorsque le mode DR est activé sur un firewall SNS respectant les recommandations IPsec DR de l'ANSSI, la négociation de tunnels VPN n'est normalement possible qu'avec des correspondants (firewalls SNS, équipements tiers et clients VPN) respectant également ces recommandations.

Les versions SNS respectant ces recommandations sont :

SNS 4.3.21 LTSB et versions 4.3 LTSB supérieures,
SNS 4.8 et versions supérieures.
SNS 5.0 et versions supérieures.

La version 5 de SNS permet de passer progressivement d'une configuration comportant des tunnels IPsec non-compatibles avec le mode DR à une configuration exclusivement composée de tunnels compatibles avec le mode DR.

Compatibilité des modes DR entre versions SNS

"Mode" IPsec	Standard			DR			Transition DR
Version SNS	3.x	4.3.21 LTSB et supérieure	5.x	3.x	4.3.21 LTSB et supérieure	5.x	5.x
3.x
4.x
5.x

: Compatible uniquement avec les tunnels IPsec en mode standard

NOTE
Le mode DR des versions 3.x de SNS n'est pas compatible avec le mode DR des versions 4.x et 5.x de SNS. Un firewall en version 3.x devant établir des tunnels en mode DR avec des firewalls en version 4.x ou 5.x doit donc être préalablement mis à jour en version SNS 4.3 LTSB ou 4.8.

Chemins de mise à jour

Pour mettre à jour un firewall en version 4.3, 4.8 ou 5 depuis une version antérieure, des mises à jour intermédiaires peuvent être nécessaires selon la version d'origine :

Depuis une version 3.X	Mettre à jour vers la dernière version 3.7.X LTSB ou 3.11.X LTSB disponible
Depuis une version 4.0.X	Mettre à jour en version 4.1.6
Depuis une version 4.1.6 ou supérieure	Aucune mise à jour intermédiaire requise
Depuis un firewall V / VS-VU	Voir Migrer un firewall virtuel modèle V / VS-VU vers un modèle EVA

Compatibilité des clients VPN IPsec avec le mode DR

Les clients VPN IPSec pouvant établir un tunnel en mode DR avec des firewalls SNS sont les suivants :

Stormshield Network VPN Client Exclusive 7.5.109 et versions supérieures,
TheGreenBow VPN Client Édition Enterprise 7.5.109 et versions supérieures.

Si vous utilisiez des clients Stormshield Network VPN Client Standard, l'activation du mode DR nécessite de désinstaller ces clients au profit de l'un des clients compatibles listés ci-dessus.

Si vous utilisiez déjà Stormshield Network VPN Client Exclusive, assurez-vous que chaque client est en version 7.5.109 ou supérieure et vérifiez leur configuration comme décrit dans la section Créer un tunnel compatible avec le mode DR sur un client mobile.

NOTE
Dans la suite de ce document, le client VPN mobile utilisé fera référence à l'un des deux clients compatibles cités ci-dessus et sera nommé de manière générique "client VPN compatible mode DR".

Impacts réseau

Les paquets de négociation du tunnel VPN IPsec ainsi que les paquets ESP sont échangés par défaut sur le port UDP/4500 pour respecter les recommandations de l'ANSSI sur le mode DR.

Si d'autres équipements de sécurité sont situés entre le firewall à paramétrer en mode DR et ses correspondants, vous devez donc autoriser le port UDP/4500 entre le firewall SNS et ses correspondants sur ces équipements intermédiaires.

Vous pouvez cependant revenir au port standard UDP/500 à l'aide de la séquence de commandes CLI / Serverd suivante :

CONFIG IPSEC PEER UPDATE UDPEncapPreferred=0
CONFIG IPSEC ACTIVATE

Plus d'informations sur la commande CONFIG IPSEC PEER UPDATE

Conditions à remplir pour qu'un tunnel soit compatible avec le mode DR

Profils de chiffrement IKE et IPsec

Les profils de chiffrement IKE et IPsec doivent obligatoirement répondre aux contraintes suivantes, établies par le référentiel IPsec DR :

Les méthodes Diffie-Hellman utilisées doivent obligatoirement appartenir aux groupes DH19 NIST Elliptic Curve Group (256-bits) ou DH28 Brainpool Elliptic Curve Group (256-bits).
Les algorithmes imposés pour la phase 1 (Parent Security Association) et la protection des renouvellements de phase 2 (Child Security Association) doivent être :
- Soit AES_GCM_16. Il s'agit d'un algorithme de type AEAD (Authenticated Encryption with Associated DATA) et il n'est donc associé à aucun algorithme d'authentification.
- Soit AES_CTR, impérativement associé à l'algorithme d'authentification SHA256.

Protocole IKE

Seule la version 2 du protocole IKE est autorisée.

Authentification des correspondants

Seule l'authentification par certificat est autorisée. Les contraintes de génération et de signature des bi-clés sont les suivantes :

Taille des clés utilisées dans les certificats fixée à 256 bits,
Signature ECDSA ou ECSDSA sur courbe ECP 256 (SECP) ou BP 256 (BRAINPOOL),
SHA256 comme algorithme de hachage.

IMPORTANT
Ces contraintes s'appliquent en remontant depuis le certificat du correspondant jusqu'au premier Trust Anchor (première CA ou sous-CA) respectant ces spécifications.

De plus, le champ ID du correspondant doit être obligatoirement renseigné en respectant l'un des deux formats suivants :

Distinguished Name (DN). Il s'agit du sujet du certificat du correspondant (exemple : C=FR,ST=Nord,L=Villeneuve d'Ascq,O=Stormshield,OU=Documentation,CN=DR-Compliant-Gateway-Peer.stormshield.eu),
Subject Alternative Name (SAN). Il s'agit d'un des alias éventuellement définis lors de la création du certificat du correspondant (exemple : I). Lorsque le champ ID du correspondant est renseigné avec le SAN d'un correspondant, vous devez également renseigner ce SAN dans le champ Local ID du correspondant concerné.

NOTE
La longueur possible d'un sujet de certificat peut poser des problèmes de compatibilité avec des matériels tiers comme les chiffreurs, passerelles VPN... autres que les firewalls SNS. Il est dans ce cas fortement conseillé de définir un SAN lors de la création du certificat du correspondant et d'utiliser ce SAN comme ID de correspondant.

Vérification de révocation des certificats

Un mécanisme de vérification des Certificate Revocation Lists (CRL) de l'ensemble de la chaîne de confiance (CA racine [Root CA], sous-CA et certificats) doit être actif sur le firewall.

Pour ce faire, le champ CRL Required d'un correspondant compatible avec le mode DR doit être positionné sur la valeur Auto ou Obligatoire. Notez que par défaut (mode IPsec standard), ce champ prend la valeur Auto et que lorsque le mode DR est activé, il prend la valeur Obligatoire.

Durant la phase de transition, il doit être positionné sur à la valeur Obligatoire.

En plus de la vérification de révocation des certificats, les CRL doivent être présentes et toujours valides pour que la négociation soit fonctionnelle.