Configurer un VPN IPsec Site-to-Site Sophos Firewall

Un VPN IPsec Site-to-Site relie deux sites, ou une Sophos Firewall et un pare-feu tiers, au moyen d’un tunnel chiffré. Dans la pratique, ce type de tunnel échoue rarement à cause d’une seule case à cocher dans l’interface. Les causes sont plus souvent des réseaux mal définis, des profils IPsec différents, des règles de pare-feu manquantes, des cas particuliers de NAT ou un chemin de retour oublié d’un côté.

Cet article explique comment mettre en place proprement un tunnel IPsec Site-to-Site sur Sophos Firewall. L’accent est mis sur la planification, la mise en œuvre et le test de recette. Si un tunnel existant est déjà vert mais qu’aucun trafic ne passe, Sophos Firewall IPsec VPN Troubleshooting est l’article complémentaire le plus adapté.

Quand cet article s’applique

Cet article convient aux liaisons de sites classiques, par exemple :

• Siège principal vers succursale
• Sophos Firewall vers Sophos Firewall
• Sophos Firewall vers pare-feu tiers
• Sophos Firewall vers passerelle cloud lorsqu’aucun assistant cloud spécifique n’est utilisé
• Migration d’anciens tunnels policy-based simples vers une configuration actuelle documentée

Il ne s’agit pas du Remote Access pour des utilisateurs individuels. Pour cela, les articles adaptés sont Configurer Sophos Connect sur Sophos Firewall, Sophos Connect ou SSL VPN : quelle solution Remote Access choisir ? et Migrer le Remote Access IPsec legacy avant SFOS 22 MR1.

IPsec policy-based ou route-based

Avant la configuration, il faut décider si le tunnel sera créé en policy-based ou en route-based. Dans les versions SFOS actuelles, ces termes sont séparés plus clairement que dans les anciens guides, qui parlent encore parfois de Site-to-Site ou de Tunnel Interface.

Pour de petites liaisons stables, le policy-based IPsec est souvent le plus rapide à comprendre. Pour des réseaux de sites plus grands ou dynamiques, le route-based IPsec est généralement plus propre, car le routage et la négociation VPN sont mieux séparés. Lorsque plusieurs réseaux, SD-WAN, BGP, OSPF ou des réseaux cloud sont impliqués, le route-based IPsec devrait être évalué en priorité.

Prérequis

Avant la mise en place, les informations suivantes devraient être documentées :

⚠️ Un VPN Site-to-Site ne devrait pas être mis en œuvre sans chemin de retour documenté. Si le pare-feu local envoie le trafic dans le tunnel mais que le pair ne connaît pas la route retour ou attend un NAT différent, le tunnel paraît souvent sain alors que les applications ne fonctionnent pas.

Planifier avant la configuration

Garder des réseaux sans ambiguïté

Les réseaux locaux et distants ne doivent pas se chevaucher involontairement. Les réseaux par défaut fréquents comme 192.168.0.0/24, 192.168.1.0/24 ou les réseaux de succursales réutilisés sont particulièrement problématiques. Si des réseaux se chevauchent, il faut un design NAT volontaire. Utiliser simplement la même plage d’adresses des deux côtés et traduire ensuite “d’une manière ou d’une autre” produit des tunnels difficiles à maintenir.

Pour de nouveaux sites, un concept d’adressage IP propre est donc utile. Si les VLANs ou les zones ne sont pas encore correctement modélisés, configurer les zones et interfaces Sophos Firewall aide.

Aligner le profil IPsec

Les deux côtés doivent utiliser des paramètres compatibles en Phase 1 et Phase 2. Cela inclut le chiffrement, l’authentification, le DH group, PFS et la durée de vie. Pour les connexions vers des pare-feux tiers, le plus simple est souvent de consigner d’abord un profil commun par écrit, puis de configurer les deux côtés.

Si un tunnel ne monte pas, NO_PROPOSAL_CHOSEN, des erreurs d’ID ou des erreurs d’authentification sont des indices typiques. L’analyse structurée se trouve dans Sophos Firewall IPsec VPN Troubleshooting.

Ne pas oublier les règles de pare-feu

Un tunnel IPsec n’autorise pas encore l’accès de production. Le trafic dans le tunnel a toujours besoin de règles de pare-feu adaptées. Pour les connexions policy-based, il s’agit le plus souvent de règles entre LAN et VPN ou entre des zones propres. Pour les designs route-based, cela dépend de la zone à laquelle l’interface XFRM ou le chemin concerné est affecté.

Lors du déploiement, Log firewall traffic devrait être activé dans les règles concernées. Sinon, l’information qui permettrait plus tard de savoir quelle règle a autorisé ou bloqué un test manque précisément. Le déroulement général est décrit dans tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Vérifier consciemment les règles créées automatiquement

Lors de la création d’une connexion IPsec Site-to-Site, l’option Create firewall rule peut aider à créer un premier jeu de règles. Elle ne remplace toutefois pas une revue de sécurité. Sophos Firewall crée ces règles en haut de la liste des règles de pare-feu. Dans les versions SFOS actuelles, des règles séparées sont créées pour le trafic entrant et sortant avec les préfixes Incoming et Outgoing.

Pour l’exploitation, il faut donc vérifier :

⚠️ Les règles de pare-feu créées automatiquement sont un point de départ, pas un design de sécurité terminé. En particulier pour des tunnels de site vers des réseaux serveurs, il faut réduire les services, sources et destinations après le premier test.

Avec un IPsec route-based et des sous-réseaux Any-to-Any, il faut travailler avec une grande rigueur. Aucune règle de pare-feu automatique ne peut être créée pour ces designs route-based. Pour les versions dual IP, les règles IPv4 et IPv6 doivent être planifiées séparément. Dans ces scénarios, les règles de pare-feu, l’interface XFRM, les routes et les tests devraient être construits manuellement et consciemment.

Configurer un IPsec policy-based

Le policy-based IPsec est la variante classique pour les liaisons Site-to-Site simples. Les réseaux locaux et distants sont définis directement dans la connexion IPsec.

1. Vérifier ou créer le profil IPsec

Menu path:

Profiles > IPsec profiles

Vérifier d’abord si un profil existant correspond au pair. Si un profil dédié est nécessaire, il devrait recevoir un nom explicite, par exemple IPsec_IKEv2_AES256_G14. Le nom doit rester compréhensible plus tard lorsque plusieurs tunnels et pairs existent.

À documenter au minimum :

• Version IKE
• Phase 1 Encryption et Authentication
• DH Group
• Phase 2 Encryption et Authentication
• PFS
• Key lifetime

Pour des pare-feux tiers, le pair devrait confirmer les mêmes valeurs par écrit. Une capture d’écran seule ne suffit souvent pas, car certains champs portent des noms différents selon le fabricant.

2. Ajouter la connexion IPsec

Menu path:

Site-to-site VPN > IPsec

Créer une nouvelle connexion IPsec et choisir Policy-based comme Connection type. Définir ensuite les données de base :

• Nom du tunnel, par exemple branch-zurich
• Local gateway ou Listening interface
• Remote Gateway sous forme d’adresse IP ou de FQDN
• Authentication type: Preshared Key ou certificat
• Local ID et Remote ID si nécessaire
• IPsec profile
• Local subnet
• Remote subnet

Pour les Preshared Keys, il faut utiliser une clé forte et unique, puis la documenter de manière sûre. Une ancienne clé standard partagée entre plusieurs sites représente un risque d’exploitation inutile.

3. Activer le tunnel

Lors de l’enregistrement, Activate on save peut être coché. En environnement de production, cela devrait se faire dans une fenêtre de maintenance définie, lorsque le pair est joignable et que les deux côtés peuvent contrôler les logs.

Après l’enregistrement, la liste affiche deux états pertinents :

• si la connexion est active
• si le tunnel est réellement established

Une entrée active n’est pas automatiquement un tunnel établi. Avec plusieurs réseaux locaux ou distants, il peut aussi y avoir plusieurs Security Associations.

Configurer un IPsec route-based

Le route-based IPsec sépare plus clairement la négociation VPN et le routage. Sophos Firewall crée alors une interface XFRM. Ensuite, des routes statiques, des SD-WAN Routes ou le routage dynamique décident quel trafic passe par le tunnel.

1. Créer la connexion en route-based

Menu path:

Site-to-site VPN > IPsec

Choisir Route-based (Tunnel interface) pour la connexion. Les paramètres de gateway, authentification, IDs et profil IPsec doivent toujours correspondre au pair. Il faut en outre comprendre quelle interface XFRM sera créée et comment elle sera routée.

Sophos affiche l’interface XFRM générée sous l’interface physique utilisée dans :

Network > Interfaces

Selon le design, l’interface XFRM a besoin d’une adresse IP. En particulier avec des designs Any-to-Any, une version dual IP ou des scénarios de routage plus complexes, l’adressage de l’interface doit être planifié proprement.

Lorsque Any-to-Any est utilisé, le Tunnel Selector ne décide plus seul quel trafic passe par le tunnel. Les routes et les règles de pare-feu deviennent alors le contrôle central. C’est flexible, mais aussi sujet aux erreurs : une règle trop large peut autoriser plus de trafic que prévu, une route manquante peut laisser le tunnel au vert sans que le trafic utile circule.

2. Définir le routage

Pour un VPN route-based, la connexion IPsec seule ne suffit pas. Il faut une route vers le réseau distant :

• route statique vers l’interface XFRM
• SD-WAN Route avec gateway ou profil adapté
• route dynamique via BGP ou OSPF si le design est prévu pour cela

Pour les configurations simples, une route statique suffit souvent. Si plusieurs liens WAN, des contrôles SLA ou des chemins de failover sont utilisés, une SD-WAN Route est plus pertinente. Le contexte général sur SD-WAN, Reply Packets et le trafic généré par le système est décrit dans vérifier le routage SD-WAN Sophos Firewall pour Reply Packets et System Traffic.

3. Tenir compte de XFRM et MTU

Les VPN route-based sont plus sensibles aux malentendus liés au routage, à MTU et à MSS. Si de petits tests fonctionnent mais que de plus gros transferts restent bloqués, il ne faut pas modifier immédiatement le profil IPsec. Il faut d’abord vérifier MTU, MSS, la fragmentation et le chemin réel. La procédure adaptée se trouve dans vérifier MTU et MSS sur Sophos Firewall en cas de problèmes VPN.

Créer les règles de pare-feu

Après la configuration IPsec, il faut des règles pour le trafic de production. Sans règles adaptées, le tunnel peut être vert mais les applications ne fonctionneront pas.

Menu path:

Rules and policies > Firewall rules

Règles typiques :

Bonnes pratiques :

• Nom de règle avec le tunnel ou le site, par exemple LAN_to_Branch_Zurich.
• Définir Source et Destination aussi strictement que possible.
• Définir les Services concrètement.
• Activer le logging pendant le déploiement et le troubleshooting.
• Vérifier la position de la règle.
• Définir les fonctions de protection consciemment au lieu de les reprendre par hasard.

Si le trafic Internet d’une succursale doit passer par le siège, il faut en plus un concept NAT et sécurité volontaire. C’est un autre design qu’une simple liaison de sites pour des réseaux internes.

Planifier NAT consciemment

NAT n’est pas interdit avec IPsec, mais il doit être clairement justifié. Les cas typiques sont les réseaux qui se chevauchent, les exigences cloud ou des tiers qui n’acceptent que certaines adresses source.

Menu path:

Rules and policies > NAT rules

Avant une règle NAT, il faut répondre à ces questions :

• Le pair attend-il des adresses IP originales ou des adresses traduites ?
• Existe-t-il des réseaux qui se chevauchent ?
• NAT est-il résolu dans la connexion IPsec ou par des règles NAT séparées ?
• Le sens retour est-il documenté ?
• Log Viewer montre-t-il après NAT la Source et la Destination attendues ?

Pour des cas particuliers policy-based avec NAT, une route IPsec sur Sophos Firewall manuelle peut devenir pertinente. Ce n’est toutefois pas une étape standard pour chaque tunnel.

Device Access et accès WAN

Pour les requêtes IPsec entrantes, le pare-feu doit pouvoir accepter le trafic IPsec sur la zone WAN appropriée. Cela ne se règle pas par une règle LAN-to-WAN normale, mais par les services locaux du pare-feu.

Menu path:

Administration > Device access

IPsec doit y être autorisé pour la zone nécessaire. En même temps, il faut vérifier si d’autres services locaux comme WebAdmin, SSH, User Portal ou VPN Portal sont accessibles trop largement. Pour le durcissement de ces services locaux, sécuriser l’accès Sophos Firewall : configurer correctement Device Access est l’article central.

Tester le tunnel

Un bon test de recette ne vérifie pas seulement l’état vert. Il vérifie le flux de données réel.

1. Vérifier le statut

Dans l’interface WebAdmin :

Site-to-site VPN > IPsec

Vérifier :

• La connexion est active.
• Le statut du tunnel est established.
• Avec plusieurs réseaux, toutes les Child SAs attendues sont établies.
• Aucun reconnect ou erreur récurrente n’est visible.

2. Vérifier Log Viewer

Menu path:

Log viewer

Générer un trafic de test avec une Source, une Destination et un Service clairs. Vérifier ensuite dans Log Viewer quelle règle de pare-feu matche et si NAT, Webfilter, IPS ou d’autres modules influencent le trafic.

3. Utiliser Packet Capture

Si Log Viewer ne suffit pas, Packet Capture devrait être utilisé avec un filtre étroit :

Diagnostics > Tools > Packet capture

Exemple de filtre :

host 172.16.10.25 and host 10.20.30.15

Lors d’un troubleshooting VPN, il est important de vérifier les deux directions. Des paquets sortants sans réponse indiquent le plus souvent un problème de chemin retour, de NAT ou de pair.

4. Utiliser la CLI seulement de manière ciblée

Pour une analyse plus profonde, l’Advanced Shell peut être utilisée via SSH :

ipsec statusall

Les points intéressants incluent notamment :

• IKE SA established
• Child SA installed
• réseaux locaux et distants
• compteurs d’octets dans les deux directions
• messages récurrents de rekey ou de disconnect

Si SSH n’est pas encore préparé, se connecter à Sophos Firewall via SSH aide.

Erreurs typiques

Checklist

Avant le changement :

• Les réseaux locaux et distants sont sans ambiguïté.
• Le choix policy-based ou route-based a été fait consciemment.
• Le profil IPsec est aligné avec le pair.
• La Preshared Key ou les certificats sont documentés de manière sûre.
• Les règles de pare-feu sont planifiées, y compris direction, position, logging et services.
• Avec Create firewall rule, les règles créées automatiquement à retravailler sont connues.
• Pour route-based Any-to-Any, les règles de pare-feu et routes manuelles sont prévues.
• NAT est soit exclu, soit documenté consciemment.
• Device Access pour IPsec a été contrôlé.
• Fenêtre de maintenance, pair et chemin de retour sont connus.

Après le changement :

• Le statut du tunnel est established.
• Log Viewer montre la règle de pare-feu attendue.
• Packet Capture montre l’aller et le retour.
• Les accès DNS internes et applicatifs ont été testés.
• Les compteurs d’octets augmentent dans les deux directions.
• NAT et chemin retour sont alignés avec le pair.
• Le changement est reporté dans la documentation réseau.

Questions fréquentes