Configurer un Tunnel VPN IPSec entre Pare-feux de Constructeurs Différents : Guide et Pièges à Éviter

Connecter des réseaux d'entreprise via un tunnel VPN IPSec est une pratique courante pour assurer une communication sécurisée. Idéalement, on utiliserait des équipements du même constructeur pour simplifier la configuration. Cependant, dans le monde réel, il est fréquent de devoir établir des connexions entre des appareils provenant de fournisseurs différents. Est-ce possible ? Oui. Est-ce toujours simple ? Pas nécessairement. Cet article explore les défis et les clés du succès pour configurer un tunnel IPSec site-à-site entre des constructeurs variés.

La Réalité des Tunnels Multi-Constructeurs

Les sources montrent que la configuration de tunnels IPSec site-à-site entre des pare-feux de constructeurs différents est réalisable. Des exemples existent entre Palo Alto Networks et Cisco, et des utilisateurs partagent leurs expériences avec des équipements de diverses marques comme Juniper, Cisco, Meraki, Palo Alto, et Fortigate.

Cependant, un constat récurrent est que cette tâche est souvent perçue comme plus complexe ou pénible qu'une configuration entre appareils du même constructeur. La difficulté principale ne réside généralement pas dans le matériel lui-même, mais dans la nécessité de faire en sorte que tous les paramètres correspondent exactement sur les deux extrémités du tunnel.

L'Importance Cruciale de la Correspondance des Paramètres

Un tunnel IPSec est établi en deux phases principales : la Phase 1 (IKE) et la Phase 2 (IPsec). Pour qu'une connexion s'établisse entre deux appareils différents, chaque paramètre configurable dans ces deux phases doit être identique sur les deux équipements.

Voici les éléments clés à synchroniser méticuleusement :

Phase 1 : Établir le Canal Sécurisé pour les Clés (IKE - Internet Key Exchange)

La Phase 1, gérée par le protocole IKE, a pour objectif de sécuriser l'échange des clés qui seront utilisées pour chiffrer les données réelles dans la Phase 2. Elle établit une Association de Sécurité IKE (IKE SA). Les paramètres critiques incluent :

• Méthode d'authentification : Comment les deux appareils se prouvent-ils leur identité ? La méthode la plus courante est l'utilisation de clés pré-partagées (PSK - Pre-Shared Key). Les identités des homologues (locales et distantes) doivent également correspondre.
• Groupe Diffie-Hellman (DH) : Utilisé pour l'échange sécurisé des clés. Un groupe DH spécifique doit être choisi et configuré de manière identique sur les deux côtés. Par exemple, group2 est mentionné dans un exemple Juniper.
• Algorithme d'authentification : Utilisé pour l'intégrité et l'authentification des messages IKE. Des algorithmes comme sha1 ou md5 sont couramment utilisés. Ce paramètre doit être identique.
• Algorithme de chiffrement : Utilisé pour chiffrer les messages IKE. Des algorithmes comme 3des-cbc ou aes-256-cbc sont des choix typiques. Ce paramètre doit être identique.
• Mode : IKEv1 peut utiliser le Mode Principal (Main Mode) ou le Mode Agressif (Aggressive Mode). Le Mode Principal utilise six messages pour établir la SA IKE et est considéré comme plus sécurisé car le hachage n'est pas envoyé en clair. Le Mode Agressif utilise seulement trois messages mais présente un risque de sécurité car le hachage est envoyé en clair, permettant potentiellement la récupération de la PSK si les messages sont capturés. Le Mode Principal est généralement préféré et doit être configuré de manière identique. Un exemple Juniper montre la configuration en Mode Agressif.
• Adresse IP de passerelle distante : L'adresse publique de l'homologue distant doit être correctement spécifiée.
• Interfaces externes : Les interfaces réseau connectées à Internet qui enverront ou recevront les paquets IKE doivent être correctement définies.

Phase 2 : Sécuriser le Trafic de Données (IPsec)

Une fois que la Phase 1 a établi un canal sécurisé et échangé les clés, la Phase 2 négocie les paramètres pour sécuriser le trafic de données réel qui traversera le tunnel. Elle établit des Associations de Sécurité IPsec (IPsec SAs). Les paramètres essentiels à faire correspondre sont :

• Protocole : IPSec peut utiliser AH (Authentication Header) pour l'authentification et l'intégrité, ou ESP (Encapsulating Security Payload) pour l'authentification, l'intégrité et le chiffrement. ESP est le plus courant pour les VPNs. Ce protocole doit être le même des deux côtés.
• Algorithme d'authentification : Utilisé pour authentifier les paquets de données IPsec (même avec ESP). Des exemples incluent hmac-sha1-96 ou HMAC-MD5-96.
• Algorithme de chiffrement : Utilisé pour chiffrer les paquets de données IPsec (avec ESP). 3des-cbc ou aes-256-cbc sont des options courantes.
• Perfect Forward Secrecy (PFS) : Une option de sécurité qui garantit que la compromission d'une clé de Phase 1 ne compromettra pas les clés futures de Phase 2. Si PFS est activé sur un appareil, il doit l'être sur l'autre, et le Groupe Diffie-Hellman utilisé pour PFS doit également correspondre. group1 ou group2 sont des exemples de groupes DH pour PFS.

NAT-Traversal (NAT-T) et Identifiants Proxy (Proxy IDs)

Deux autres points de configuration importants, souvent sources d'erreurs :

• NAT-Traversal (NAT-T) : Si l'un des appareils (ou les deux) est derrière un équipement effectuant de la traduction d'adresses réseau (NAT), NAT-T est indispensable. Il permet d'encapsuler le trafic IKE et ESP dans des paquets UDP, généralement sur le port 4500, pour traverser le périphérique NAT. Cette fonctionnalité doit être prise en charge et activée des deux côtés si nécessaire. Des messages "keepalive" sont nécessaires avec NAT-T pour maintenir les traductions NAT actives. NAT-T est activé par défaut sur les appareils Juniper, sauf si désactivé explicitement.
• Identifiants Proxy (Proxy IDs) ou Sélecteurs de Trafic : Ces paramètres définissent quels flux de trafic (combinaisons d'adresses IP source, destination et service) sont autorisés à traverser le tunnel IPsec. Pour que le tunnel monte et fonctionne correctement, les identifiants proxy configurés de chaque côté doivent correspondre exactement, mais de manière inversée (par exemple, l'ID de proxy local de l'initiateur doit correspondre à l'ID de proxy distant du répondeur, et vice-versa). Une non-correspondance des identifiants proxy est une cause très fréquente d'échec de la Phase 2. Dans le cas des VPN basés sur les stratégies, ils définissent le trafic qui déclenche le tunnel.

Stratégies de Sécurité et Routage

Même si le tunnel est établi, le trafic ne passera pas automatiquement. Des stratégies de sécurité (firewall policies) sont nécessaires pour autoriser le flux de trafic entre les réseaux locaux via l'interface de tunnel. La configuration de ces stratégies doit refléter le trafic que vous souhaitez autoriser à traverser le VPN. Pour les VPN basés sur le routage, des routes statiques (ou dynamiques) pointant vers l'interface de tunnel (par exemple, une interface st0 sur Juniper) sont requises pour diriger le trafic destiné au réseau distant vers le tunnel.

Pourquoi c'est un "Pain" (Douleur) ?

La difficulté réside souvent dans les petites différences de mise en œuvre ou de nomenclature entre les constructeurs. Ce qui est appelé "Proxy ID" chez l'un peut être désigné différemment chez l'autre. Les options peuvent être cachées ou structurées différemment dans l'interface graphique ou la ligne de commande. Un manque de compréhension approfondie des mécanismes IKE et IPsec, ainsi que des spécificités de chaque équipement, est une cause fréquente de problèmes.

Bonnes Pratiques et Dépannage

Pour augmenter vos chances de succès :

• Documentez ! Échangez une feuille de calcul simple listant tous les paramètres de Phase 1 et Phase 2 (méthodes d'authentification, algorithmes, groupes DH, clés PSK, identifiants, sous-réseaux locaux/distants, services, etc.) avec l'autre partie et assurez-vous que tout est listé et configuré de manière identique.
• Accédez aux Logs : Avoir accès aux logs de sécurité ou aux outils de débogage sur les deux pare-feux est essentiel pour identifier la cause d'un échec de négociation. Les logs (kmd logs sur Juniper, par exemple) et les commandes pour vérifier l'état des associations de sécurité (show security ike security-associations, show security ipsec security-associations sur Juniper) sont vos meilleurs alliés pour le dépannage.
• Vérifiez les Bases : Assurez-vous que la connectivité réseau de base est établie et que les ports UDP 500 (pour IKE) et 4500 (pour NAT-T si utilisé) sont ouverts entre les deux passerelles. Vérifiez que les interfaces de tunnel (par exemple, st0 sur Juniper) sont correctement liées au VPN.
• Comprenez IKE et IPsec : Une solide compréhension des phases de négociation IKE et des protocoles IPsec est fondamentale pour diagnostiquer les problèmes lorsque les logs indiquent un échec.

Conclusion

Configurer un tunnel VPN IPSec entre des constructeurs différents n'est pas une tâche impossible, mais elle exige de la rigueur et une attention méticuleuse aux détails. La clé du succès réside dans la correspondance parfaite de tous les paramètres de Phase 1 et Phase 2, une bonne communication avec l'administrateur de l'autre côté, et une capacité à dépanner en utilisant les logs et les outils disponibles sur les équipements. En suivant ces principes, vous pouvez surmonter les défis liés aux différences de syntaxe ou d'implémentation et établir une connexion sécurisée fonctionnelle entre vos réseaux.

Amadou Lamine DIOUF
Expert consultant formateur et auditeur de systèmes d'information

www.truetechnologie.com

lamine.diouf@truetechnologie.com

+221778562766