Configurer et vérifier un groupe de connexions SD-WAN dans Sophos Central

Un groupe de connexions SD-WAN permet à Sophos Central de créer des connexions IPsec basées sur les routes entre plusieurs pare-feu administrés. Cela évite de répéter une grande partie de la configuration dans les topologies hub-and-spoke ou full mesh. Central peut générer les tunnels, les interfaces XFRM, les routes, les objets réseau et, si l’option est sélectionnée, les règles de pare-feu correspondantes.

L’automatisation ne remplace pas la planification du réseau ni la validation. Un état vert du groupe confirme surtout que les pare-feu participants sont actifs. Il ne prouve pas qu’un client donné peut atteindre la destination distante au moyen de la règle, de la route et du traitement NAT attendus.

Chemin rapide vers un groupe de connexions fonctionnel

Vérifier la licence Central Orchestration, l’administration depuis Central et l’appartenance au groupe de pare-feu pour chaque équipement.
Documenter les réseaux locaux, les adresses WAN, les conditions NAT, la redondance et la topologie prévue.
S’assurer que les pools d’adresses XFRM ne chevauchent aucun réseau de production.
Créer un groupe sous My Products > Firewall Management > SD-WAN Connection Groups.
Sélectionner les pare-feu, les ressources partagées, les services et, éventuellement, la création automatique des règles de pare-feu.
Résoudre individuellement chaque conflit de réseau et de WAN détecté par Central.
Surveiller Tasks Queue et l’état du groupe jusqu’à ce que tous les pare-feu participants aient été traités.
Contrôler les tunnels, les objets Central_, les adresses XFRM, les routes et les règles sur chaque pare-feu.
Générer un trafic bidirectionnel réel et vérifier Firewall Rule ID, la route, le NAT et le chemin retour.
Ajouter d’autres ressources ou pare-feu uniquement après validation du premier périmètre.

⚠️ Ne pas supprimer sans préparation un groupe de connexions actif ni désinscrire un pare-feu de Central pendant l’exploitation normale. Lors de la désinscription, Sophos Central supprime le groupe de connexions associé et ses tunnels générés automatiquement. Une telle modification nécessite une sauvegarde récente, une fenêtre de maintenance et un chemin de retour documenté.

Ce que Central crée automatiquement

Un groupe de connexions SD-WAN utilise un VPN IPsec basé sur les routes. Selon la topologie, Sophos Central crée les connexions et les objets de configuration nécessaires sur les pare-feu membres. Les objets générés automatiquement portent des noms commençant par Central_ dans la configuration locale. Il s’agit notamment de connexions IPsec, d’interfaces XFRM, d’objets réseau et de routes.

Dans une topologie hub-and-spoke, les ressources partagées se trouvent derrière le pare-feu hub. Le hub répond comme passerelle distante aux tunnels initiés par les spokes. Cela convient, par exemple, à un siège disposant de réseaux de serveurs et de plusieurs succursales.

Dans une topologie full mesh, Central connecte chaque pare-feu à tous les autres membres du groupe. Cette solution peut raccourcir les chemins directs entre sites, mais elle crée beaucoup plus de tunnels et de dépendances. Il faut donc d’abord déterminer si chaque site a réellement besoin de communiquer directement avec tous les autres.

L’option de création automatique des règles de pare-feu est pratique, mais elle ne remplace pas le contrôle des sources, destinations et services autorisés. Si elle n’est pas sélectionnée, les règles nécessaires doivent exister localement ou dans la stratégie de groupe Central correspondante. Si elle est sélectionnée, l’ordre, le périmètre et la journalisation des règles générées doivent tout de même être vérifiés. Les principes sont détaillés dans Planifier et créer des règles de pare-feu sur Sophos Firewall.

Planifier la topologie et les valeurs d’exemple

Le groupe de connexions d’exemple suivant relie trois pare-feu :

FW-HQ partage le réseau de serveurs 10.10.0.0/16.
FW-BE partage le réseau de la succursale 10.20.0.0/16.
FW-ZH partage le réseau de la succursale 10.30.0.0/16.
Au départ, seuls HTTPS et RDP vers certains systèmes du réseau de serveurs sont nécessaires.
L’exemple utilise une topologie hub-and-spoke avec FW-HQ comme hub.

Ces noms et réseaux sont uniquement des valeurs de documentation. Ils doivent être remplacés par les noms réels des pare-feu, les ressources locales et les services. La planification ne porte pas seulement sur les chevauchements directs entre les trois sites. Les réseaux distants de cloud, de partenaires, de clients VPN, RED et d’administration doivent également être comparés aux ressources et pools XFRM prévus.

Comprendre les pools d’adresses XFRM

Central utilise des réseaux /30 pour les interfaces XFRM. Si aucun pool personnalisé n’est configuré, Sophos Central utilise par défaut 10.252.0.0/15 et 10.254.0.0/16. Si l’une de ces plages existe déjà dans l’environnement, il faut choisir un pool personnalisé libre avant de créer le premier groupe.

Le réglage se trouve sous :

My Products > Firewall Management > SD-WAN Connection Groups > Add IP Pool

Un changement de pool affecte uniquement les nouveaux groupes de connexions. Les groupes existants conservent les adresses XFRM qui leur ont été attribuées. Le changement de pool ne constitue donc pas une réparation rétroactive pour un groupe en production.

Conditions requises avant la création

Tous les pare-feu participants doivent être administrés depuis Central et disposer de la licence Central Orchestration appropriée. Ils doivent également appartenir au préalable à un groupe de pare-feu dans Sophos Central. Un pare-feu uniquement enregistré, mais non affecté à un groupe de pare-feu Central, n’est pas disponible comme prévu pour le groupe de connexions.

Avant la création, les points suivants sont également vérifiés :

adresse IP publique ou FQDN accessible pour chaque chemin WAN
NAT en amont et rôle d’initiateur ou de répondeur qui en résulte
ressources locales uniques et sans chevauchement
réseaux XFRM disponibles
liens WAN actifs et passerelles de secours prévues
services autorisés entre les sites
configurations locales IPsec, de routage, NAT et SD-WAN existantes
accès d’administration indépendant et sauvegarde récente de la configuration

Configurer un VPN IPsec site à site sur Sophos Firewall explique la structure d’une connexion individuelle basée sur les routes. Central exécute plusieurs de ces étapes dans un groupe de connexions, mais les conditions sous-jacentes de routage, de règles et de chemin retour restent identiques.

Créer le groupe de connexions dans Sophos Central

Sélectionner les pare-feu et les ressources

Le processus commence ici :

My Products > Firewall Management > SD-WAN Connection Groups > Create Connection Group

Le groupe reçoit d’abord un nom sans ambiguïté, par exemple HQ-Branches. Les pare-feu participants et la topologie sont ensuite sélectionnés. Pour chaque pare-feu, les réseaux locaux ou les hôtes qui seront accessibles aux autres sites sont définis comme Shared resources.

Les ressources doivent être choisies aussi précisément que possible. Au lieu de partager l’ensemble du réseau du siège, un réseau de serveurs ou d’applications suffit souvent. De même, il ne faut pas sélectionner Any par précaution si seules quelques applications sont nécessaires.

Central peut éventuellement créer des règles de pare-feu. Les options couvrent également les utilisateurs authentifiés et Security Heartbeat. Avant l’enregistrement, il convient de documenter si les règles sont générées automatiquement ou administrées séparément. Il reste ainsi clair par la suite si une règle manquante est une erreur ou une décision de conception.

Résoudre les conflits de réseau et de WAN

Central recherche les conflits dans les ressources et les connexions WAN sélectionnées. Un conflit ne signifie pas automatiquement qu’un réseau est incorrect. Il indique que Central ne peut pas générer une connexion sans ambiguïté sans décision supplémentaire.

Selon le résultat, les décisions possibles comprennent notamment :

désactiver un sous-réseau qui se chevauche pour cette connexion
associer une adresse NAT unique au sous-réseau
définir un objet réseau supplémentaire
sélectionner le lien WAN approprié
sélectionner une passerelle de secours
remplacer l’adresse détectée par Central

Chaque décision modifie le chemin de données final. Les adresses NAT, les remplacements WAN et les réseaux désactivés sont donc consignés dans un plan d’adressage et de routage, et ne sont pas simplement configurés jusqu’à ce que l’état devienne vert.

Un caractère générique * comme adresse publique ou FQDN convient uniquement au côté passerelle distante qui agit comme répondeur. Il ne doit pas servir à masquer une situation WAN ou NAT non résolue. L’initiateur, le DNS, l’accessibilité publique et l’identité du pair doivent rester sans ambiguïté.

Enregistrer le groupe et surveiller les tâches

Après l’enregistrement, Central crée les tâches nécessaires pour tous les pare-feu participants. La session d’administration existante reste ouverte sur au moins un pare-feu pendant l’opération. Dans Central, l’état et les détails du groupe de connexions sont contrôlés, ainsi que :

My Products > Firewall Management > Tasks Queue

Les états Pending, Failed ou Partial Success ne doivent pas être simplement ignorés. Le pare-feu, l’entité, l’erreur et l’heure sont consignés, puis comparés à la configuration locale. Vérifier Sophos Central Firewall Tasks Queue explique en détail Retry, Skip, Force Sync et la validation locale.

Vérifier localement la configuration générée

Après la réussite d’une tâche Central, chaque pare-feu participant est ouvert séparément afin de vérifier les points suivants :

Les connexions Central attendues sont actives sous Site-to-site VPN > IPsec.
Les interfaces XFRM possèdent des adresses /30 uniques du pool prévu sous Network > Interfaces.
Les routes générées pointent vers l’interface XFRM attendue sous Routing.
Les objets réseau, hôte et service dont le nom commence par Central_ correspondent aux ressources partagées.
Les règles de pare-feu créées automatiquement ou séparément autorisent uniquement les sources, destinations et services prévus.
Le NAT ne s’applique que là où il a été choisi intentionnellement pour résoudre un conflit.
Avec plusieurs chemins WAN, l’état des passerelles et du SD-WAN correspond à la sélection primaire et de secours prévue.

Central administre les objets générés. Les modifications locales manuelles des objets Central_ peuvent être remplacées lors d’une modification ultérieure du groupe ou provoquer des incohérences. Les changements doivent donc être effectués dans la conception du groupe de connexions ou dans la stratégie Central correspondante.

Valider avec du trafic réel

Pour la première validation, au moins un test réel est effectué pour chaque chemin de ressource partagée. Dans l’exemple, un client de 10.20.0.0/16 se connecte en HTTPS à un serveur explicitement autorisé dans 10.10.0.0/16, puis le test est répété depuis 10.30.0.0/16.

Les éléments suivants sont contrôlés des deux côtés :

les SA IKE et Child actives
la bonne Firewall Rule ID
les interfaces d’entrée et de sortie dans Packet Capture
les adresses source et de destination attendues après toute traduction NAT volontaire
le chemin aller et le chemin retour
le résultat applicatif, et pas seulement un ping

Un tunnel ou un état de groupe vert n’est qu’un résultat intermédiaire. Tester une règle Sophos Firewall explique la validation complète avec Log Viewer, Policy Test et Packet Capture.

Ajouter des profils SD-WAN et de la résilience

Central peut utiliser des profils SD-WAN pour les groupes de connexions lorsque les pare-feu et les interfaces XFRM remplissent les conditions requises. Un profil définit comment plusieurs passerelles sont évaluées et utilisées. Il ne remplace ni une route correcte ni une connexion VPN individuelle fonctionnelle.

Chaque chemin WAN et chaque tunnel est testé séparément avant l’activation d’un profil. Du trafic réel permet ensuite de vérifier que les nouvelles connexions utilisent le chemin primaire prévu et basculent vers le chemin de secours lors d’une panne planifiée. Les health checks doivent viser un système qui représente réellement le chemin de bout en bout nécessaire.

La logique de routage locale, les valeurs SLA et la validation du basculement sont décrites dans Configurer une route SD-WAN sur Sophos Firewall. Central simplifie la distribution, mais ne change pas la signification de la passerelle, de route precedence, du NAT ni du comportement des sessions.

Résoudre les problèmes selon le symptôme

Impossible de sélectionner un pare-feu

Vérifier l’enregistrement dans Central, la licence valide ou l’autorisation Orchestration et l’appartenance à un groupe de pare-feu Central. Déterminer ensuite si une tâche de groupe ou de synchronisation en attente bloque la modification.

Une tâche a échoué ou n’a réussi que partiellement

Ne pas recréer immédiatement le groupe. Il faut d’abord conserver les détails de la tâche et la configuration locale partielle. Les causes fréquentes sont des conflits d’objets ou de réseaux, des pare-feu injoignables, des restrictions de licence ou une stratégie de groupe qui n’a pas pu être appliquée intégralement. La tâche n’est répétée qu’après correction de la cause.

Le tunnel est actif, mais le trafic applicatif manque

Comparer les ressources partagées, la sélection des services et la règle de pare-feu avec le flux réel. Contrôler ensuite la route, l’interface XFRM, le NAT, route precedence et le chemin retour. Un ping n’est pertinent que si ICMP est autorisé et si la cible doit y répondre.

Un seul chemin WAN ou de secours fonctionne

Vérifier l’adresse publique ou le FQDN, le NAT en amont, le rôle de la passerelle, le lien WAN et la passerelle de secours. Pour un profil SD-WAN, poursuivre avec la cible SLA et l’état de la passerelle. Une adresse générique ou un tunnel vert ne doit pas masquer une absence d’accessibilité de bout en bout.

Une modification du pool n’apparaît pas dans le groupe

Ce comportement est normal pour les groupes de connexions existants. Les nouveaux pools d’adresses IP ne sont utilisés que par les groupes créés ultérieurement. Il ne faut pas supprimer et recréer un groupe de production uniquement pour modifier l’adressage ; l’impact, l’interruption de service et le retour arrière doivent d’abord être planifiés.

Central affiche un état vert, mais l’application reste indisponible

L’état du groupe n’est pas interprété comme une surveillance applicative. Les journaux, Rule IDs, Packet Capture, le routage et le NAT sont vérifiés simultanément sur les deux pare-feu. En cas de HA ou de traitement distribué, il faut utiliser le nœud qui a traité le trafic de test.

Effectuer les modifications et le retour arrière en toute sécurité

Avant toute modification importante du groupe, il convient de consigner la configuration du groupe de connexions, les pare-feu membres, les ressources partagées, l’affectation WAN, le pool XFRM, les règles générées automatiquement et un flux de test fonctionnel. Une sauvegarde récente du pare-feu est également conservée.

Si une extension échoue, l’ensemble du groupe n’est pas supprimé par réflexe. Seule la ressource, le pare-feu ou la modification de profil nouvellement ajouté est d’abord retiré, puis la redistribution complète de la configuration précédente par Central est vérifiée. Les tests locaux des tunnels, routes, règles et flux sont ensuite répétés.

Si le groupe de connexions doit être entièrement supprimé, l’opération a lieu pendant une fenêtre de maintenance. Des chemins alternatifs entre les sites ou des tunnels administrés manuellement doivent être prêts au préalable. Après la suppression, chaque pare-feu est contrôlé pour vérifier que les objets Central_ associés ont disparu et qu’aucune règle, route ou dépendance NAT orpheline ne subsiste.

Liste de contrôle pour la mise en production

Tous les pare-feu sont administrés depuis Central, disposent d’une licence et sont affectés à un groupe de pare-feu.
Les ressources, les services, les chemins WAN et les réseaux XFRM sont documentés et sans chevauchement.
Chaque conflit détecté a été résolu de manière volontaire.
Toutes les tâches Central se sont terminées avec un résultat documenté.
Les tunnels, interfaces XFRM, routes, règles et objets Central_ ont été vérifiés localement.
Un test applicatif bidirectionnel réel fonctionne pour chaque chemin entre sites.
Les chemins primaire et de secours ont été testés pendant une fenêtre de maintenance.
La sauvegarde, l’accès d’administration et le chemin de récupération sont documentés.

Questions fréquentes

Un groupe de connexions remplace-t-il les connaissances locales en matière d’IPsec et de routage ?

Non. Central automatise la création répétitive, mais le chemin de données reste un VPN IPsec basé sur les routes avec des interfaces XFRM, des routes, des règles de pare-feu et éventuellement du NAT. Ces couches doivent toujours être comprises pour le dépannage et la validation.

Que prouve un état vert dans Sophos Central ?

Il indique que les pare-feu participants sont actifs ou que l’état global du groupe semble sain. Il ne prouve pas que chaque ressource est accessible au moyen de chaque règle et application. Des contrôles locaux et de véritables connexions de test restent nécessaires.

Que se passe-t-il lors de la désinscription d’un pare-feu ?

Sophos Central supprime le groupe de connexions associé et les tunnels qu’il a créés. Un pare-feu ne doit donc pas être désinscrit puis réinscrit comme mesure de dépannage habituelle. Cette modification doit être effectuée pendant une fenêtre de maintenance, avec une sauvegarde et un chemin de remplacement préparé.