Configurer et tester un groupe de failover IPsec sur Sophos Firewall

Un groupe de failover IPsec classe plusieurs connexions IPsec Site-to-Site par priorité. Si le tunnel principal tombe en panne, Sophos Firewall active la prochaine connexion disponible. Toutefois, pour que le basculement soit réellement utile, les deux tunnels doivent déjà fonctionner séparément et couvrir les mêmes réseaux de production, règles, exigences NAT et chemins de retour.

Procédure courte : tester séparément deux connexions IPsec, vérifier les Remote IDs et l’ordre, les réunir dans un groupe sous Site-to-site VPN > IPsec > Failover group, choisir une Failover Condition appropriée, puis valider le Failover et le Failback avec un flux de test défini.

Ce guide suppose qu’une configuration IPsec Site-to-Site existe déjà. Il explique la gestion de la redondance sans reprendre toute la création du tunnel.

Quand utiliser un groupe de failover IPsec

Le groupe convient surtout à IPsec Policy-based et à IPsec Route-based avec des Traffic Selectors précis. Plusieurs connexions ayant des Local et Remote subnets identiques doivent appartenir au même groupe de failover ou utiliser des Selectors clairement distincts. Sinon, les tunnels peuvent se perturber mutuellement.

La décision est différente avec Route-based Any-to-Any : les interfaces XFRM reçoivent des adresses de transfert et les routes statiques, dynamiques ou les SD-WAN Routes déterminent le chemin des données. Plusieurs XFRM Gateways peuvent alors être priorisées directement au moyen d’un SD-WAN Profile et de contrôles SLA. Aucun VPN Failover Group supplémentaire n’est nécessaire pour ce modèle.

Un WAN Failover normal ne remplace pas non plus le groupe. WAN link manager peut changer de connexion Internet, mais il ne crée pas une seconde connexion IPsec avec sa propre Gateway Address, sa Listening Interface et sa configuration du pair.

Un FQDN avec plusieurs adresses WAN ne constitue pas un failover

Si le même enregistrement DNS A pointe simultanément vers l’adresse WAN primaire et vers une adresse active uniquement en cas de panne, le pair distant peut sélectionner l’adresse inactive. DNS round robin ne connaît ni l’état WAN ni l’état du tunnel. Un IPsec Failover Group local ne corrige pas automatiquement ce choix DNS distant.

Pour les tunnels initiés par le pair distant, celui-ci doit donc disposer de deux connexions explicitement configurées ou d’un FQDN dont le DNS sensible à l’état ou la mise à jour DDNS pointe uniquement vers l’adresse actuellement joignable. Si ni la configuration du pair ni la mise à jour DNS ne peuvent être contrôlées, il faut arrêter la conception à ce stade. Deux adresses publiées simultanément ne doivent pas être considérées comme un failover testé.

Un VPN Failover Group est également différent d’un cluster HA. Le groupe bascule entre des tunnels, tandis que HA bascule entre deux nœuds de firewall. Dans un environnement critique, les pannes WAN, VPN et les éventuelles pannes HA doivent donc être planifiées et testées séparément.

Ce que surveille le groupe

Sophos Firewall contrôle le pair à l’aide de la Failover condition du groupe. L’intervalle provient de la valeur globale Gateway failover time-out sous :

Network > WAN link manager

La même valeur agit aussi sur la surveillance générale des WAN Gateways. Elle ne doit donc pas être modifiée uniquement pour un seul tunnel VPN. Une valeur courte réagit plus vite, mais une brève perte de paquets peut provoquer un basculement inutile. Une valeur longue tolère plus longtemps les perturbations, mais prolonge la panne avant le basculement.

Le Health Check confirme uniquement que le pair distant répond à la condition Ping ou TCP sélectionnée. Il ne prouve pas que DNS, une application métier, NAT, Routing et l’intégralité du chemin de retour fonctionnent. Ces éléments sont testés séparément après le basculement.

Préparer deux tunnels pour le groupe

L’exemple suivant relie un siège et une filiale au moyen de deux tunnels :

• Siège : 10.10.0.0/16
• Filiale : 10.20.0.0/16
• Connexion principale : HQ-Branch-ISP1
• Connexion secondaire : HQ-Branch-ISP2
• Adresse du pair principal : 198.51.100.20
• Adresse du pair secondaire : 203.0.113.20
• Remote ID commun de la filiale : 10.255.255.2
• Groupe de failover : HQ-Branch-Zurich

Les adresses 198.51.100.0/24 et 203.0.113.0/24 sont des réseaux de documentation et doivent être remplacées par les véritables adresses publiques des pairs. Les réseaux, les noms et le Remote ID sont également des exemples. Le principe est essentiel : les Gateway addresses peuvent être différentes, mais l’adresse IP du Remote ID doit être identique pour tous les membres du groupe. Sur le pair, ce Remote ID doit correspondre au Local ID concerné.

Avant de les regrouper, tester les deux connexions séparément :

1. Les deux connexions sont actives sous Site-to-site VPN > IPsec.
2. Chaque connexion peut être établie seule et transporte le même flux de test défini.
3. Les Local et Remote subnets ou Traffic Selectors sont symétriques à la configuration du pair.
4. Les règles de firewall autorisent le trafic requis dans les deux sens via la zone VPN.
5. NAT est identique sur les deux chemins et a été configuré délibérément.
6. Le pair dispose d’un chemin de retour via les deux tunnels.
7. Les Profiles correspondent au pair concerné. Les IPsec Profiles sur Sophos Firewall expliquent DPD, Rekeying et Lifetimes.
8. Un autre accès administratif et une fenêtre de maintenance sont disponibles.

⚠️ L’ajout à un groupe de failover interrompt les connexions établies. Ne pas effectuer cette modification pendant une session distante sans surveillance ni sans chemin de secours testé.

Une connexion ne peut appartenir qu’à un seul groupe de failover. Elle ne peut pas être supprimée tant qu’elle appartient à un groupe. Les connexions IPsec Remote Access ne peuvent pas servir de membres.

Choisir une Failover Condition appropriée

Sophos prend en charge Ping ou TCP avec un port défini. La condition doit être autorisée délibérément sur les deux firewalls :

• Ping : facile à vérifier, mais nécessite Ping/Ping6 pour la zone WAN sous Administration > Device access. Avec des adresses de pair fixes, une Local Service ACL Exception restrictive vaut mieux qu’une autorisation inutilement large. Device Access et Local Service ACL expliquent la configuration sûre.
• TCP 22 : nécessite SSH via la zone VPN. Il ne faut pas ouvrir SSH sur WAN à cette fin. Un service de gestion ne constitue pas un bon Health Check général s’il doit être exposé uniquement pour la surveillance.
• Autre port TCP : nécessite des règles de firewall entrantes et sortantes appropriées. Le service doit rester disponible et ne pas dépendre uniquement de l’état d’une application quelconque.

La condition doit représenter un service de réponse ou un chemin stable du pair distant. Si le service utilisé pour TCP ne répond plus en raison d’une maintenance, d’une panne locale ou d’un Host Firewall, le groupe peut basculer alors que le chemin IPsec lui-même reste disponible.

Configurer le groupe de failover IPsec

Le chemin de menu est le suivant :

Site-to-site VPN > IPsec > Failover group > Add

1. Saisir un Name unique, HQ-Branch-Zurich dans cet exemple.
2. Sous Member connections, sélectionner au moins deux connexions IPsec Site-to-Site actives.
3. Placer les connexions dans l’ordre souhaité : d’abord HQ-Branch-ISP1, puis HQ-Branch-ISP2. La première connexion est le tunnel principal.
4. Activer Mail notification si un changement de tunnel doit être signalé par e-mail. Les Notification settings et notifications VPN doivent déjà fonctionner.
5. Activer Automatic failback si le groupe doit revenir au tunnel préféré après son rétablissement.
6. Définir une Failover condition appropriée avec Ping ou TCP et un port.
7. Enregistrer avec Save.
8. Activer le commutateur d’état du groupe. Ce n’est qu’alors que le groupe devient actif et tente d’établir la connexion principale.

Lorsque deux Sophos Firewalls sont concernés, vérifier des deux côtés les propriétés des connexions, l’ordre des membres, les Remote IDs et les autorisations du Health Check. Un groupe correct d’un seul côté ne remplace pas une configuration cohérente sur le pair.

Effet sur DPD et Key negotiation tries

Dès qu’une connexion devient membre du groupe, SFOS désactive Dead Peer Detection pour cette connexion et définit effectivement Key negotiation tries sur 3. La Failover Condition prend en charge la surveillance. Les valeurs de la vue du Profile ne représentent donc pas à elles seules tout le comportement effectif.

Après son retrait du groupe, la connexion utilise à nouveau les valeurs DPD et Key-negotiation de son IPsec Profile associé. C’est important lors du Rollback : un tunnel peut se comporter différemment après la suppression du groupe, même si le Profile lui-même n’a pas été modifié.

Tester Failover et Failback de manière contrôlée

Avant le test de panne, définir un flux de données précis, par exemple :

• Source : 10.10.10.25
• Destination : 10.20.20.15
• Service : TCP 443
• Règle de firewall attendue : HQ-to-Branch-HTTPS

Effectuer ensuite le test dans un ordre clair :

1. Documenter l’état du groupe, l’ordre des membres, le Firmware Build et Gateway failover time-out.
2. Vérifier le tunnel principal des deux côtés dans WebAdmin. Confirmer avec un véritable trafic HTTPS que les chemins aller et retour fonctionnent.
3. Enregistrer l’état dans l’Advanced Shell avec ipsec statusall.
4. Pendant la fenêtre de maintenance, interrompre de manière contrôlée le chemin WAN ou Upstream principal. Ne pas désactiver tout le Failover Group, car cela désactive tous les tunnels actifs du groupe.
5. Observer pendant une durée supérieure au Gateway failover time-out configuré et noter l’heure du basculement.
6. Vérifier que HQ-Branch-ISP2 s’établit et que le même test HTTPS fonctionne dans les deux sens.
7. Contrôler la règle de firewall, NAT, le chemin de retour et le fonctionnement de l’application. Un tunnel vert ne constitue pas à lui seul un critère de réussite.
8. Rétablir le chemin principal et observer Automatic failback.
9. Après le retour, refaire le même test et documenter l’interruption réellement mesurée.

Les sessions TCP existantes peuvent être interrompues lors du changement. Le nouveau tunnel utilise d’autres Security Associations et peut passer par une autre adresse publique. L’application doit donc souvent établir une nouvelle session. Le Failover IPsec améliore la disponibilité, mais ne garantit pas une session sans interruption.

Automatic failback s’arrête après cinq tentatives infructueuses

Lorsque le pair principal redevient accessible, SFOS tente jusqu’à cinq fois de rétablir la connexion préférée si Automatic failback est activé. En cas d’échec, le tunnel secondaire reste actif. Le firewall ne continue pas à contrôler indéfiniment le tunnel principal ; un nouveau retour n’a lieu que si le chemin secondaire tombe en panne.

Il est possible de désactiver et de réactiver manuellement le groupe pour déclencher une nouvelle tentative d’établissement de la connexion principale. Cette opération provoque toutefois une interruption de service et ne constitue pas un simple bouton de rafraîchissement. Vérifier d’abord les Logs, le pair, le Profile, les IDs et le chemin.

Consulter les Logs sans modifier la configuration

dgd.log est important pour la décision du groupe, tandis que strongswan.log couvre l’établissement IPsec lui-même. Les commandes suivantes s’exécutent dans l’Advanced Shell et ne modifient pas la configuration :

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

Si nécessaire, ajouter charon.log, ipsec_monitor.log et l’Action Log propre à la connexion. Dans la dernière ligne, remplacer HQ-Branch-ISP1 par le véritable nom de la connexion :

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Comparer les horodatages de dgd.log, l’état IPsec, l’événement WAN et le test applicatif. Un Health Check qui échoue sans erreur correspondante du tunnel ou de l’application ne prouve pas encore une panne du fournisseur. Le chemin de diagnostic complet se trouve dans Troubleshooting IPsec VPN sur Sophos Firewall.

Erreurs fréquentes et retour sûr

Le groupe ne s’active pas correctement

Au moins deux connexions doivent être sélectionnées et actives. Vérifier si une connexion appartient déjà à un autre groupe, a été créée comme Remote Access ou utilise un Remote ID différent. Tester ensuite à nouveau les deux tunnels séparément avant de réactiver le groupe.

Le tunnel secondaire est vert, mais le trafic échoue

La logique du groupe a probablement fonctionné, mais pas le chemin des données. Vérifier les règles de firewall, NAT, les Local et Remote subnets, les routes automatiques ou manuelles ainsi que le chemin de retour sur le pair. Le tunnel secondaire doit pouvoir transporter le même flux de test de production que le tunnel principal.

Le groupe bascule trop tôt ou trop tard

Vérifier ensemble la Failover Condition et Gateway failover time-out. Une cible Ping ou TCP instable peut provoquer des changements inutiles. Un Timeout global long retarde également d’autres contrôles de Gateway qui en dépendent. Ne pas modifier uniquement la valeur numérique, mais documenter la cause, la perte de paquets et la durée réelle du basculement.

L’ordre est incorrect après un Drag-and-drop

Sophos confirme le défaut NC-178121 dans SFOS 22.0 GA : après une modification par Drag-and-drop, les connexions IPsec Site-to-Site pouvaient se retrouver à une position incorrecte dans le Failover Group. Ce défaut précis est corrigé dans SFOS 22.0 MR2 Build 546.

Dans SFOS 22.0 GA, documenter l’ordre avant et après chaque modification et ne pas se fier uniquement au déplacement visuel. La Release Note publique n’indique pas de limite distincte et sans ambiguïté concernant l’impact ou le correctif pour MR1. Si un défaut similaire apparaît dans MR2 Build 546 ou une version ultérieure, il ne doit pas continuer à être attribué automatiquement à NC-178121.

Supprimer le groupe

La désactivation d’un Failover Group désactive les tunnels actifs de ses membres. Les connexions autonomes nécessaires doivent ensuite être réactivées séparément. Pour un Rollback contrôlé :

1. Consigner l’état initial, l’ordre des membres et les Profiles utilisés.
2. Confirmer la fenêtre de maintenance et un autre accès administratif.
3. Désactiver le groupe et documenter l’interruption.
4. Retirer les connexions du groupe ou rétablir l’affectation d’origine.
5. Activer la connexion autonome nécessaire.
6. Prendre à nouveau en compte le comportement DPD et Key-negotiation du Profile.
7. Vérifier le même flux de test, les Logs et le chemin de retour.

Exploitation

• Retester Failover et Failback après toute modification de Firmware, de fournisseur, de pair, de Routing, de NAT ou de Profile.
• Documenter l’ordre des membres, les Remote IDs, les Profiles, la condition du Health Check et le Timeout global.
• Utiliser Mail notification uniquement comme alerte ; la validation technique exige toujours l’état, les Logs et du trafic réel.
• Inclure les deux tunnels dans le Monitoring, le plan de maintenance et la documentation du pair.
• Vérifier que le fournisseur secondaire respecte les mêmes Allowlists, dépendances NAT et accessibilités publiques.
• Ne désactiver et réactiver manuellement le groupe qu’avec une interruption planifiée.

FAQ