Configurer la Haute Disponibilité (HA) sur Sophos Firewall

La Haute Disponibilité, ou HA, relie deux Sophos Firewalls en cluster. Dans la plupart des environnements, Active-Passive avec QuickHA constitue le meilleur choix : un firewall traite le trafic, tandis que le second prend le relais en cas de panne ou de maintenance. Avant de commencer, vérifier que les deux appareils, les builds du firmware, les licences, le câblage et l’accès d’administration respectent les prérequis HA.

Cet article couvre le choix du mode HA, la configuration, le test de failover, l’exploitation et le RMA. HA ne remplace ni une conception réseau propre ni les sauvegardes.

Choisir le mode HA et l’architecture

Recommandation opérationnelle d’Avanet : dans la plupart des environnements de production, Active-Passive est la meilleure variante HA. Un firewall traite tout le trafic et le second reste prêt à prendre le relais en cas de panne ou de maintenance. La conception est plus simple, les licences coûtent moins cher et le comportement en cas de panne est plus facile à comprendre. Il s’agit d’une recommandation de conception, et non d’une exigence de Sophos.

Active-Active ne se justifie que si ses limites sont acceptées en connaissance de cause. Il ne s’agit pas d’un load balancing symétrique classique où les deux firewalls occupent une position équivalente partout dans le réseau. Le Primary Firewall continue de recevoir le trafic et distribue certaines connexions à l’Auxiliary Firewall. Tous les services et types de trafic ne sont pas distribués.

Orientation rapide :

• Stabilité maximale et exploitation simple : Active-Passive.
• Utilisation du second firewall sans licences de protection séparées : Active-Passive.
• Besoin de débit supplémentaire pour certaines connexions TCP : Évaluer Active-Active.
• Nombreux cas VPN, proxy, RED, NDR ou particuliers : Préférer Active-Passive.
• Environnement petit ou moyen sans problème de performances clair : Active-Passive.
• Exigence de performances claire et licences adaptées pour les deux appliances : Active-Active après test.

Les deux Sophos Techvids présentent visuellement la configuration et les changements de rôle :

Ce que signifie la Haute Disponibilité

Un cluster HA Sophos Firewall se compose de deux firewalls. Les appareils échangent des heartbeats, l’état des appareils, les informations de connexion et les données de configuration via un lien HA dédié. La configuration est synchronisée du Primary Firewall vers l’Auxiliary Firewall.

HA protège contre les pannes courantes :

• Panne du Primary Firewall
• Panne électrique ou matérielle
• Panne d’une interface surveillée
• Problème logiciel ou de service empêchant un appareil de fonctionner
• Mises à jour planifiées du firmware
• Changement de rôle planifié pendant la maintenance

HA ne résout toutefois pas tous les problèmes :

• Un ensemble de règles incorrect reste incorrect dans le cluster.
• La panne d’un switch commun peut toucher les deux firewalls simultanément.
• Une conception VLAN défaillante ou un routing incorrect ne sont pas corrigés automatiquement.
• Les logs et rapports ne sont pas synchronisés entre les deux firewalls.
• Une sauvegarde reste obligatoire.

Avant de planifier HA, les principes des zones, interfaces, VLANs, LAGs et bridges doivent être clarifiés. Voir Planifier et configurer les zones et interfaces Sophos Firewall.

Active-Passive ou Active-Active

Active-Passive

Avec Active-Passive, un firewall traite tout le trafic de production. Le second reste passif et ne prend le relais que si le firewall actif tombe en panne ou si un failover est déclenché manuellement ou par une opération de maintenance.

Caractéristiques habituelles :

• Le Primary Firewall traite le trafic.
• L’Auxiliary Firewall reste en standby.
• Les sessions sont synchronisées si le service concerné le permet.
• Pour les appliances matérielles, seul l’appareil titulaire de la licence requiert les abonnements de protection.
• Lorsque la MAC virtuelle du cluster est utilisée, l’Auxiliary Firewall prend le relais avec la même adresse MAC virtuelle lors d’un failover.
• Dans ce cas, les équipements réseau ne doivent généralement pas réapprendre leurs voisins.

Active-Passive est généralement le meilleur choix pour les entreprises, succursales, centres de données et environnements où la stabilité est plus importante qu’un éventuel gain de performances.

Active-Active

Avec Active-Active, les deux firewalls traitent du trafic. L’architecture reste néanmoins asymétrique : le Primary Firewall reçoit le trafic et décide de traiter une connexion ou de la transférer à l’Auxiliary Firewall.

Sophos utilise l’adresse IP source pour la distribution : les connexions TCP éligibles provenant d’adresses IP source paires sont traitées par le Primary, tandis que celles provenant d’adresses impaires sont envoyées à l’Auxiliary. Le trafic TCP transféré et les connexions TCP traduites sont distribués, y compris le trafic SNAT et Virtual Host, également via des interfaces VLAN. Après avoir traité une connexion, l’Auxiliary envoie les paquets directement à la destination sans repasser par le Primary. Cette méthode paire-impaire est fixe et ne peut pas être modifiée. La prise en charge de Layer 7 varie selon le service : selon Sophos, DPI Engine, les proxys transparents, directs et parents, ainsi que le trafic du proxy SMTP et HTTPS sont éligibles au load balancing. FTP analysé et H.323 ne le sont pas. Sont également exclus le trafic non-TCP tel que UDP, ICMP, multicast et broadcast, SD-RED, ainsi que le trafic TCP et non-TCP tunnelisé, y compris VPN. Les load balancers externes ne sont pas pris en charge pour HA.

Les deux nœuds nécessitent des licences adaptées et enregistrent localement les logs du trafic qu’ils traitent. Active-Active n’est donc pertinent qu’avec un objectif de performances clair et si le trafic concerné bénéficie effectivement de la distribution. Pour la seule haute disponibilité, Active-Passive est généralement préférable.

Rôles, état et failover

Rôles dans le cluster HA

• Primary : Appareil qui maintient la configuration centrale du cluster. Dans les deux modes HA, le Primary reçoit le trafic.
• Auxiliary : Second appareil du cluster. Il synchronise sa configuration depuis le Primary et prend le relais si nécessaire.
• Initial primary : Appareil démarré comme Primary lors de la configuration. En Active-Passive, il est généralement aussi titulaire de la licence. Cette propriété demeure, que le nœud soit actuellement Active ou Passive.
• Preferred primary : Appareil préféré qui doit redevenir Primary après un failover dès qu’il est de nouveau disponible de manière stable.

En mode Active-Passive, WebAdmin sur l’Auxiliary n’affiche pas les Live users, les DHCP leases ni les connexions IPsec actives. Il s’agit du comportement attendu et non de la preuve d’un échec de synchronisation. Le Primary actuellement actif fait foi pour ces données d’exécution.

Valeurs d’état pendant l’exploitation

• Active : L’appareil traite du trafic.
• Passive : L’appareil est prêt, mais ne traite pas de trafic de production en Active-Passive.
• Standalone : L’appareil ne voit pas son peer ou HA n’est pas entièrement actif. Les deux appareils peuvent passer en Standalone lors d’une panne du lien HA.
• Faulty : L’appareil n’est pas suffisamment sain pour participer normalement au cluster.

Adresse MAC virtuelle

Lorsque la MAC virtuelle du cluster est utilisée, SFOS attribue des adresses MAC virtuelles aux interfaces physiques, à l’exception du Dedicated HA Link et des ports d’administration. Le Dedicated HA Link utilise sa propre adresse MAC physique. Seul le Primary répond aux requêtes ARP du cluster. Lors d’un failover, l’Auxiliary reprend l’adresse MAC virtuelle de chaque interface de production concernée. La connectivité reste ainsi plus stable pour les commutateurs, routeurs et clients, car l’association IP-MAC ne change pas fondamentalement. L’option MAC d’interface décrite ci-dessous est une autre variante ; ne pas lui attribuer le même comportement de reprise de la MAC virtuelle.

Le Cluster ID est important, car il sert à générer l’adresse MAC virtuelle. Si plusieurs clusters HA fonctionnent dans le même environnement Layer 2, chacun doit utiliser un Cluster ID unique. Sinon, des conflits MAC peuvent se produire.

Éléments synchronisés

• Règles de firewall, policies, objets, routing et configuration CLI sont synchronisés du Primary vers l’Auxiliary.
• Sessions actives sont synchronisées selon le protocole et le service. En Active-Active, les deux appareils échangent avec leur peer l’état et les détails des sessions actives ; la synchronisation de la configuration reste en revanche dirigée du Primary vers l’Auxiliary.
• Secure Storage Master Key et identifiants WebAdmin sont synchronisés.
• Le Dedicated HA link et les ports d’administration sont explicitement exclus de la synchronisation selon la documentation officielle des modes et rôles HA. Les instructions officielles sur l’adressage d’administration se contredisent toutefois, comme expliqué sous Prérequis réseau.
• Logs et rapports ne sont pas synchronisés entre les appareils.

Comportement du failover

En Active-Passive, l’Auxiliary reprend tout le trafic si le Primary tombe en panne. En Active-Active, en revanche, la panne de l’un des deux appareils actifs peut déclencher la reprise par le peer sain. Si l’Auxiliary tombe en panne, le Primary traite seul tout le trafic ; cela ne constitue pas nécessairement un changement de rôle. Lorsqu’un peer devient indisponible, l’appareil restant fonctionne en Standalone. Cet état ne prouve donc pas à lui seul une panne du lien HA affectant les deux appareils ; vérifier les rôles et l’accessibilité des deux nœuds avant d’appliquer le runbook split-brain.

Plusieurs événements peuvent déclencher un failover :

• Absence de heartbeats sur le lien HA
• Panne d’un port surveillé
• Panne électrique
• Panne matérielle
• Problème logiciel ou de service
• Changement de rôle planifié
• Mise à jour du firmware

Si un seul Node démarre en mode Failsafe, consigner d’abord son rôle et l’état du peer. Vérifier un Sophos Firewall en mode Failsafe présente la procédure de diagnostic sûre et explique pourquoi il ne faut ni redémarrer les deux Nodes sans coordination ni désactiver HA sur la base d’une simple supposition.

Les heartbeats sur le Dedicated HA Link sont des requêtes VRRP. SFOS 22 utilise par défaut 250 ms et 16 heartbeats manquants, soit un timeout de heartbeat de 4 secondes. SFOS 23 utilise par défaut 100 ms et 3 tentatives, soit 300 ms ; les liens HA basés sur un LAG exigent d’autres valeurs, comme expliqué ci-dessous. Ces timeouts ne garantissent pas le délai de rétablissement du trafic. Pour les Monitored Ports, la panne d’un seul port suffit en revanche pour considérer l’appareil comme indisponible et déclencher le failover.

Indications divergentes sur les heartbeats pour SFOS 23 : La description générale du failover indique toujours 250 ms et 16 tentatives, tandis que les instructions détaillées de configuration de SFOS 23 indiquent 100 ms et 3 tentatives. Les valeurs par défaut SFOS 23 sont à contrôler sur le build utilisé avant toute modification. Avant toute modification sous System services > High availability, documenter les valeurs réellement configurées et la topologie du lien HA sur les deux nœuds. Ni l’ancienne indication ni la valeur par défaut plus courte de la configuration ne justifient de modifier un cluster existant sans vérification ; si les valeurs sont incertaines ou ne respectent pas l’exigence LAG, clarifier la planification avec Sophos Support.

Après le failover, WebAdmin sur l’ancien Auxiliary Firewall affiche la configuration du Primary. Les limites varient selon les sessions actives :

Lorsque l’Initial Primary revient, il reste Auxiliary dans le cluster si Preferred primary n’est pas sélectionné. S’il est défini comme Preferred primary, SFOS synchronise d’abord les services puis effectue automatiquement le retour. L’appareil qui fonctionnait seul jusque-là redémarre pendant cette opération. Ce failback doit donc être planifié dans une fenêtre de maintenance. Les changements de rôle et les redémarrages décrits ne garantissent pas le traitement sans interruption des connexions existantes.

Services pris en charge et limités

Sophos HA prend en charge la plupart des services du firewall, mais leurs limites d’exploitation diffèrent nettement :

Si le reporting ou la conservation des logs sont importants, planifier rapidement l’utilisation d’un serveur syslog externe ou de Sophos Central Firewall Reporting. Voir Activer Central Firewall Reporting.

Pour la configuration, les limites de sécurité et les tests, utiliser Configurer le mDNS reflector. La découverte de services n’autorise pas l’accès aux applications ; la prise en charge HA ne garantit pas des sessions applicatives sans interruption. Cette affirmation sur mDNS concerne SFOS 23, pas SFOS 22.

Prérequis et conception réseau

Avant la mise en œuvre, vérifier soigneusement les prérequis HA par rapport à l’environnement. De petites différences de modèle, firmware, interfaces, Cellular WAN ou plateformes virtuelles peuvent avoir des conséquences importantes.

Compatibilité du matériel et des modèles

• Modèle d’appliance : Les deux firewalls doivent être du même modèle XGS Appliance, par exemple XGS 2100 avec XGS 2100.
• Révision matérielle : Des révisions matérielles différentes sont possibles avec le même modèle XGS Appliance.
• Modèles XGS Appliance Wi-Fi : Non pris en charge. Par exemple XGS 126w et XGS 136w.
• Flexi Port Modules : Si des modules d’extension sont utilisés, leur nombre et leur modèle doivent être identiques sur les deux appareils.
• Firmware : Les deux appareils doivent exécuter la même version SFOS, y compris le Maintenance Release et le build.
• Matériel plus appliance virtuelle : Impossible de former une paire HA.

Important : Les modules Flexi Port ne sont pas remplaçables à chaud. Pour en ajouter, arrêter proprement les deux pare-feu, installer le même modèle de module sur les deux appareils, puis redémarrer les deux appareils. Configurer ensuite les nouveaux Flexi Ports uniquement sur le Primary actuel sous Network > Interfaces. SFOS synchronise cette configuration de ports sur l’Auxiliary. Ne pas modifier un seul nœud pendant le fonctionnement du cluster.

SFOS 22 ne prend plus en charge le matériel XG ou SG Series. Avant une migration vers SFOS 22, ces appareils doivent être remplacés par une XGS Appliance compatible ou une plateforme virtuelle adaptée.

Appliances virtuelles et logicielles

Les appliances virtuelles et logicielles doivent également correspondre précisément. Microsoft Hyper-V, VMware et Nutanix Prism sont des exemples de plateformes virtuelles ; les appliances logicielles fonctionnent sur du matériel de votre choix, sous réserve des exigences de compatibilité de Sophos. La mention d’une plateforme ne dispense pas de vérifier les exigences HA suivantes.

• Plateforme : Même type d’appliance et même plateforme SFOS.
• Hypervisor : Même type d’hypervisor.
• Ressources : Ressources matérielles allouées identiques, notamment le même nombre de cœurs CPU, ainsi que le même nombre d’interfaces réseau.
• Firmware : Même version SFOS, y compris le build.
• Adresses MAC : Dans les environnements virtuels, l’option d’adresses MAC attribuées par l’hypervisor peut éviter le Promiscuous Mode. La modification de cette option provoque une interruption de service.

Si le cluster utilise l’adresse MAC virtuelle générée par SFOS, la plateforme de virtualisation doit accepter les changements de MAC. Dans VMware ESXi, définir MAC Address Changes et Forged Transmits sur Accept au niveau du vSwitch ou du port group ; les port groups doivent hériter des valeurs du vSwitch ou être configurés en conséquence. Dans Hyper-V, activer Enable MAC address spoofing sur tous les adaptateurs réseau virtuels des deux firewalls, sauf celui du Dedicated HA Link. Il est aussi possible de sélectionner Use host or hypervisor-assigned MAC address dans SFOS 22 ou Use interface MAC address dans SFOS 23 ; pour les appliances virtuelles, les deux utilisent la MAC attribuée par l’hypervisor, et ces modifications de plateforme ne sont alors pas nécessaires. L’option SFOS 23 utilise aussi la MAC d’interface sur les appliances matérielles au lieu de la MAC virtuelle du cluster. L’activer ou la désactiver met à jour la configuration des interfaces et provoque une interruption de service.

Déploiements cloud

Les environnements cloud imposent des exigences de plateforme supplémentaires. Routing, interfaces virtuelles, adresses IP, Security Groups, UDRs et mécanismes de failover spécifiques au cloud doivent correspondre à l’architecture concernée. L’approche HA habituelle des appliances ne peut pas être transposée sans vérification à Azure, AWS ou d’autres clouds.

Avant de planifier HA pour un Sophos Firewall dans le cloud, consulter la documentation Sophos actuelle de la plateforme et l’architecture du réseau cloud.

Gateway, Bridge et Discover/TAP

HA est disponible en modes gateway et bridge. Le mode Discover ou TAP prend uniquement en charge Active-Passive. Si au moins un nœud fonctionne en mode discover, aucun cluster Active-Active ne peut être créé. Une interface TAP active bloque également la configuration Active-Passive. Désactiver l’interface TAP sur les deux firewalls via la CLI, établir HA, puis réactiver TAP séparément sur chaque nœud. TAP reste actif sur l’Auxiliary passif.

Licences et enregistrement

Les licences HA varient selon la plateforme et le mode HA. Trois questions sont décisives : s’agit-il de matériel ou de Virtual/Software ? Le mode utilisé est-il Active-Passive ou Active-Active ? Quel appareil est l’Initial Primary et donc titulaire de la licence du cluster ? Avant la mise en œuvre, comparer ces points avec l’état des licences, les numéros de série et le mode cible.

Principaux éléments de licence :

• Base Firewall : HA nécessite une licence Base Firewall. Les appliances matérielles l’incluent par défaut, mais elle prend fin lorsque l’appareil atteint sa fin de vie. La licence Base Firewall n’expire pas sur les appliances cloud, virtuelles et logicielles, mais elle doit être présente pour HA.
• Matériel Active-Passive : Seul l’Initial Primary a besoin des abonnements de production. L’Auxiliary Firewall reçoit une copie des abonnements et peut traiter le trafic après un failover.
• Matériel Active-Active : Les deux firewalls ont besoin de leurs propres licences compatibles. Les types de licence doivent correspondre, mais les dates d’expiration peuvent différer.
• Active-Passive Virtual/Software : Seul le Primary a besoin des licences requises, y compris Base Firewall.
• Active-Active Virtual/Software : Les deux appareils ont besoin de leur propre licence Base Firewall et des licences de protection supplémentaires adaptées.
• Enregistrement matériel : Les deux appareils matériels doivent être revendiqués dans Sophos Fusion (anciennement Sophos Central) avant la configuration HA et pouvoir synchroniser leurs licences.
• Enregistrement Virtual/Software Active-Passive : Selon Sophos, seul le Primary est revendiqué en Active-Passive Virtual/Software.
• Sophos Central Management : La synchronisation des licences et la revendication ne signifient pas automatiquement que les firewalls peuvent être administrés via Sophos Central Firewall Management. Un abonnement supplémentaire adapté est nécessaire.
• RMA et support : Advance Hardware Replacement nécessite Enhanced Plus Support sur le Primary d’un cluster matériel Active-Passive. En Active-Active, chaque appareil nécessite Enhanced Support ou Enhanced Plus Support.

Administrer la paire HA dans Sophos Fusion

Une paire HA peut être connectée à des commutateurs de la couche d’accès, notamment des Sophos Switches. Sophos Fusion, anciennement Sophos Central, permet l’administration centralisée des firewalls et des Sophos Switches. Cela ne remplace pas une conception redondante des commutateurs : un commutateur partagé peut toujours affecter les deux nœuds. L’ancienne présentation de SFOS 23 utilise encore le nom Sophos Central ; cela n’implique pas une architecture HA différente.

Une paire HA déjà constituée est administrée dans Sophos Fusion comme une seule paire, et non comme deux firewalls indépendants. Les deux nœuds doivent utiliser la même version de firmware et, pour Central Management, disposer d’un accès Internet IPv4 fonctionnel et de l’abonnement approprié. Le claiming et la synchronisation des licences ne suffisent pas à activer l’administration.

Lorsque deux firewalls déjà administrés séparément dans Sophos Fusion sont réunis en paire HA, Sophos recommande de désenregistrer d’abord les deux appareils. Établir HA localement, enregistrer à nouveau la paire complète pour Central Management, puis la déplacer dans un autre groupe Central si nécessaire.

Sur le Primary actuel, ouvrir System > Sophos Central et sélectionner Register both HA devices. Activer ensuite Central Management puis, dans Sophos Fusion sous My Products > Firewall Management > Firewalls, ouvrir Approval Pending pour le Primary et confirmer accept-services. Après quelques minutes, la paire doit apparaître une seule fois avec l’icône HA ; les modifications depuis Sophos Fusion s’appliquent alors aux deux firewalls.

Le statut Central ne remplace pas la validation locale. Après l’enregistrement, vérifier localement les rôles HA, la synchronisation, le statut des licences et une comparaison de configuration sans impact. Si deux entrées indépendantes apparaissent ou si Approval Pending persiste, ne pas désenregistrer l’un des firewalls par précaution. Comparer d’abord les numéros de série, le tenant Central, le chemin IPv4 et le statut HA local.

L’Initial Primary est particulièrement important en Active-Passive, car cet appareil détient la licence du cluster. La vue HA indique quel appareil détient cette licence. Le documenter sans ambiguïté dans le manuel d’exploitation.

Licence sur le mauvais firewall – Active-Passive uniquement : Si les abonnements Active-Passive ont été attribués par erreur à l’Auxiliary plutôt qu’à l’Initial Primary détenteur des licences, une synchronisation ne suffit pas. Avant toute modification, documenter le numéro de série source de l’Auxiliary licencié par erreur et le numéro de série cible prévu de l’Initial Primary, indépendamment des rôles HA actuels, puis les vérifier dans SFOS et Sophos Fusion. Cette procédure de correction abrégée s’applique uniquement si le Primary actuel et l’Initial Primary sont le même appareil physique. S’il s’agit d’appareils différents ou si leur identification est incertaine, arrêter avant toute désactivation de HA ou tout transfert de licence et clarifier la procédure adaptée à l’aide des instructions Sophos ou avec Sophos Support ; ne pas improviser un retour aux rôles précédents. Uniquement lorsque l’identification est sans ambiguïté, désactiver HA de manière planifiée sur le Primary actuel, transférer les abonnements dans Sophos Fusion du numéro de série source documenté vers le numéro de série cible documenté de l’Initial Primary, puis reconfigurer le cluster Active-Passive. Les transferts de licences concernent aussi les RMA ou changements de modèle, mais nécessitent la procédure adaptée au cas précis. Les modèles HA devant être identiques, les deux appareils doivent être remplacés lors d’un changement de modèle. En Active-Active, l’Auxiliary doit également détenir ses propres licences. Ce n’est pas une erreur à corriger par ce transfert. Ne pas réutiliser cette procédure Active-Passive pour un RMA Active-Active sans instructions Sophos applicables.

Des licences Active-Active expirées ou non synchronisées peuvent arrêter le load balancing et désactiver HA. Pour les appliances matérielles et Virtual/Software, Sophos décrit le début de cet arrêt de manière contradictoire : le résumé le situe à la fin de trois jours, les détails dans les trois premiers jours, suivis de la désactivation HA. Le début exact reste indéterminé ; aucun délai de grâce de trois jours n’est garanti. Corriger rapidement les problèmes de licences et, si nécessaire, convenir avec Sophos Support d’un plan d’exploitation sûr pour le build installé. Lors de la configuration initiale, Active-Active n’est pas activé si les licences ne correspondent pas.

En Active-Passive, synchroniser les licences du Primary. L’Initial Primary détenteur des licences doit les synchroniser au moins une fois tous les 90 jours. Sur les appliances matérielles, les abonnements de protection concernés s’arrêtent sinon, tandis que Base Firewall et Enhanced Support restent actifs. Sur Virtual/Software, la licence Base Firewall est désactivée, HA s’arrête et d’autres fonctions de protection deviennent inactives. Les clusters licenciés en ligne ont donc besoin de DNS, d’une heure système correcte, de routing et d’un accès Internet aux services de licences Sophos. Les clusters isolés utilisent à la place le processus manuel documenté de licence Air-Gap.

En Active-Active, sur les appliances matérielles et Virtual/Software, synchroniser individuellement les licences des deux appareils avec Sophos Fusion et vérifier la réussite sur le Primary et l’Auxiliary. Des types de licences identiques et la possession des licences ne remplacent pas cette étape. Sur le matériel, Base Firewall et Enhanced Support restent actifs lors des problèmes de licences décrits ; sur Virtual/Software, la désactivation de Base Firewall désactive HA et rend les autres licences inactives. Ne pas utiliser l’indication non résolue de trois jours comme intervalle de synchronisation.

Documenter au minimum :

• Quel appareil est l’Initial Primary
• Quels numéros de série ou appliance IDs appartiennent au cluster
• Quelles licences sont actives sur chaque appareil
• Quand les licences ont été synchronisées avec succès pour la dernière fois ; en Active-Active, noter séparément le statut et l’heure des deux nœuds
• Quel niveau de support est disponible pour RMA ou Advance Replacement
• Qui valide les changements de licence, renouvellements et processus RMA

Prérequis réseau

• Lien HA : Connexion dédiée entre les deux firewalls, idéalement directe par câble Ethernet.
• Zone du lien HA : Zone DMZ avec SSH activé pour la zone.
• Adresses IP du lien HA : Adresses IP statiques dans le même sous-réseau, mais différentes.
• Qualité du lien HA : Bande passante élevée, faible latence et aucune perte de paquets.
• Switches : Activer RSTP sur les commutateurs connectés aux ports du firewall.
• Monitored Ports : Surveiller uniquement les ports connectés et critiques.
• Cellular WAN : Désactiver pour HA.
• Peer Admin Port : Planifier séparément pour que l’Auxiliary Firewall reste accessible.
• Adresses des interfaces : Active-Active exige des adresses IP statiques sur toutes les interfaces. Active-Passive autorise DHCP, DHCP Prefix Delegation ou PPPoE. La connexion PPPoE ne bénéficie pas du failover de session.

En Active-Passive, les interfaces de production peuvent utiliser DHCP, DHCP Prefix Delegation ou PPPoE, mais le Dedicated HA Link et les deux ports d’administration nécessitent toujours des adresses statiques. En Active-Active, toutes les interfaces doivent avoir des adresses statiques. La limite documentée de PPPoE n’établit pas une exception générale de failover de session pour les interfaces DHCP : l’attribution d’adresses et le trafic du protocole DHCP sont distincts de la préservation des sessions TCP transférées. Appliquer les limites par protocole et service décrites plus haut, sans en déduire non plus une garantie générale de préservation des sessions sur les interfaces DHCP.

Les interfaces breakout sont configurées sur le Primary. Pour une nouvelle configuration breakout, redémarrer d’abord le Primary afin d’appliquer la modification, puis redémarrer l’Auxiliary. Si la configuration breakout correspondante existe déjà sur le Primary, redémarrer uniquement l’Auxiliary après la synchronisation. Si aucune configuration breakout correspondante n’existe sur le Primary, la synchronisation supprime toute configuration breakout présente uniquement sur l’Auxiliary. Les différents cas sont expliqués dans Configurer les interfaces breakout.

Le lien HA ne transporte aucun trafic client ou serveur normal. Il sert uniquement aux heartbeats, à l’état, à la synchronisation des sessions et de la configuration, ainsi qu’à la distribution Active-Active. Il ne peut pas être réutilisé pour HSRP, car les messages hello HSRP ne traversent pas le Dedicated HA Link. Il reste néanmoins extrêmement critique. S’il tombe en panne, les deux firewalls peuvent croire qu’ils sont Primary. Ce scénario split-brain doit être évité.

Le Peer Admin Port fournit un accès opérationnel distinct au WebAdmin de l’Auxiliary Firewall depuis le même sous-réseau. QuickHA utilise automatiquement l’interface de la session WebAdmin actuelle pour l’administration. Contradiction dans les instructions officielles sur l’adressage : la documentation des modes et rôles HA exclut explicitement le Dedicated HA Link et les ports d’administration de la synchronisation ; les prérequis d’interfaces HA exigent deux adresses IP d’administration statiques différentes dans le même sous-réseau. À l’inverse, le guide de démarrage du port d’administration interdit des adresses IP PortMGMT différentes en HA, au motif que la configuration est synchronisée. Une adresse PortMGMT commune complétée par une adresse Peer Administration supplémentaire n’est pas une conciliation établie de ces instructions. Avant la configuration ou toute modification des adresses d’administration, documenter les rôles Primary/Auxiliary actuels ou, pour des appareils autonomes, les rôles prévus, le build SFOS exact installé, l’interface d’administration sélectionnée et les adresses IP actuelles. Disposer d’une sauvegarde sécurisée et d’un accès administratif indépendant par console ou accès local. Vérifier le comportement applicable au build installé dans les instructions correspondantes ou le clarifier avec Sophos Support. Si la contradiction reste non résolue, arrêter avant Initiate HA ou toute modification des adresses d’administration.

L’adresse par défaut des ports ordinaires est 172.16.16.16 ; le PortMGMT dédié des grandes appliances utilise 10.0.1.1. Le Primary est accessible depuis toute zone où HTTPS est autorisé sous Administration > Device access. Pour accéder à WebAdmin sur l’Auxiliary, le poste d’administration doit être dans le même sous-réseau que son port d’administration.

Ports et interfaces

• Dedicated HA link : Transporte les heartbeats, l’état et la synchronisation de la configuration et des sessions. Le connecter directement ou via un switch très fiable. Ne pas l’utiliser pour le trafic de production.
• Monitored ports : Surveillent les liens de production critiques. Surveiller les uplinks WAN, DMZ ou core importants, mais ne pas sélectionner de ports inutilisés.
• Peer Admin Port : Permet l’accès au WebAdmin de l’Auxiliary. Le planifier et le documenter séparément ; le client doit se trouver dans le sous-réseau adapté.
• Interfaces de production : Câbler LAN, WAN, DMZ, VLANs et LAGs de manière identique sur les deux firewalls et les concevoir de façon équivalente.

Des interfaces physiques, VLANs ou LAGs peuvent servir de Dedicated HA link. Les interfaces Bridge et adresses Alias IP ne peuvent pas être utilisées comme lien HA dédié. QuickHA peut regrouper jusqu’à quatre interfaces physiques non liées dans un HA redundant link ; pour un LAG existant, les parent interfaces doivent être configurées de manière identique sur les deux appliances.

Dans SFOS 23, un Dedicated HA link utilisant un LAG ou un VLAN sur LAG exige Keepalive request interval × Keepalive attempts ≥ 2500 ms. La valeur de configuration par défaut de SFOS 23, 100 ms × 3 = 300 ms, ne respecte pas cette exigence LAG et ne doit pas être appliquée ici sans modification. Un exemple autorisé est 250 ms × 10 tentatives = 2500 ms, et non une valeur par défaut universelle. QuickHA crée un HA redundant link sous forme de LAG lorsque plusieurs interfaces physiques non liées sont sélectionnées ; cette exigence s’applique donc aussi à cette topologie. Vérifier la configuration réelle du lien. Ne pas supposer que QuickHA négocie automatiquement des valeurs adaptées ; vérifier les valeurs configurées avant de compter sur le cluster.

Ports haut débit : Pour les ports 25, 50 et 100 GbE des XGS 7500/8500 Series, sélectionner le même Link mode avec des valeurs de vitesse et de duplex identiques des deux côtés sous Network > Interfaces > Advanced settings, puis enregistrer avec Save. Ouvrir ensuite à nouveau l’interface pour la modifier, utiliser Show recommended settings > Load recommended configuration pour la négociation et Forward Error Correction (FEC), puis enregistrer à nouveau avec Save. Si les recommandations restent vides après le premier enregistrement et la réouverture, désactiver Auto-negotiation pour Media Type et FEC, puis enregistrer la modification. Pour les autres ports, utiliser Automatic ou des valeurs de vitesse et de duplex identiques, et conserver les valeurs MTU et MSS par défaut. Lorsque QuickHA sélectionne une interface non liée, SFOS réinitialise ses Advanced settings ; vérifier à nouveau ces valeurs après l’établissement de HA.

Important : le Dedicated HA link et un Monitored Port ne doivent pas être la même interface. Si une interface déjà utilisée par une configuration de production est sélectionnée comme lien HA, le firewall peut modifier ou supprimer les configurations dépendantes. Le lien HA doit donc être libre et documenté au préalable.

Conception réseau

Les deux firewalls doivent pouvoir occuper la même position réseau lors d’une panne. Les interfaces de production, VLAN trunks, LAGs, switchports et connexions fournisseur doivent donc être câblés de manière équivalente des deux côtés. La redondance WAN, SD-WAN et le failover fournisseur restent des tâches distinctes ; HA ne les remplace pas.

• Connecter le Dedicated HA link aussi directement que possible. S’il passe par des commutateurs, le chemin doit être stable, à faible latence et sans perte de paquets.
• Des nœuds HA géographiquement séparés ne sont raisonnables que sur un réseau Layer 2 à faible latence dans le même domaine de broadcast. Le Dedicated HA Link reste dans le même sous-réseau IP ; une latence élevée ou une perte de paquets rendent ce design inadapté.
• Activer RSTP sur les commutateurs concernés et configurer VLANs, trunks et LAGs de manière identique des deux côtés.
• Surveiller uniquement les uplinks WAN, core ou DMZ connectés en permanence. Un Monitored Port volontairement déconnecté déclencherait sinon un failover.
• VLANs et LAGs sont pris en charge, mais doivent utiliser les mêmes parent interfaces sur les deux nœuds. Bridge Mode fonctionne, mais son dépannage est plus complexe que celui de Gateway Mode.
• Tester séparément les scénarios VPN, RED et distants, car toutes les sessions ne sont pas transférées de façon transparente.
• Limiter consciemment l’accès d’administration et Device Access. Voir Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.

En Active-Active, il faut également savoir quel goulot d’étranglement sera réduit par le trafic éligible à la distribution TCP. Si les licences, services et processus de dépannage des deux nœuds ne sont pas définis, Active-Passive reste le meilleur choix.

Avertissement : Dans une situation split-brain, les deux firewalls se considèrent responsables. Cela peut provoquer une utilisation dupliquée des adresses IP et MAC et une interruption de production. Si le lien HA tombe en panne, décider d’abord quel nœud doit rester actif, puis arrêter l’autre de manière contrôlée ou le déconnecter du réseau de production.

Préparer la configuration

Ne pas improviser dans le réseau de production avant de configurer HA. Cette préparation permet de gagner beaucoup de temps par la suite.

Préparer les deux firewalls

• Mettre les deux firewalls sur la même version SFOS, y compris le build.
• Vérifier l’état des licences et de l’enregistrement.
• Désactiver Cellular WAN.
• Confirmer la compatibilité des modèles.
• Vérifier la configuration des Flexi Ports.
• Documenter les interfaces et switchports.
• Sélectionner le port du lien HA.
• Connecter directement le lien HA ou vérifier le chemin via les commutateurs.
• Planifier la zone DMZ et l’accès SSH pour le lien HA.
• Documenter l’accès d’administration aux deux appareils.
• Créer une sauvegarde de la configuration existante.
• Si LINCE est nécessaire, aligner le mode sur les deux appareils avant d’activer HA.

FIPS suit une autre séquence que LINCE. Le mode FIPS 140-3 est d’abord activé sur le Primary autonome, ce qui entraîne une réinitialisation aux paramètres d’usine ; Sophos active automatiquement FIPS sur l’Auxiliary pendant la configuration HA qui suit.

Les sauvegardes ne sont pas facultatives avec HA. Une sauvegarde doit être disponible avant la configuration, les mises à jour du firmware et les modifications importantes d’interfaces. Voir Créer ou restaurer une sauvegarde Sophos Firewall.

Avant de sélectionner Initiate HA, vérifier également :

• Adressage d’administration validé pour le build installé : Respecter le contrôle préalable décrit sous Prérequis réseau : documenter les rôles actuels ou prévus, le build SFOS exact, l’interface d’administration et les IP actuelles ; disposer d’une sauvegarde sécurisée et d’un accès indépendant par console ou accès local. Clarifier les instructions contradictoires pour ce build, si nécessaire avec Sophos Support. Si elles restent non résolues, ne pas sélectionner Initiate HA ni modifier les adresses d’administration.
• Dedicated HA link sans dépendances de production : HA peut modifier les adresses IP des interfaces et les configurations dépendantes.
• Monitored Ports connectés sur les deux appareils : Un Monitored Port déconnecté peut empêcher la formation du cluster ou déclencher immédiatement un failover.
• Cluster ID unique : Plusieurs clusters HA dans la même zone Layer 2 nécessitent des adresses MAC virtuelles différentes.
• Sauvegarde, SSMK et firmware build documentés : Le cluster doit pouvoir être reproduit lors d’une restauration, RMA ou reimage.

Définir LINCE avant HA

Depuis SFOS 21.5 MR1, LINCE ne peut plus être activé ou désactivé après la création d’un cluster HA. Si la certification est requise, exécuter la commande suivante dans la Device Console sur les deux firewalls encore indépendants.

Avertissement : Vérifier auparavant qu’un accès de remplacement est disponible via WebAdmin ou la console locale. La commande active LINCE, redémarre le service SSH et déconnecte les sessions SSH existantes.

system certification lince enable

Vérifier ensuite l’état LINCE sur les deux appareils avant de créer HA. Lors d’une restauration, la sauvegarde et le cluster cible doivent avoir le même état LINCE.

Comprendre et activer le mode LINCE sur Sophos Firewall explique pourquoi le mode ne certifie pas automatiquement le build SFOS déployé et quels algorithmes SSH doivent être contrôlés avant l’activation.

QuickHA ou Interactive mode

• QuickHA : Cas standard. Rapide, robuste et suffisant pour la plupart des configurations Active-Passive et Active-Active.
• Interactive mode : Utile lorsque les Admin Ports, adresses du lien HA, Cluster ID, Monitored Ports et valeurs détaillées doivent être définis avant la création du cluster.

QuickHA demande initialement uniquement le rôle, le nom du nœud, la passphrase et le Dedicated HA link. La passphrase doit comporter entre 10 et 20 caractères et inclure au moins une majuscule, une minuscule, un chiffre et un caractère spécial. Elle est utilisée une seule fois pour générer les clés SSH, puis supprimée. Avant de remplacer un appareil dans une paire HA encore fonctionnelle, HA doit donc être désactivé, puis reconfiguré avec l’appareil de remplacement. Les sections correspondantes ci-dessous expliquent l’état initial particulier après un RMA et les descriptions divergentes des procédures de reimage.

Les appareils QuickHA préparés continuent à rechercher leur peer jusqu’à ce qu’ils le trouvent. Ils peuvent donc être configurés à l’avance et connectés plus tard sur le site cible. Dès qu’un appareil a découvert le peer et que l’établissement HA est en cours, ce processus de discovery ne peut plus être arrêté. La sélection des interfaces, la passphrase et le peer prévu doivent donc être corrects avant que les deux liens HA soient accessibles simultanément.

Pour une modification en production, ne pas simplement parcourir l’assistant : documenter au préalable les rôles, le lien HA, l’accès d’administration, la sauvegarde, l’état des licences et la procédure de retour arrière.

Noms des nœuds dans QuickHA : Dans SFOS 22, l’attribution d’un nom est facultative. Pour SFOS 23, les instructions détaillées demandent un nom de nœud, tandis que les exemples de configuration continuent de le présenter comme facultatif. La checklist suivante attribue donc aux deux appareils des noms différents et facilement reconnaissables. Il s’agit d’une consigne prudente, et non d’une preuve que la GUI refuse un champ de nom vide.

Configurer HA

Active-Passive avec QuickHA

1. Préparer le Primary Firewall

1. Se connecter au WebAdmin du firewall qui deviendra Primary.
2. Accéder à System services > High availability.
3. Sélectionner Primary (active-passive) comme mode.
4. Utiliser QuickHA.
5. Attribuer un nom de nœud unique, par exemple FW01.
6. Définir une passphrase HA de 10 à 20 caractères contenant une majuscule, une minuscule, un chiffre et un caractère spécial.
7. Conserver temporairement la passphrase de manière sécurisée, car elle est requise ensuite sur l’Auxiliary Firewall.
8. Sélectionner le Dedicated HA link.
9. Sélectionner Initiate HA.

Remarques :

• Lorsque QuickHA utilise une interface non liée, Sophos lui attribue la zone DMZ et, par défaut, 169.254.192.1. SSH est activé automatiquement pour la zone.
• Le firewall supprime les configurations dépendantes de l’interface sélectionnée comme lien HA. Elle doit donc être libre de toute dépendance de production.

2. Préparer l’Auxiliary Firewall

1. Se connecter au firewall qui deviendra Auxiliary.
2. Accéder à System services > High availability.
3. Sélectionner Auxiliary comme rôle.
4. Utiliser QuickHA.
5. Attribuer un nom de nœud différent de celui du Primary, par exemple FW02.
6. Saisir la même passphrase HA.
7. Sélectionner le même port de lien HA que sur le Primary.
8. Sélectionner Initiate HA.

Une fois le cluster créé, le Primary Firewall synchronise la configuration vers l’Auxiliary Firewall. De nombreux paramètres locaux de l’Auxiliary sont écrasés. Il ne faut donc pas le configurer en parallèle comme firewall de production indépendant avant la configuration HA.

3. Vérifier les paramètres avancés

Après la création du cluster, vérifier les points suivants sans modifier l’adressage d’administration tant que le contrôle préalable décrit sous Prérequis réseau n’est pas résolu :

• État HA des deux nœuds
• Rôle et état en haut à droite dans WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval et Attempts
• Titulaire de la licence en Active-Passive
• Enregistrement Sophos Fusion, s’il est utilisé

4. Définir les Monitored Ports

Les Monitored Ports déterminent si la panne d’une interface déclenche un failover. Le champ de sélection s’appelle Select ports to be monitored dans SFOS 22 et Monitored interfaces dans les instructions détaillées de SFOS 23. Candidats habituels :

• Uplink WAN
• Uplink LAN core
• Uplinks DMZ ou serveurs importants

Ne pas surveiller les ports volontairement hors ligne par moments, non câblés ou réservés à des scénarios facultatifs. Un Monitored Port mal sélectionné est une cause fréquente de failover inattendu ou de cluster qui ne démarre pas.

Les choix possibles sont les interfaces physiques, les LAGs et les interfaces non liées avec un VLAN configuré. Une interface non liée sans VLAN ne peut pas être sélectionnée comme Monitored Port. Les Monitored Ports doivent utiliser des adresses IP statiques dans les deux modes HA.

SFOS 23 autorise au maximum 24 Monitored ports. Garder cette sélection distincte du Dedicated HA link et n’inclure que les liens de production réellement nécessaires.

HA fonctionne également sans Monitored Ports sélectionnés. Dans ce cas, la panne d’un port de production ne déclenche pas à elle seule un failover ; les défaillances de heartbeat, d’appareil ou d’alimentation peuvent toujours déclencher un changement de rôle. Chaque port effectivement sélectionné doit être connecté sur les deux nœuds. La surveillance de l’état des ports ne détecte pas toutes les pannes d’un fournisseur en amont.

Les paramètres HA avancés, tels que Monitored interfaces, Peer administration, Preferred primary et les valeurs keepalive, sont modifiés après l’établissement de QuickHA sur le Primary actuel. Vérifier au préalable la sauvegarde, la fenêtre de maintenance et la disponibilité d’un accès d’administration sécurisé ; toute modification de Peer administration ou des adresses d’administration reste soumise au contrôle préalable bloquant décrit sous Prérequis réseau. Le changement de MAC décrit plus haut provoque une interruption de service. Pour un lien HA basé sur un LAG, respecter l’exigence keepalive et ne pas modifier les valeurs lorsque l’état est Standalone ou Faulty. Une fois la sélection souhaitée effectuée, revenir en haut de la page et sélectionner Initiate HA. Le Primary synchronise alors les modifications vers l’Auxiliary. Vérifier ensuite sur les deux nœuds les rôles HA, l’état, la synchronisation et les valeurs modifiées ; en cas d’écart, comparer d’abord le lien HA et les logs des deux appareils. Cette étape finale s’applique également à la variante Active-Active suivante et doit être distinguée de l’intégration initiale des deux appareils au cluster.

Active-Active avec QuickHA

Active-Active se configure de manière similaire, mais avec un objectif différent. Les deux firewalls doivent disposer au préalable de licences adaptées.

Le processus est identique à Active-Passive, mais sélectionner Primary (active-active) sur FW01. Les deux appareils doivent être revendiqués, exécuter le même SFOS build et avoir des types de licence compatibles ; toutes les interfaces nécessitent des adresses IP statiques. La supervision et le dépannage doivent couvrir les deux nœuds, et le trafic concerné doit bénéficier de la distribution TCP décrite ci-dessus.

Tester après la configuration

En Active-Active, il faut tester plus que le seul état HA :

• Les connexions sont-elles distribuées entre les deux nœuds ?
• Les licences des deux nœuds ont-elles été synchronisées individuellement avec succès, avec le statut et l’heure notés séparément ?
• Les logs sont-ils visibles sur les deux appareils ?
• Les connexions VPN fonctionnent-elles après un changement de rôle ?
• Web Protection, IPS, Application Control et les fonctions de sécurité pertinentes fonctionnent-ils ?
• Certaines applications sont-elles affectées par le comportement asymétrique ?
• Les rapports et alertes attendus sont-ils générés ?

Interactive mode

Interactive mode est utile lorsque la logique automatique de QuickHA n’offre pas assez de contrôle.

Avant la configuration, autoriser SSH et Ping/Ping6 pour la zone DMZ sur les deux appareils sous Administration > Device access. Interactive mode sélectionne initialement et automatiquement la première interface DMZ comme Dedicated HA link. Si cette interface n’est pas prévue pour HA ou comporte des dépendances de production, sélectionner avant l’enregistrement une interface physique, VLAN ou LAG préparée et libre.

Motifs habituels :

• Des adresses IP fixes doivent être utilisées pour le lien HA
• Le Peer Admin Port doit être défini précisément
• Le Cluster ID doit être défini volontairement
• Plusieurs clusters HA existent dans le même environnement Layer 2
• Les appliances virtuelles nécessitent des options MAC spécifiques
• Un déploiement très contrôlé est nécessaire

En Interactive mode, configurer d’abord l’Auxiliary, puis le Primary. Cela évite que la détection du peer expire sur le Primary pendant la préparation du second nœud.

1. Configurer l’Auxiliary

1. Sur FW02, accéder à System services > High availability.
2. Sélectionner Initial device role > Auxiliary et HA configuration mode > Interactive mode.
3. Définir le nom du nœud et une passphrase conforme aux règles ci-dessus.
4. Sélectionner le port DMZ libre pour le Dedicated HA link. Le firewall supprime les configurations dépendantes existantes de cette interface.
5. Enregistrer et attendre la confirmation de l’application de la configuration Auxiliary.

2. Configurer le Primary

1. Sur FW01, sélectionner Primary (active-passive) ou Primary (active-active) et Interactive mode.
2. Définir un Cluster ID unique et le nom du nœud.
3. Saisir la passphrase de FW02.
4. Indiquer le même Dedicated HA link ainsi que l’adresse IP statique du lien HA de l’Auxiliary. Le champ s’appelle Dedicated peer HA link IPv4 address dans SFOS 22 et Peer IPv4 address of dedicated HA link dans les instructions détaillées de SFOS 23. Les deux adresses du lien HA doivent se trouver dans le même sous-réseau. Il ne s’agit pas de l’adresse IP d’administration définie sous Peer administration settings, dont le comportement doit être clarifié selon le contrôle préalable décrit sous Prérequis réseau.
5. Sélectionner les Monitored ports critiques ; SFOS 23 en autorise au maximum 24.
6. Sous Peer administration settings, indiquer l’interface d’administration et l’adresse IP de FW02 uniquement après résolution du contrôle préalable sur l’adressage décrit sous Prérequis réseau pour le build installé. Si la contradiction reste non résolue, arrêter avant de modifier les adresses ou de sélectionner Initiate HA.
7. Si nécessaire, sélectionner Use host or hypervisor-assigned MAC address pour les appliances virtuelles dans SFOS 22, ou Use interface MAC address dans SFOS 23. L’option SFOS 23 utilise la MAC de l’hypervisor sur les appliances virtuelles et la MAC d’interface sur le matériel, au lieu de la MAC virtuelle du cluster. L’activer ou la désactiver provoque une interruption de service.
8. Définir Preferred primary et sélectionner Initiate HA.

Après la création du cluster, modifier les valeurs keepalive uniquement pour une raison documentée. SFOS 22 autorise des intervalles de 250–500 ms et 16–24 tentatives ; les valeurs par défaut de 250 ms et 16 tentatives donnent un timeout de 4 secondes. SFOS 23 autorise 100–500 ms et 3–24 tentatives ; les valeurs par défaut de 100 ms et 3 tentatives donnent 300 ms. Pour les Dedicated HA links de SFOS 23 utilisant un LAG ou un VLAN sur LAG, le produit doit être d’au moins 2500 ms : 250 ms × 10 tentatives est un exemple autorisé, pas la valeur par défaut générale. Vérifier aussi les LAG redondants créés par QuickHA. Ces valeurs ne peuvent pas être modifiées lorsque les appareils ont l’état Standalone ou Faulty. Après le timeout, le nouveau Primary effectue des contrôles internes avant de commencer à traiter le trafic. Aucun de ces timeouts ne garantit un délai de rétablissement du trafic.

Divergence dans la documentation de l’API de SFOS 22 : La description de Keepalive attempts indique 8–16 tentatives, tandis que la contrainte détaillée du paramètre et l’exemple XML indiquent 16–24. La contrainte détaillée indique cette plage ; 8–16 ne constitue pas une seconde plage confirmée. Avant toute modification, documenter le build SFOS installé et les valeurs keepalive actuelles des deux nœuds. Si les limites applicables restent incertaines, les clarifier avec Sophos Support avant toute modification ; les exigences LAG restent à respecter.

Vérification préalable de l’API pour SFOS 22 et 23 : Les tableaux des paramètres documentent ClusterId comme un entier facultatif dans la plage 0–63, avec une valeur par défaut de 0, et NodeName comme une chaîne de caractères obligatoire de 1–30 caractères. Même avec la valeur par défaut documentée, chaque cluster sur le réseau Layer 2 partagé doit utiliser un Cluster ID distinct afin d’éviter les conflits de MAC virtuelles. Ces métadonnées de l’API ne modifient pas les indications ci-dessus concernant le caractère facultatif ou obligatoire de l’attribution d’un nom dans la GUI et ne prouvent aucune validation par la GUI. Le tableau utilise l’orthographe ClusterId, l’exemple XML ClusterID ; cela n’établit ni une correspondance testée entre les balises ni une charge utile API fonctionnelle.

Dans les paramètres HA avancés de SFOS 23, Monitor hardware components est facultatif et ajoute un déclencheur de failover lorsqu’un problème de périphérique de stockage est détecté, en complément des défaillances de heartbeat et d’interfaces surveillées. Ne pas supposer qu’il est activé par défaut ni qu’il détecte toutes les pannes matérielles.

Note sur l’API de SFOS 23 : Le tableau des paramètres de l’API présente HardwareMonitor comme un paramètre scalaire facultatif (SCALAR, Mandatory: No), avec les valeurs Enable et Disable et la valeur par défaut documentée pour l’API Enable. Cette indication ne prouve ni le réglage réel dans la GUI ni l’état de l’appareil en fonctionnement. Vérifier le réglage sur l’appareil installé ; le périmètre limité aux périphériques de stockage décrit ci-dessus reste inchangé.

L’exemple XML de l’API de SFOS 23 contient toujours Number(250-500) et Number(16-24). Ces valeurs indicatives ne correspondent pas aux plages du tableau, 100–500 ms et 3–24 tentatives, et ne doivent pas être reprises comme limites complètes. Cela ne prouve ni un rejet des valeurs inférieures par le produit ni un comportement testé de l’API.

Connecter un nouvel Auxiliary virtuel comme HA spare

Pour un nouvel Auxiliary virtuel en Active-Passive, le Setup Assistant peut utiliser Connect as HA spare. Avant de sélectionner Initiate HA, effectuer le contrôle préalable sur le conflit d’adressage d’administration décrit sous Prérequis réseau et vérifier le comportement applicable au build installé à l’aide des instructions Sophos ou avec Sophos Support. Si la contradiction reste non résolue, arrêter avant Initiate HA ou toute modification des adresses d’administration ; la configuration automatique du port d’administration ne résout pas cette contradiction. Cette procédure constitue une alternative à la configuration décrite ci-dessus, qui commence par l’Auxiliary avec deux appareils déjà présents : la nouvelle VM spare n’est pas configurée au préalable comme Auxiliary. Active-Active ou deux firewalls Virtual/Software existants nécessitent toujours QuickHA ou Interactive mode sur les deux appareils.

1. Sur le Primary existant, autoriser SSH pour DMZ sous Administration > Device access et sélectionner Primary (active-passive) ainsi que Interactive mode sous System services > High availability. Dans SFOS 23, saisir un Cluster ID et un nom de nœud avant de sélectionner Initiate HA ; les instructions de SFOS 22 présentent la saisie du Cluster ID et la modification du nom du nœud comme facultatives. Si plusieurs clusters HA sont présents sur le même réseau Layer 2, utiliser un Cluster ID distinct pour chaque cluster afin d’éviter les conflits d’adresses MAC virtuelles. Documenter de manière sécurisée le Dedicated HA Link, sa propre adresse IP et son masque de sous-réseau, l’adresse IP prévue du peer, Peer Administration et la passphrase HA utilisée sur le Primary. Sélectionner ensuite Initiate HA ; dans SFOS 23, revenir en haut de la page pour accéder à cette action. À ce stade, avant que la nouvelle VM rejoigne le cluster, le guide Sophos pour la configuration d’un spare documente le message HA could not be enabled et, temporairement, l’état Standalone. Pendant cette phase de configuration, aucun de ces deux éléments ne prouve à lui seul l’échec d’un cluster entièrement constitué.
2. Installer le nouveau firewall virtuel avec exactement le même build SFOS, lancer le Setup Assistant et définir un nouveau mot de passe administrateur.
3. Sélectionner Connect as HA spare et saisir le numéro de série du Primary existant, la même passphrase HA précédemment utilisée sur le Primary et documentée de manière sécurisée, ainsi que la même interface Dedicated HA Link. Pour le nouveau spare, utiliser une adresse IP propre, libre et différente de celle du Primary, dans le sous-réseau du Dedicated HA Link du Primary existant, avec un masque de sous-réseau identique ; elle doit correspondre à l’adresse IP du peer préparée sur le Primary. Ne pas supposer qu’une passphrase provient d’un Auxiliary prétendument déjà configuré.
4. Sélectionner Apply, Continue et Finish. SFOS crée l’Auxiliary, attribue un numéro de série commençant par HAAUX et configure automatiquement le Dedicated HA Link et le port d’administration.
5. Après quelques minutes, actualiser WebAdmin de l’Auxiliary et se reconnecter. Vérifier ensuite sur le Primary les rôles, la synchronisation, Peer Admin, les Monitored Ports et le failover.

Valider le cluster

Après la configuration, valider systématiquement le cluster HA.

Vérification dans WebAdmin

1. Se connecter au Primary Firewall.
2. Vérifier l’état HA en haut à droite.
3. Accéder à System services > High availability.
4. Vérifier les rôles, états, numéros de série et le mode.
5. Confirmer que le cluster est synchronisé.
6. En Active-Passive, vérifier quel appareil détient la licence du cluster.

Vérification CLI

Dans la Device Console, la commande en lecture seule suivante affiche les rôles, l’état et la synchronisation du cluster. Elle ne modifie pas la configuration :

system ha show details

Vérifier les paramètres opérationnels de SFOS 22

SFOS 22 documente deux paramètres HA supplémentaires. Consulter leurs valeurs avant toute modification :

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

Le premier contrôle détermine le chemin du trafic système envoyé par l’Auxiliary Firewall lui-même. Par défaut, tout ce trafic passe par le Dedicated HA Link. Outre all, les options none et only_dynamic_interface sont disponibles. Sophos ne précise pas quels flux relèvent de l’option only_dynamic_interface dans ce dernier mode. Cette option n’est donc utilisée que pour un cas confirmé sur le build installé, et non comme correction générale du routage.

Le second contrôle active ou désactive la répartition du trafic éligible entre les pare-feu. Il ne remplace pas la sélection du mode HA et ne rend pas éligibles au load balancing les services et tunnels exclus plus haut. Effectuer chaque modification séparément dans une fenêtre de maintenance et enregistrer auparavant les deux sorties show :

system ha auxiliary_system_traffic_through_dedicated_link [all|none|only_dynamic_interface]
system ha load-balancing [on|off]

Vérifier ensuite les rôles, la synchronisation, le Dedicated HA Link, les nouvelles sessions, les logs locaux des nœuds et les connexions système lancées par l’Auxiliary lui-même. Pour le retour en arrière, restaurer la valeur relevée auparavant. Sophos ne documente all comme valeur par défaut que pour le premier contrôle ; aucune valeur par défaut n’est supposée pour le load balancing.

Vérifier l’Initial Primary titulaire de la licence sous System services > High availability. Sophos documente également le contrôle CLI officiel suivant dans l’Advanced Shell :

nvram get "#li.master"

YES identifie l’Initial Primary qui détient les licences du cluster ; NO identifie l’appareil configuré comme Auxiliary. La commande est en lecture seule. La vue HA reste plus pratique pour les contrôles quotidiens, mais la sortie shell est elle aussi documentée officiellement.

Si l’accès shell n’est pas encore préparé, voir Se connecter à Sophos Firewall via SSH.

Test fonctionnel

• Tester l’accès Internet depuis un client LAN.
• Tester l’accès aux serveurs internes.
• Tester le VPN.
• Tester les scénarios DNAT ou WAF.
• Tester DNS et DHCP si le firewall fournit ces services.
• Vérifier les logs dans Log Viewer.
• Tester un changement de rôle HA pendant une fenêtre de maintenance.
• Documenter ensuite les rôles, l’état et le comportement des sessions.

Exploitation et maintenance

Surveillance continue

Surveiller l’état HA et les rôles, le Dedicated HA link, les Monitored Ports, les licences, le firmware, CPU, RAM, le disque et les services centraux. Envoyer les alertes vers Sophos Fusion, par email ou vers la plateforme de supervision existante.

Pour le disque et le matériel, considérer les deux nœuds séparément. Les rapports locaux, fichiers logs et l’état du SSD peuvent différer. Voir Vérifier le stockage Sophos Firewall et gérer les rapports et Vérifier l’état du SSD Sophos Firewall avec SMART.

Logs et rapports

Chaque nœud écrit les logs du trafic qu’il traite. En Active-Active, il faut donc vérifier les deux appareils. Sophos Central Firewall Reporting ou syslog conviennent à une analyse consolidée. Les fichiers locaux sont expliqués dans Dépannage Sophos Firewall : services et logs.

L’Auxiliary envoie des rapports par email uniquement lorsqu’ils contiennent des données sur ce nœud, par exemple une activité email ou des Pattern Updates. Il n’envoie pas les rapports sans données, comme Security Dashboard ou Security Audit. L’absence d’un email pour ces types de rapport ne prouve donc pas à elle seule un dysfonctionnement.

En Active-Active, l’IP source fournit une première indication du nœud sur lequel les logs sont attendus : pour le trafic TCP éligible, les adresses paires correspondent au Primary, les adresses impaires à l’Auxiliary. Cela ne s’applique pas systématiquement aux types de trafic exclus ci-dessus et ne remplace pas la comparaison des deux appareils, notamment après un changement de rôle.

Pour les événements HA, ouvrir Log viewer > System séparément sur chaque nœud. Via Add filter, sélectionner le filtre et la valeur adaptés à la période concernée, puis les appliquer avec le bouton Add filter. Pour une analyse détaillée, ouvrir Diagnostics > Tools > Troubleshooting logs > Select files sur les deux appareils et sélectionner csc.log pour le service central qui gère les autres services. Sélectionner également les fichiers HA décrits ci-dessous sous Logs et emplacements de diagnostic importants, puis enregistrer séparément chaque paquet avec Download. Pour reconstituer le déroulement des opérations du cluster, comparer les enregistrements des deux nœuds et rechercher les lacunes temporelles ou les logs ayant fait l’objet d’une rotation.

Runbook pour l’exploitation HA

Documenter au minimum dans le runbook d’exploitation :

• Numéro de série, emplacement, position dans le rack et rôle des deux appliances.
• Dedicated HA link, Peer Admin Port, Cluster ID et Monitored Ports.
• Preferred primary et comportement attendu après un failover.
• Titulaire de la licence, statut du support et voie de contact RMA.
• Processus et responsabilité pour les mises à jour du firmware, sauvegarde, reimage, remplacement matériel, logs et cas de support.

Si WebAdmin ne répond pas sur un seul des deux nœuds, cela ne signifie pas automatiquement que tout le cluster HA est défectueux. Vérifier d’abord si un redémarrage de la GUI WebAdmin ou un redémarrage contrôlé des services suffit avant de déclencher un failover ou un reboot.

Modifications du cluster

Modifier les règles, interfaces et policies uniquement sur le Primary. Avant de modifier les interfaces, VLANs, LAGs, zones, routing, NAT, VPN, Device Access ou SD-WAN :

• Créer une sauvegarde.
• Définir une fenêtre de maintenance.
• Vérifier l’état HA.
• Mettre à jour la documentation.
• Définir une procédure de retour arrière.
• Tester ensuite la synchronisation et le trafic.

Synchronisation manuelle et changement de rôle forcé

La synchronisation automatique est le fonctionnement normal. Utiliser Sync auxiliary device sur le Primary ou l’Auxiliary uniquement pour corriger un problème de synchronisation confirmé. L’Auxiliary redémarre, effectue une synchronisation complète de la base de données et des fichiers associés, puis reste Auxiliary. Les logs et rapports restent locaux à chaque nœud. Le firewall interrompt toutes les connexions masqueradées pendant l’opération, qui doit donc être planifiée dans une fenêtre de maintenance.

En Active-Passive, forcer l’Auxiliary à prendre le relais avec Switch to passive device sur le Primary actuel ou Switch to active device sur l’Auxiliary actuel. Le Primary actuel redémarre. Il s’agit d’un changement de rôle planifié présentant un risque pour les sessions, et non d’une bascule anodine.

Désactiver HA de manière contrôlée

Les FAQ HA de Sophos pour SFOS 22 et 23 énoncent un prérequis général : désactiver HA avant un reimage, avant le remplacement d’un nœud dans la paire HA et avant un transfert de licence entre les nœuds. La passphrase à usage unique du tunnel SSH est supprimée après son établissement ; pour intégrer un nouvel appareil, HA doit donc être désactivé et reconfiguré. Cette exigence ne remplace pas une planification adaptée au cas précis : les détails de reimage ci-dessous présentent une divergence documentaire, et les procédures RMA supposent qu’un nœud sain fonctionne déjà à l’état Standalone HA. Planifier au préalable la sauvegarde, un accès d’administration assuré, la fenêtre de maintenance et la reconstruction ; pour la correction de licences Active-Passive, respecter également la condition relative aux numéros de série et aux rôles décrite ci-dessus.

Dans la mesure du possible, désactiver HA sur le Primary actuel sous System services > High availability > Disable HA. Le nœud utilisé détermine le résultat :

Accès via Fusion à partir de SFOS 22 MR1 : Les Sophos Known Issues, NC-186855, décrivent une exception au comportement général ci-dessus : lorsque HA est désactivé dans l’interface du pare-feu ouverte via Sophos Fusion/Central par FRP-SSO, l’Auxiliary peut rester en mode Standalone avec HA activé, alors que HA est déjà désactivé sur le Primary. Il existe alors un risque de split-brain. Après l’opération, vérifier séparément l’état HA sur les deux appareils. Si les états restent incohérents, interrompre la reconstruction prévue et coordonner la récupération avec Sophos Support avant de remettre les appareils en service comme paire. Un dialogue terminé avec succès sur le Primary ne suffit pas comme contrôle. Au 24 octobre 2026, l’entrée ne mentionne aucune version corrigée.

Mises à jour du firmware et sauvegardes

Mises à jour du firmware dans les environnements HA

Les mises à jour du firmware sont lancées sur le Primary Firewall. Les appareils sont mis à jour successivement et le cluster peut changer de rôle pendant le processus.

Processus typique :

1. Lancer la mise à jour sur le Primary Firewall.
2. L’Auxiliary Firewall est mis à jour.
3. L’Auxiliary Firewall redémarre et prend temporairement le relais.
4. L’ancien Primary est mis à jour.
5. L’ancien Primary redémarre.
6. Si Preferred primary est activé, un retour vers l’appareil préféré peut avoir lieu.

Les mises à jour du firmware doivent néanmoins avoir lieu dans une fenêtre de maintenance. Même si le processus vise une interruption de service minimale, certaines sessions, connexions VPN ou applications particulières peuvent subir une brève interruption ou nécessiter une reconnexion.

Un rollback du firmware de la paire HA suit le même processus et ne nécessite pas de désactiver HA au préalable.

Voir Mise à jour du firmware Sophos Firewall : préparation et bonnes pratiques.

Pattern Updates

Les Pattern Updates sont installées sur le Primary et automatiquement synchronisées vers l’Auxiliary. Cela s’applique aussi aux environnements où les mises à jour sont contrôlées ou installées hors ligne.

Dans un environnement HA isolé, identifier quel nœud est l’Initial Primary et lequel est actuellement Primary avant chaque Pattern Update ou mise à jour manuelle de licence. Le processus Air-Gap est décrit dans Exploiter les licences Air-Gap et les Pattern Updates de Sophos Firewall.

Sauvegarde et restauration

Créer des sauvegardes régulièrement et avant chaque modification importante. Si LINCE est activé, la sauvegarde et le cluster cible doivent avoir le même état LINCE. Trois cas de restauration s’appliquent :

Active-Active et Bridge-VLAN: Chaque nœud écrit ses propres logs. En SFOS 22 Active-Active, seul le Primary traite le trafic reçu sur les interfaces VLAN configurées sur des Bridge Interfaces. Les descriptions de configuration et d’interfaces de SFOS 23 omettent cette restriction, mais cette omission ne confirme pas une répartition de charge. Tant que Sophos Support n’a pas confirmé le comportement pour le build SFOS 23 et la topologie utilisés, prévoir prudemment ce trafic sur le Primary uniquement, sans compter sur sa distribution pour dimensionner la capacité.

Accès à la quarantaine: Chaque nœud stocke sa propre quarantaine et envoie son propre Quarantine Digest. Les administrateurs libèrent un email sur le nœud qui l’a traité. Les utilisateurs libèrent les emails mis en quarantaine via le User Portal. Le User Portal affiche uniquement les emails mis en quarantaine sur le Primary actuel.

Attention avec une sauvegarde sans HA : Les descriptions Sophos pour SFOS 22 et 23 se contredisent sur l’état de l’Auxiliary après cette restauration : le texte indique qu’il conserve sa configuration précédente, tandis que le résumé indique une réinitialisation d’usine, sauf pour le Peer Admin Port et le Dedicated HA Link. Ni la conservation complète ni la réinitialisation d’usine ne constituent donc un comportement établi. Ne pas compter sur la conservation de la configuration de l’Auxiliary. Sauvegarder d’abord les configurations sur un support externe, documenter les adresses IP d’administration et les identifiants, et prévoir une interruption ainsi que la reconstruction de HA. Avant de dépendre de cet état incertain de l’Auxiliary, clarifier la procédure pour le build SFOS installé avec Sophos Support.

Si le Primary était enregistré comme gateway Sophos ZTNA, l’ajouter à nouveau comme gateway dans Sophos ZTNA après la restauration sur le cluster HA.

Reimage des nœuds HA en Active-Passive

Un reimage interrompt l’exploitation et, selon Sophos, s’applique uniquement à Active-Passive. Exécuter au préalable system diagnostics show version-info dans la Device Console des deux nœuds, documenter le firmware avec son build et l’Initial Primary, puis enregistrer une sauvegarde actuelle hors du cluster.

Périmètre des procédures suivantes : Au départ, FW1 est à la fois le Primary actuel et l’Initial Primary détenteur des licences ; FW2 est l’Auxiliary actuel. Ces noms désignent les mêmes appareils physiques pendant toute la procédure, même après un changement de rôle. L’objectif est de retrouver FW1 comme Primary et FW2 comme Auxiliary. Si le Primary actuel et l’Initial Primary sont des appareils différents, ne pas improviser à partir de ces procédures : déterminer d’abord les rôles et le détenteur des licences à l’aide des instructions Sophos applicables ou avec Sophos Support.

Clarifier la divergence documentaire avant le reimage : Les FAQ HA pour SFOS 22 et 23 exigent de manière générale la désactivation de HA avant un reimage. En revanche, pour le reimage du Primary et celui des deux nœuds, les instructions détaillées Active-Passive décrivent un changement de rôle avec Switch to passive device, suivi d’une réinstallation, sans mentionner d’étape distincte Disable HA. Le changement de rôle n’équivaut pas à une désactivation de HA ; cette omission ne prouve pas l’existence d’une exception généralement sûre. Les séquences détaillées suivantes sont donc conservées en tant que procédures documentées, mais contradictoires sur ce point. Avant de les exécuter, définir précisément les rôles, l’Initial Primary, le build installé, la sauvegarde, l’interruption de service et la procédure de retour arrière, et clarifier l’ordre adapté avec Sophos Support si cette séquence détaillée divergente doit être utilisée. Si l’ordre reste incertain, arrêter avant le changement de rôle ou la réinstallation ; ne pas ajouter de sa propre initiative une étape de désactivation à la séquence.

Si FW1 est enregistré pour Central Management, le désenregistrer avant chacune des trois procédures. Vérifier ensuite, dans le même tenant Sophos Central/Fusion sous My Products > Firewall Management > Firewalls, que l’entrée de FW1 n’est plus présente. Ne poursuivre avec la sauvegarde, la désactivation de HA ou le changement de rôle qu’après cette vérification. Ce contrôle concerne l’enregistrement pour Firewall Management, et pas uniquement Synchronized Security.

Réinstaller uniquement l’Auxiliary FW2

1. Après le désenregistrement et la vérification décrits ci-dessus, enregistrer la sauvegarde de FW1 sur un support externe et désactiver HA sur FW1, jamais sur FW2.
2. Dans l’Advanced Shell de FW1, vérifier avec service -S | grep msync que msync affiche l’état UNTOUCHED ou STOPPED. Sinon, ne pas poursuivre.
3. Réinstaller FW2 avec exactement la même version de firmware, build compris, que FW1. Se connecter localement et configurer uniquement le WAN pour l’accès Internet, sans configurer d’interfaces LAN ou DMZ. Revendiquer ensuite FW2 s’il ne l’est pas déjà.
4. Reconstruire HA avec FW1 comme Primary et FW2 comme Auxiliary.

Réinstaller uniquement le Primary FW1

1. Après le désenregistrement et la vérification, enregistrer la sauvegarde de FW1 sur un support externe et utiliser Switch to passive device pour que FW2 prenne le relais. L’identité des appareils reste inchangée.
2. Réinstaller FW1 avec exactement la même version de firmware, build compris, que FW2. Se connecter localement, configurer uniquement le WAN pour l’accès Internet, sans configurer d’interfaces LAN ou DMZ, et revendiquer FW1 s’il ne l’est pas déjà.
3. Pour la restauration, débrancher tous les câbles de FW1 sauf celui du poste d’administration, restaurer la sauvegarde, reconnecter les câbles et retransférer le traitement du trafic de FW2 vers FW1.
4. Réinitialiser ensuite FW2 aux paramètres d’usine. Se connecter localement, configurer uniquement le WAN pour l’accès Internet, sans configurer d’interfaces LAN ou DMZ, et le revendiquer s’il ne l’est pas déjà.
5. Reconstruire HA avec FW1 comme Primary et FW2 comme Auxiliary.

Réinstaller et mettre à niveau les deux nœuds

1. Effectuer le désenregistrement, la vérification, la sauvegarde et le changement de rôle comme pour le reimage du Primary. Installer toutefois sur FW1 la version cible, build cible compris. Se connecter ensuite localement, configurer uniquement le WAN pour l’accès Internet, sans configurer d’interfaces LAN ou DMZ, et le revendiquer s’il ne l’est pas déjà.
2. Pour la restauration, débrancher tous les câbles de FW1 sauf celui du poste d’administration, y restaurer la sauvegarde, reconnecter les câbles et retransférer le traitement du trafic de FW2 vers FW1.
3. Contrairement au reimage du Primary seul, ne pas se contenter de réinitialiser FW2 aux paramètres d’usine : le réinstaller également avec exactement la même version cible, build compris, que FW1. Se connecter localement, configurer uniquement le WAN pour l’accès Internet, sans configurer d’interfaces LAN ou DMZ, et le revendiquer s’il ne l’est pas déjà.
4. Reconstruire le cluster Active-Passive avec FW1 comme Primary et FW2 comme Auxiliary. L’interruption planifiée comprend également cette seconde étape de réinstallation et d’intégration au cluster.

Si le cluster utilise Sophos Central Synchronized Security, la paire HA doit être retirée de la gestion Central avant le retour de l’appareil dans le cadre du RMA. Après le remplacement, le nouveau cluster HA est de nouveau enregistré dans Central. Cela évite les conflits de synchronisation des numéros de série et des licences avec l’ancien appareil encore enregistré.

Remplacer l’Auxiliary après un RMA

Le remplacement ou reimage d’un nœud provoque une interruption planifiée. Les procédures suivantes s’appliquent à Active-Passive ; pour Active-Active, planifier la procédure exacte avec Sophos Support. Les deux variantes RMA détaillées supposent que le nœud sain restant fonctionne déjà en Standalone HA : le Primary sain pour le RMA de l’Auxiliary, l’Auxiliary sain pour le RMA du Primary. C’est uniquement pour cet état initial que les sources décrivent la revendication de l’appareil de remplacement et le transfert de licence avant la désactivation de HA ou la réinitialisation ultérieure du nœud sain, selon le cas. Ne pas appliquer cet ordre au remplacement dans une paire HA encore fonctionnelle ; l’exigence générale de désactivation préalable des FAQ s’y applique. Si l’état initial ne correspond pas ou reste incertain, arrêter avant le remplacement ou le transfert de licence et planifier la procédure avec Sophos Support.

1. Vérifier que le modèle et la révision matérielle de l’appareil de remplacement conviennent et installer exactement le même firmware build que sur le Primary sain.
2. Préparer d’abord l’accès local à l’appareil de remplacement. Dans l’exemple documenté de connexion aux ports, connecter un poste d’administration capable d’obtenir une adresse par DHCP au port 1 et ouvrir https://172.16.16.16:4444 ; connecter le WAN au port 2 et le configurer pour l’accès Internet dans le Setup Assistant. Si la disposition des ports diffère, utiliser les ports d’administration et WAN correspondant au modèle de l’appareil. Ne configurer aucune autre interface. Revendiquer seulement ensuite l’appareil de remplacement dans Sophos Fusion et transférer la licence de l’appareil Auxiliary défectueux.
3. Déplacer les câbles de l’appareil défectueux vers l’appareil de remplacement.
4. Sur le Primary sain, désactiver HA sous System services > High availability.
5. Dans l’Advanced Shell, vérifier que msync est arrêté :

service -S | grep msync

L’état attendu est UNTOUCHED ou STOPPED. La commande ne modifie rien ; un autre état signifie que HA ne doit pas encore être reconstruit. Reconfigurer ensuite le Primary sain comme Primary et l’appareil de remplacement comme Auxiliary.

Remplacer le Primary après un RMA

1. Télécharger une sauvegarde actuelle depuis l’Auxiliary sain et désenregistrer cet appareil de Sophos Fusion. Dans le même tenant Sophos Central/Fusion, sous My Products > Firewall Management > Firewalls, vérifier que l’entrée de cet Auxiliary sain n’est plus présente avant de poursuivre.
2. Installer le même firmware build sur l’appareil de remplacement et se connecter localement. Dans l’exemple documenté de connexion aux ports, connecter un poste d’administration capable d’obtenir une adresse par DHCP au port 1 et ouvrir https://172.16.16.16:4444 ; configurer le WAN connecté au port 2 pour l’accès Internet dans le Setup Assistant. Si la disposition des ports diffère, utiliser les ports d’administration et WAN correspondant au modèle de l’appareil. Ne configurer aucune autre interface. Revendiquer seulement ensuite l’appareil dans Sophos Fusion et transférer la licence du Primary défectueux.
3. Restaurer la sauvegarde sur l’appareil de remplacement.
4. Déplacer les câbles de l’Auxiliary sain vers l’appareil de remplacement. À partir de ce moment, l’appareil de remplacement traite le trafic comme firewall autonome.
5. Réinitialiser l’ancien Auxiliary aux paramètres d’usine et préparer à nouveau l’accès local : dans l’exemple documenté de connexion aux ports, connecter un poste d’administration capable d’obtenir une adresse par DHCP au port 1 et ouvrir https://172.16.16.16:4444, puis configurer le WAN connecté au port 2 pour l’accès Internet dans le Setup Assistant. Si la disposition des ports diffère, utiliser les ports d’administration et WAN correspondant au modèle de l’appareil. Ne configurer aucune autre interface. Revendiquer seulement ensuite à nouveau l’appareil dans Sophos Fusion et connecter les câbles prévus.
6. Reconstruire HA avec l’appareil de remplacement comme Primary et l’appareil réinitialisé comme Auxiliary.

Avertissement : Sauvegarde/restauration, Factory Reset et les changements de câblage provoquent une interruption de service. Documenter les numéros de série, l’Initial Primary, le firmware build, le transfert de licence, l’état Central et la procédure de retour arrière avant de commencer.

Pour la réinstallation technique, voir Réinstaller Sophos Firewall OS : reimage avec une clé USB. En cas de panne matérielle ou de processus RMA, planifier également Préparer correctement une panne matérielle et un RMA Sophos.

Dépannage

Pour les pannes complexes, procéder méthodiquement : vérifier d’abord l’état, le lien HA, les Monitored Ports, la version du firmware et l’état des licences, puis analyser les cas particuliers ou les indications du fabricant. Cela permet de déterminer si le problème relève réellement de HA ou s’il est provoqué par les licences, une interface, le firmware ou la supervision.

Logs et emplacements de diagnostic importants

• État HA : System services > High availability.
• Event Logs : Log viewer > System.
• Troubleshooting Logs : Diagnostics > Tools > Troubleshooting logs > Select files ou via SSH sous /log.
• Détails HA par CLI : Voir l’unique vérification CLI sous Valider le cluster.
• Problèmes d’interface : show network interfaces, ifconfig, dmesg dans les cas de diagnostic adaptés.
• Titulaire de la licence : System services > High availability.

Les fichiers suivants sont particulièrement utiles pour un premier diagnostic :

• ha.log : Erreurs de création, création HA réussie et changements d’état.
• ha_pair.log : Détection du peer dans QuickHA.
• ha_tunnel.log : Tunnel SSH via le Dedicated HA link.
• msync.log : Synchronisation de la configuration HA.
• ctsyncd.log : Synchronisation des sessions Conntrack.
• filesync.log : Synchronisation de fichiers liée aux services, par exemple pour les routes dynamiques ou DHCP.

Chaque nœud stocke uniquement les logs et rapports du trafic qu’il traite. Pour accéder à l’Auxiliary, se connecter via son adresse Peer Admin ou consulter les fichiers logs par SSH sur ce nœud.

Pour une analyse approfondie, voir Dépannage CLI Sophos Firewall : commandes importantes.

Symptômes HA courants

• Le cluster ne se forme pas ; la version ou le build du firmware diffère : Vérifier la version sur les deux appareils et mettre les deux firewalls sur une version SFOS identique.

• Le cluster ne se forme pas ; le modèle ou l’appliance ne correspond pas : Vérifier le modèle et le numéro de série. Pour HA matériel, utiliser uniquement des modèles XGS Appliance identiques et compatibles.

• HA could not be enabled : Sophos documente ce message uniquement pour la configuration avec un nouveau HA spare virtuel décrite ci-dessus, immédiatement après Initiate HA sur le Primary et avant que le spare rejoigne le cluster ; l’état temporaire Standalone y est également décrit. Cela ne permet pas d’ignorer ce message dans tous les cas. S’il persiste après la fin de l’assistant du spare et la phase d’attente et d’actualisation, ou s’il apparaît dans une autre configuration, le Dedicated HA link n’est peut-être pas connecté ou le peer est inaccessible. S’assurer que les interfaces dédiées au lien HA des deux appareils sont connectées directement par un câble Ethernet ou via le switch prévu. Sur les deux nœuds, vérifier sous Network > Interfaces que l’interface sélectionnée pour le lien HA affiche Connected. Sur le Primary, utiliser l’outil Ping sous Diagnostics > Tools pour vérifier l’adresse IP du lien HA dédié de l’Auxiliary, et non son adresse Peer Admin. Les réponses confirment une connectivité de base, mais pas encore une synchronisation HA terminée. En l’absence de réponses, vérifier et corriger d’abord le câble, le chemin via les commutateurs, l’état du lien et l’adresse IP ainsi que le sous-réseau du lien HA ; répéter ensuite le ping et vérifier à nouveau les rôles et la synchronisation.

• Lien HA down : Le câble, switchport, VLAN ou LAG peut être défectueux. Vérifier l’état de l’interface, speed/duplex, VLAN trunk et les membres LAG.

• Les deux appareils passent en Standalone : Le lien HA est tombé et présente un risque split-brain. Vérifier la connexion physique et le chemin via les commutateurs, arrêter un appareil de manière contrôlée, réparer le lien HA puis redémarrer l’appareil.

• WebAdmin de l’Auxiliary inaccessible : Peer Admin Port, sous-réseau, route ou Device Access ne correspondent pas. Vérifier l’IP de l’Admin Port et l’accès depuis le réseau d’administration.

• Validation Failed For Ha interface IP : Sur le Primary, rechercher ce message exact dans /log/syslog.log. Sophos l’associe à des ports d’administration qui ne se trouvent pas dans le même sous-réseau ; comparer les adresses des ports d’administration des deux appareils. Vérifier également, comme prérequis distinct, que les adresses du lien HA se trouvent dans le même sous-réseau, sans considérer leur configuration comme une cause établie de ce message. Avant de corriger l’adressage d’administration, respecter le contrôle préalable décrit ci-dessus pour clarifier la contradiction entre les sources : documenter les rôles, le build SFOS installé, l’interface d’administration et les adresses IP actuelles, disposer d’une sauvegarde sécurisée et d’un accès d’administration indépendant par console ou accès local, puis vérifier le comportement d’adressage applicable ou le clarifier avec Sophos Support. Si le comportement reste incertain, arrêter avant toute modification des adresses.

• Failover inattendu : Un Monitored Port est souvent tombé ou mal sélectionné. Vérifier les Monitored Ports et l’état du switch, puis surveiller uniquement des ports réellement critiques et stables. Si le nœud concerné a réellement rebooté et n’a pas seulement changé de rôle, contrôler le redémarrage inattendu spécifiquement pour ce nœud.

• Le failover ne se produit pas : Le port concerné n’est probablement pas surveillé. Ajouter les ports WAN, core ou DMZ critiques comme Monitored Ports.

• Active-Active ne distribue pas comme prévu : Le type de trafic n’est peut-être pas load-balanced. Vérifier le type de connexion, le protocole et les logs des deux nœuds ; si le bénéfice n’est pas clair, utiliser Active-Passive ou adapter la conception.

• Des logs semblent manquer : Le trafic a peut-être été traité par l’autre nœud ou la journalisation n’est pas active. Vérifier les deux nœuds et Log Viewer, activer la journalisation dans les règles et utiliser Central Reporting ou syslog.

• Les rapports diffèrent : Les rapports locaux dépendent du nœud. Comparer les rapports des deux appareils ou utiliser Sophos Central Firewall Reporting.

• Problème de licence en Active-Active : Les types de licence ne correspondent peut-être pas. Vérifier Licensing sur les deux firewalls et aligner les licences.

• Problèmes après une mise à jour du firmware : Un nœud n’a peut-être pas été correctement mis à jour ou le cluster n’est pas synchronisé. Vérifier l’état HA, les versions et les logs ; utiliser une fenêtre de maintenance pour les clusters de production et impliquer Sophos Support.

• Le lien HA Flexi Port ne fonctionne plus après une mise à jour : Sur les modèles 1U XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 et XGS 4500, HA peut ne pas s’établir lorsqu’un Flexi Port sert de Dedicated HA link. Après la mise à jour et le redémarrage du premier appareil, son Interface speed n’est plus réglé sur Auto negotiation, tandis que le second utilise toujours Auto negotiation.

  Avant de modifier le réglage : Documenter les rôles HA et les réglages des ports des deux appareils, disposer d’une sauvegarde et d’un accès d’administration indépendant, et prévoir une fenêtre de maintenance. En cas de split-brain, suivre d’abord la procédure de panne du lien HA ci-dessous : décider quel nœud doit rester actif et déconnecter l’autre du réseau de production ou l’arrêter de manière contrôlée. Ne pas redémarrer les deux nœuds sans coordination.

  1. Sur les deux appareils, ouvrir Network > Interfaces.
  2. Sélectionner l’interface Flexi Port concernée et ouvrir Advanced settings.
  3. Régler Interface speed sur Auto negotiation.

Vérifier ensuite l’état du lien, les rôles HA, la synchronisation et le trafic de production. Si le problème persiste, sauvegarder les réglages et les logs des deux nœuds et faire appel à Sophos Support. Ne rétablir les valeurs précédentes documentées que dans le cadre d’une modification contrôlée, avec un accès d’administration assuré ; cela peut faire réapparaître la panne du lien HA. Il est également possible de prévoir un port intégré comme Dedicated HA link, et non une vitesse fixe.

WebAdmin et VPN Portal inaccessibles lors de la synchronisation des certificats

Les notes de version de SFOS 22.0 MR3 Build 576 du 16 octobre 2026 indiquent que NC-186809 est corrigé : sur l’Auxiliary, la synchronisation des certificats pouvait échouer lorsque certains noms de fichiers de certificat commençaient par deux points consécutifs (..), rendant WebAdmin et VPN Portal inaccessibles. Distinguer ces symptômes des problèmes généraux de routage ou de Device Access, puis conserver le build, le nœud concerné, l’heure et les logs de synchronisation disponibles. Ne pas renommer ni supprimer des certificats sur un simple soupçon. Si les symptômes correspondent, solliciter le support et planifier un changement de firmware pris en charge avec un accès de gestion assuré ; contrôler ensuite les deux portails et la synchronisation HA.

Procédure en cas de panne du lien HA

Si le lien HA dédié tombe en panne, procéder avec prudence. Les firewalls ne se voient plus mutuellement. Dans le pire des cas, les deux appareils envoient ARP/GARP et tentent de revendiquer la MAC du cluster.

Procédure sûre :

1. Stabiliser l’état du réseau.
2. Décider quel appareil doit rester actif.
3. Arrêter l’autre appareil de manière contrôlée ou le déconnecter du réseau de production.
4. Réparer le câble, switchport, VLAN ou LAG du lien HA.
5. Redémarrer l’appareil.
6. Vérifier l’état HA.
7. Vérifier les logs et les rôles.

Commandes CLI supplémentaires

En plus de la consultation de l’état HA sous Valider le cluster, la commande en lecture seule suivante dans la Device Console affiche l’état des interfaces et des liens :

show network interfaces

Des états UP sont attendus pour le Dedicated HA link et les Monitored Ports connectés.

Dans la même sortie de show network interfaces, rechercher l’interface physique concernée à l’aide de son nom réel et vérifier, en plus de l’état du lien, les compteurs disponibles de pertes de paquets (Drops), d’erreurs et de collisions. Tous les builds n’affichent pas tous les compteurs ; une information absente ne correspond pas à une valeur nulle. Enregistrer la sortie avec le nœud, l’interface et un horodatage, puis la comparer à une observation ultérieure : des compteurs en hausse aident à circonscrire les problèmes d’interface, de câble ou de négociation, mais ne prouvent pas à eux seuls une cause précise. Remplacer le câble ou corriger la vitesse et le duplex uniquement de manière contrôlée, avec un accès d’administration assuré et les précautions HA et split-brain décrites ci-dessus ; comparer ensuite à nouveau les compteurs, l’état du lien, les rôles et la synchronisation. Ces compteurs d’interface doivent être distingués des paquets rejetés par les règles de firewall et de leur Drop Capture.

Pour les instabilités de liaison, accéder à l’Advanced Shell via Device Management > Advanced Shell et remplacer PortE par le nom réel de l’interface :

dmesg | grep PortE

La sortie filtre les messages du noyau pour cette interface. Des montées et coupures de lien répétées indiquent des problèmes de câble, de module optique, de port ou de négociation. La commande ne modifie rien, mais dmesg ne contient que le tampon actuel du noyau et ne remplace pas une analyse des logs à long terme.

Le diagnostic physique complet avec ethtool, les données du module et les cas particuliers connus est expliqué dans Choisir et vérifier SFP et SFP+ sur Sophos Firewall.

Avant toute intervention plus approfondie, sauvegarder d’abord les sorties et les timestamps.

Checklist de mise en production

• Active-Passive ou Active-Active choisi avec une justification documentée.
• Modèles, Flexi Ports, SFOS build, état LINCE, revendication et licences vérifiés.
• Sauvegarde et procédure de retour arrière disponibles.
• Dedicated HA link libre, stable et connecté aussi directement que possible.
• VLANs, LAGs, switchports et RSTP cohérents des deux côtés.
• Accès Peer Admin à l’Auxiliary testé.
• Uniquement des interfaces stables et critiques sélectionnées comme Monitored Ports.
• Cluster ID, Initial Primary, Preferred primary et numéros de série documentés.
• WebAdmin, état CLI et logs pertinents vérifiés.
• LAN, Internet, serveurs, VPN, DNAT/WAF, DNS et DHCP testés fonctionnellement.
• Failover et retour testés pendant une fenêtre de maintenance.
• Processus de supervision, firmware, restauration et RMA consignés dans le runbook.

FAQ