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, les deux appareils, les builds du firmware, les licences, le câblage et l’accès d’administration doivent correspondre.

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 entièrement synchronisés entre les 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 provenant d’adresses IP source paires sont généralement traitées par le Primary, tandis que les adresses impaires sont envoyées à l’Auxiliary. Les connexions TCP transférées ou traduites sont distribuées, y compris 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. Le trafic non-TCP, SD-RED et tunnelisé, ainsi que les connexions Layer 7 via DPI ou proxy, notamment SMTP Proxy, HTTPS, FTP analysé et H.323, ne sont pas distribués. Sophos ne prend pas en charge les load balancers externes devant le cluster pour cette logique 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 HA est utilisée, les interfaces de production utilisent des adresses MAC virtuelles. Seul le Primary répond aux requêtes ARP du cluster. Lors d’un failover, l’Auxiliary reprend cette adresse MAC virtuelle. 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.
• Secure Storage Master Key et identifiants WebAdmin sont synchronisés.
• Le Dedicated HA link n’est pas synchronisé comme une configuration d’interface de production normale.
• Le Peer Admin Port est traité séparément et n’est pas synchronisé comme une interface normale.
• Logs et rapports ne sont pas synchronisés entre les appareils.

Comportement du failover

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 une Sophos Firewall en mode Failsafe présente la commande de diagnostic en lecture seule 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.

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

Lorsque l’Initial Primary revient, il reste Auxiliary si Preferred primary n’est pas sélectionné. S’il s’agit du Preferred primary, SFOS synchronise d’abord les services puis effectue automatiquement le retour. L’appareil qui fonctionnait seul redémarre pendant cette opération. Ce failback doit donc être planifié dans une fenêtre de maintenance, même si le cluster reste généralement disponible pendant l’opération.

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.

• Plateforme : Même type d’appliance et même plateforme SFOS.
• Hypervisor : Même type d’hypervisor.
• Ressources : Même nombre de cœurs CPU, ressources comparables et 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 passive.

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 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. Désactiver HA de manière planifiée sur le Primary actuel, transférer les abonnements de l’Auxiliary vers le Primary dans Sophos Fusion, 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 ou PPPoE, mais ces connexions ne bénéficient pas du basculement 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.

Configurer les breakout interfaces sur le Primary. Redémarrer d’abord le Primary pour appliquer la modification, puis redémarrer l’Auxiliary. Si le Primary ne possède pas la configuration breakout correspondante, la synchronisation supprime une configuration breakout présente uniquement sur l’Auxiliary.

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 à l’Auxiliary Firewall. Les deux nœuds utilisent le même réseau d’administration. SFOS synchronise toutefois la configuration normale de l’interface, y compris l’adresse IP PortMGMT, du Primary vers l’Auxiliary ; cette adresse IP ne peut donc pas être différente par nœud. Le paramètre Peer Administration séparé attribue à l’Auxiliary une adresse IP d’administration supplémentaire et distincte dans le même sous-réseau. QuickHA utilise automatiquement l’interface de la session WebAdmin actuelle. Une fois HA établi, l’Auxiliary est accessible uniquement via cette adresse Peer Admin depuis le sous-réseau correspondant.

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 une vitesse et un duplex identiques des deux côtés sous Network > Interfaces > Advanced settings. Utiliser ensuite Show recommended settings > Load recommended configuration pour la négociation et Forward Error Correction (FEC). Si les recommandations sont vides, désactiver Auto-negotiation pour Media Type et FEC. Pour les autres ports, utiliser Automatic ou des valeurs speed/duplex identiques, et conserver les valeurs MTU et MSS par défaut. Lorsque QuickHA choisit une interface non liée, SFOS réinitialise ses Advanced settings ; les vérifier à nouveau 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 effectue une réinitialisation; 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 :

• Admin Ports dans le même sous-réseau, mais avec des adresses IP différentes : Sinon, HA ne peut pas être correctement établi ou l’Auxiliary ne sera pas accessible ensuite.
• 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. Après le remplacement d’un appareil, HA doit donc être désactivé et reconfiguré.

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.

Les étapes suivantes suivent la configuration HA officielle de Sophos, mais sont volontairement formulées comme checklist pratique pour administrateurs. 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.

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 éventuellement un nom de nœud, 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 éventuellement un nom de nœud, 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 :

• É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. 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.

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.
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 une adresse IP dédiée pour FW02.
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.

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. 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 préparer Active-Passive en Interactive mode. Documenter le Dedicated HA Link, l’adresse IP du peer, Peer Administration et la passphrase HA. Le Primary peut afficher Standalone jusqu’à ce que le nouvel Auxiliary rejoigne le cluster.
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, la même interface Dedicated HA Link et une adresse IP libre avec le même masque de sous-réseau.
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 publie deux contrôles HA supplémentaires. Les deux sont lus 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 elle-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 sont considérés comme une interface dynamique 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 elle-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. Elle 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.

Pour les événements HA, ouvrir Log viewer > System séparément sur chaque nœud et filtrer la période concernée. Pour une analyse détaillée, ouvrir Diagnostics > Tools > Troubleshooting logs > Select files sur les deux appareils, sélectionner au minimum csc.log, puis enregistrer séparément chaque paquet avec Download. Seule la comparaison des deux nœuds montre la séquence complète du cluster.

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 que sur un nœud, 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’un simple commutateur.

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

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 :

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 mise à 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 réagir brièvement.

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 :

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, ces procédures s’appliquent uniquement à Active-Passive. Exécuter d’abord 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.

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.

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. Revendiquer 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 l’appareil de Sophos Fusion.
2. Mettre l’appareil de remplacement au même firmware build, le revendiquer 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 Factory Settings, le revendiquer à nouveau 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 le supervision.

Logs et emplacements de diagnostic importants

• État HA : System services > High availability.
• Event Logs : Log viewer > System.
• Troubleshooting Logs : Monitor & Analyze > Logs > Troubleshooting logs 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 : Le Dedicated HA link n’est peut-être pas connecté ou le peer est inaccessible. Vérifier l’état du port, le câble, le switch et le ping vers l’IP du lien HA, puis stabiliser le câblage ou le lien HA.

• 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 : Les Admin Ports ou les adresses du lien HA ne se trouvent pas dans le sous-réseau attendu. Vérifier les adresses IP et /log/syslog.log, puis corriger l’adressage.

• 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 le journalisation n’est pas actif. Vérifier les deux nœuds et Log Viewer, activer le 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. Cette modification a été vérifiée dans la documentation, mais n’a pas été testée sur un appareil.

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

show network interfaces

l’état des interfaces et des liens. Des états UP sont attendus pour le Dedicated HA link et les Monitored Ports connectés.

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. Les commandes ont été vérifiées par rapport à la documentation Sophos actuelle, mais n’ont pas été exécutées sur le matériel spécifique du client.

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