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

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.

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.
• Lors d’un failover, l’Auxiliary Firewall prend le relais avec la même adresse MAC virtuelle.
• En règle générale, les équipements réseau ne doivent 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 notamment 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 peuvent être envoyées à l’Auxiliary. Les connexions TCP transférées ou traduites sont distribuées. 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.
• 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.

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

Sophos Firewall utilise des adresses MAC virtuelles pour les interfaces de production d’un cluster HA. 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.

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

Les heartbeats transitent par le lien HA dédié. Des intervalles très courts sont utilisés par défaut. Si plusieurs heartbeats consécutifs sont absents, le peer est considéré comme inaccessible. Le firewall évalue alors l’état et effectue le changement de rôle.

De nombreuses connexions continuent ou sont rapidement rétablies pendant un failover. Le processus n’est toutefois pas entièrement transparent pour toutes les applications. Les connexions TCP stateful, sessions web, connexions proxy et certains scénarios VPN peuvent notamment être brièvement interrompus ou devoir être rétablis.

Services pris en charge et limités

Sophos HA prend en charge la plupart des services du firewall, mais certains présentent des particularités.

• Règles de firewall et NAT sont synchronisées. En Active-Active, il faut savoir quel nœud traite une connexion.
• VPN fonctionne dans de nombreux scénarios HA, mais tous les types de session ne basculent pas sans interruption. IPsec peut mieux reprendre le trafic UDP/ICMP stateless que le trafic TCP stateful.
• Web Protection fonctionne dans le cluster. En Active-Active, des alertes peuvent provenir des deux nœuds.
• Email Protection peut gérer la quarantaine et les validations par nœud, car chaque appareil stocke ses propres données pour le trafic email traité.
• Synchronized Application Control ne convient pas à Active-Active si la fonction n’est pas prise en charge dans la version SFOS utilisée.
• NDR Essentials ne doit être planifié qu’avec Active-Passive dans les environnements HA.
• sFlow fonctionne uniquement sur le Primary dans les environnements HA.
• Rapports sont générés localement sur chaque appareil. Sophos Central Firewall Reporting est plus adapté aux rapports consolidés.
• Cellular WAN doit être désactivé pour HA.
• Les modèles XGS Wi-Fi ne prennent pas en charge HA.

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.

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, 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.
• Modèles XGS Wi-Fi : Non pris en charge. Par exemple XGS 126w et XGS 136w.
• Flexi Port Modules : Si des modules d’extension sont utilisés, les deux appareils doivent disposer du même nombre de Flexi Ports.
• 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.

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 appliance XGS 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.

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.

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. Les appliances Virtual/Software doivent être licenciées en conséquence.
• 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 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 : Le statut de support est important pour le remplacement du matériel et Advance Replacement. Pour le matériel Active-Passive, Sophos indique Enhanced Plus Support sur le Primary comme prérequis pertinent pour Advance Hardware Replacement. En Active-Active, le statut de support doit être adapté sur les deux appareils.

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.

Si les licences Active-Active diffèrent, le load balancing s’arrête pendant un maximum de trois jours. Si la différence persiste, le firewall désactive HA. Lors de la configuration initiale, Active-Active n’est pas activé si les licences ne correspondent pas.

L’Initial Primary doit synchroniser les licences 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.

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 pour la dernière fois
• 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.

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 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 ports d’administration des deux appareils doivent se trouver dans le même sous-réseau, avec des adresses IP différentes. QuickHA utilise automatiquement l’interface par laquelle la session WebAdmin actuelle est connectée. Une fois HA établi, l’Auxiliary est accessible uniquement via l’adresse Peer Admin depuis un réseau approprié.

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.

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

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.

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 é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 Central, 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.

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

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.
6. Sous Peer administration settings, indiquer l’interface d’administration et une adresse IP dédiée pour FW02.
7. Pour les appliances virtuelles, sélectionner si nécessaire l’adresse MAC attribuée par l’hôte ou l’hypervisor. Une modification ultérieure 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. Par défaut, le firewall envoie un heartbeat toutes les 250 millisecondes et considère le peer comme inaccessible après 16 heartbeats manquants.

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 en priorité l’Initial Primary titulaire de la licence sous System services > High availability. Dans un cas de support documenté, la valeur interne en lecture seule suivante dans l’Advanced Shell peut apporter une information supplémentaire :

nvram get "#li.master"

YES identifie généralement l’Initial Primary et NO l’Auxiliary. Sophos ne documente pas cette commande Advanced Shell interne comme interface d’administration normale ; la vue HA reste donc la référence.

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 Central, 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.

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.

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.

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

Les sauvegardes et la restauration présentent des particularités dans les environnements HA :

• Créer des sauvegardes régulièrement et avant chaque modification importante.
• Effectuer la restauration sur le Primary Firewall actuel.
• Après une restauration, les deux firewalls sont désenregistrés de Sophos Central et doivent être enregistrés à nouveau.
• Une restauration provoque un redémarrage et une interruption de service, pas un failover normal.
• La restauration d’une sauvegarde sans configuration HA sur un cluster HA désactive HA, qui doit ensuite être reconstruit.
• Si LINCE est activé, la sauvegarde et le cluster cible doivent avoir le même état LINCE.

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 Central 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 Central.
2. Mettre l’appareil de remplacement au même firmware build, le revendiquer dans Sophos Central 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 Central 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 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.
• 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 pas : Speed/duplex ou auto-negotiation ne correspondent peut-être pas. Vérifier Interface Advanced settings sur les deux appareils et configurer les deux côtés à l’identique ou utiliser un port fixe.

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.

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

Sources officielles : Enregistrement et licences · LINCE dans les environnements HA · RMA dans un cluster Active-Passive