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 pour un modèle Route-based Any-to-Any entièrement piloté par le routage : les interfaces XFRM reçoivent des adresses de transfert, tandis que les routes statiques, dynamiques ou les SD-WAN Routes déterminent le chemin des données. Pour ce modèle, Sophos documente plusieurs passerelles XFRM avec un SD-WAN Profile et des contrôles SLA, sans groupe de basculement VPN supplémentaire. En dehors de ce modèle, Sophos avertit toutefois que plusieurs connexions Any-to-Any avec des sélecteurs identiques doivent appartenir au même groupe de basculement.

La documentation générale de dépannage impose un groupe même pour Any-to-Any, tandis que le guide SD-WAN spécifique fonctionne sans groupe. La documentation ne délimite pas explicitement cette exception. Il faut donc suivre le modèle XFRM/SD-WAN complet et le valider sur le build installé, et non omettre le groupe uniquement parce que les sélecteurs sont définis sur Any. Rendre l’IPsec Route-based redondant avec deux accès Internet explique le design complet avec deux opérateurs, des gateways XFRM distinctes, des routes statiques Primary et Backup et un test de failover contrôlé.

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.

system link_failover est un mécanisme CLI distinct

SFOS 22 publie également une commande Device Console qui ajoute un tunnel VPN ou GRE comme backup d’un Primary Link. La grammaire publiée est la suivante :

system link_failover add [primarylink] [portname] [backuplink] [vpn] [gre] [tunnel] [tunnelname] [monitor PING host] [monitor TCP host] [ipaddress] [portnumber]

Avec monitor TCP host, indiquer le port TCP à contrôler ; monitor PING host n’utilise aucun port. La cible ne doit pas seulement répondre, mais représenter utilement le chemin concerné. Un monitor réussi ne prouve pas que l’application, la règle, la route ou le chemin retour fonctionne.

Cette commande ne correspond ni au groupe de basculement IPsec configuré dans WebAdmin, ni au modèle XFRM et SD-WAN. La page publique de SFOS 22 ne documente que add : elle ne fournit aucune commande d’état, de suppression ou de retour arrière et n’explique pas l’interaction avec les routes ou stratégies SD-WAN existantes. Sans méthode de retour confirmée pour le build installé, il ne s’agit pas d’une procédure à copier-coller. Pour une nouvelle configuration, les méthodes WebAdmin ou XFRM documentées offrent un point de départ plus clair.

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. Une autre possibilité est un FQDN dont le DNS tient compte de l’état de santé ou qu’une mise à jour DDNS fait pointer uniquement vers l’adresse actuellement joignable. Si ni le pair ni la mise à jour DNS ne peuvent être contrôlés, ce modèle ne permet pas un basculement entrant fiable. Deux adresses publiées simultanément ne constituent pas un basculement 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é.

Sous Site-to-site VPN > IPsec, Active et Connection n’indiquent pas la même chose : Active indique si la connexion est activée ; Connection indique si le tunnel est établi. Une entrée active peut ne disposer d’aucun tunnel établi. Avec plusieurs Local et Remote subnets, un tunnel est créé pour chaque paire de réseaux ; un état partiellement établi ne constitue donc pas une validation complète. Activate on save ou le commutateur de la colonne Active active l’entrée. Pour plusieurs entrées sélectionnées, Activate et Deactivate sont disponibles, ainsi qu’un filtre à côté d’Active. Ces actions modifient l’état et doivent, comme le regroupement, être effectuées pendant la fenêtre de test prévue.

Pour comparer les deux membres, sélectionner Local subnet et Remote subnet sous IPsec connections > Show additional properties, puis confirmer avec OK. D’autres propriétés peuvent être affichées et les colonnes réorganisées par glisser-déposer. Logs ouvre les journaux ; Profiles > IPsec profiles > Show additional properties permet également de comparer les valeurs des profils. Clarifier avec l’administrateur du pair les paires de réseaux manquantes ou différentes avant le regroupement.

Si le firewall accepte des demandes IPsec entrantes, IPsec doit aussi être autorisé pour la zone WAN sous Administration > Device access. Cette autorisation est distincte de Ping ou SSH pour le Health Check et ne remplace pas les règles de firewall pour le trafic applicatif.

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. Sophos documente cette autorisation de zone comme prérequis. Avec des adresses de pair fixes, une Local Service ACL Exception restrictive peut être évaluée comme mesure de durcissement ; elle doit correspondre à l’adresse source réellement utilisée par le pair. Device Access et Local Service ACL expliquent la configuration.
• 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. Seules les connexions actives participent au basculement ; activer et tester séparément chaque membre prévu avant la mise en service du groupe.
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 pour recevoir les notifications d’échec de connexion. 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.

Référence API : distinguer groupe, connexion et surveillance

L’opération API combinée de SFOS 22/23 Add Failover Group IPSEC Connection / Edit IPSEC Connection ne fournit pas de payload complet pour le groupe : son exemple montre VPNIPSecConnection/Configuration et des actions sur la connexion, pas la sérialisation du groupe distinct de WebAdmin.

• La table indique Failover Group Name comme obligatoire et Failover Mail Notification comme facultatif avec y/n. L’exemple ne montre ni leur correspondance XML ni la représentation de l’appartenance au groupe, de la priorité ou d’Automatic failback. Ne pas déduire des balises XML à partir de noms de champs contenant des espaces, ni la priorité des membres à partir de l’ordre des ARRAY.
• Protocol apparaît deux fois avec des périmètres différents : pour la surveillance, comme ARRAY avec ping, tcp ou une chaîne vide (''), à côté de Port comme ARRAY de 1 à 65535 ; pour la connexion, comme SCALAR avec ALL, ICMP, UDP, TCP, à côté de LocalPort et RemotePort. Ces champs ne sont pas interchangeables. La référence n’explique ni l’appariement des arrays ni la signification de la valeur vide ; ne pas en déduire des autorisations pour le trafic applicatif ou IKE. Les règles de firewall et Device Access restent des prérequis distincts.

Les listes de valeurs diffèrent également : l’exemple de ConnectionType montre RemoteAccess/SiteToSite/HostToHost, tandis que la table ajoute TunnelInterface ; SubnetFamily montre IPv4/IPv6, tandis que la table ajoute Dual. L’absence dans l’exemple ne prouve pas une absence de prise en charge. Ne pas convertir les noms des modes GUI en tokens API supposés ; le guide IPsec Site-to-Site explique les paramètres de connexion.

Tant que le schéma du groupe pour le build installé reste incertain, gérer le groupe avec la procédure WebAdmin ci-dessus plutôt que de deviner une requête. Avant toute modification, consigner l’appartenance réelle au groupe, l’ordre, la condition de surveillance et le réglage de failback ; ensuite, vérifier le groupe enregistré et le flux de test réel. Si le résultat diffère de celui prévu, utiliser le retour arrière décrit plus bas pour rétablir l’état initial documenté.

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 utilise 3 pour Key negotiation tries. La Failover condition prend en charge la surveillance.

Après son retrait du groupe, la connexion utilise à nouveau les valeurs DPD et Key negotiation de son IPsec Profile associé. Inclure ce comportement dans le test de retour arrière, même si le profil 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. Si le groupe contient plus de deux connexions, SFOS revient à la première connexion disponible dans l’ordre Member connections.

Il est possible de désactiver et de réactiver manuellement le groupe pour relancer l’établissement de la connexion principale. Cette opération provoque une interruption de service. Vérifier d’abord les journaux, le pair, le profil, les identifiants 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. Dans la CLI, ouvrir 5. Device Management > 3. Advanced Shell ; ces commandes ne sont pas destinées à la Device Console. Les journaux peuvent contenir des réseaux internes, des adresses de pairs et des noms : les vérifier avant tout partage. Les commandes suivantes lisent uniquement l’état ou les journaux 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 et le journal d’action propre à la connexion. Les pages officielles de SFOS 22 se contredisent sur le nom du journal de surveillance : la référence générale indique ipsec_monitor.log, tandis que la page de dépannage IPsec indique strongswan-monitor.log. Ne lire que le fichier présent sur le build installé. Dans la dernière ligne, remplacer HQ-Branch-ISP1 par le véritable nom de la connexion :

tail -n 200 /log/charon.log
for log in /log/ipsec_monitor.log /log/strongswan-monitor.log; do [ -f "$log" ] && tail -n 200 "$log"; done
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. Seules les connexions actives participent au basculement. Vérifier si un membre prévu est désactivé, appartient déjà à un autre groupe, a été créé 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.

Vérifier l’ordre après un glisser-déposer

L’aide publique actuelle de SFOS 22 ne fournit aucune limite fiable de versions concernées ou corrigées pour un ordre incorrect après un glisser-déposer. Rouvrir le groupe enregistré après chaque modification et comparer son ordre à la priorité prévue.

Supprimer le groupe

La désactivation d’un groupe de basculement désactive les tunnels actifs de ses membres. Les connexions autonomes nécessaires doivent ensuite être réactivées séparément. Sophos ne documente pas les effets de la suppression du groupe lui-même. Il faut donc d’abord désactiver le groupe pendant une fenêtre de maintenance, retirer les affectations de manière contrôlée et ne pas supposer une réactivation automatique. Pour un retour arrière 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