Configurer la Haute Disponibilité (HA) sur Sophos Firewall

La Haute Disponibilité, ou HA, connecte deux Sophos Firewalls en un cluster. L’objectif n’est pas de rendre un seul pare-feu indestructible, mais de gérer de manière contrôlée la panne d’un appareil, de certains ports critiques ou des opérations de maintenance planifiées.

Un environnement HA ne remplace pas une bonne conception de réseau, des sauvegardes propres et des processus de maintenance documentés. Un cluster mal planifié peut être plus difficile à gérer en cas de panne qu’un seul pare-feu. Cet article explique donc non seulement où activer HA, mais aussi comment planifier, configurer, exploiter et vérifier un cluster HA Sophos Firewall de manière judicieuse.

Table des matières

• Résumé rapide
• Guides vidéo
• Ce que signifie la Haute Disponibilité sur Sophos Firewall
• Active-Passive ou Active-Active
• Rôles, statut et architecture
• Prérequis
• Planification et conception
• Préparer la configuration
• Configurer Active-Passive avec QuickHA
• Configurer Active-Active avec QuickHA
• Configuration manuelle de HA
• Valider le cluster
• Exploitation et maintenance
• Mises à jour du firmware et sauvegardes
• Dépannage
• Listes de vérification des meilleures pratiques

Résumé rapide

Dans la plupart des environnements de production, Active-Passive est la meilleure option HA. Un pare-feu traite tout le trafic, le second est prêt à prendre le relais en cas de panne ou de maintenance. La conception est plus simple, la licence est moins coûteuse et le comportement en cas de panne est plus facile à comprendre.

Active-Active n’est utile que si l’on accepte consciemment ses limites et restrictions. Ce n’est pas un équilibrage de charge symétrique classique où les deux pare-feux sont égaux à tous les niveaux du réseau. Le pare-feu principal continue de recevoir le trafic et distribue certaines connexions au pare-feu auxiliaire. Tous les services et types de trafic ne sont pas distribués.

Comme orientation rapide :

• Stabilité maximale et exploitation simple : Active-Passive.
• Utiliser la seconde firewall sans licence de protection séparée : Active-Passive.
• Besoin de plus de débit pour certaines connexions TCP : examiner Active-Active.
• Nombreux cas VPN, proxy, RED, NDR ou particuliers : préférer Active-Passive.
• Petit ou moyen environnement sans problème de performance clair : Active-Passive.
• Exigence de performance claire et licence adaptée pour les deux appliances : Active-Active après test.

Guides vidéo

Les Sophos Techvids suivants montrent visuellement la HA sur Sophos Firewall. Les vidéos ne remplacent pas une planification propre, mais elles aident à mieux comprendre QuickHA, les rôles, les statuts et le comportement de base d’un cluster HA.

Ce que signifie la Haute Disponibilité sur Sophos Firewall

Un cluster HA Sophos Firewall se compose de deux pare-feux. Les appareils échangent des heartbeats, des statuts d’appareil, des informations de connexion et des données de configuration via un lien HA dédié. La configuration est synchronisée de la Primary Firewall à la Auxiliary Firewall.

HA protège contre les pannes typiques :

• Panne du Primary Firewall
• Panne de courant ou matériel
• Panne d’une interface surveillée
• Problème logiciel ou de service rendant un appareil inutilisable
• Mises à jour de firmware planifiées
• Changement de rôle planifié lors de la maintenance

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

• Une règle de pare-feu incorrecte reste incorrecte même dans un cluster.
• Une panne de commutateur commun peut affecter les deux pare-feux simultanément.
• Un design VLAN défectueux ou un concept de routage erroné ne sera pas automatiquement corrigé.
• Les journaux et rapports ne sont pas entièrement synchronisés entre les deux pare-feux.
• Une sauvegarde reste obligatoire.

Avant de planifier HA, il est important de clarifier les bases pour les zones, interfaces, VLANs, LAGs et ponts. Consultez le guide Planifier et configurer les zones et interfaces Sophos Firewall.

Active-Passive ou Active-Active

Active-Passive

En mode Active-Passive, un pare-feu traite tout le trafic productif. Le second pare-feu est passif et ne prend le relais que si le pare-feu actif tombe en panne ou si un basculement est déclenché manuellement ou par maintenance.

Caractéristiques typiques :

• Le Primary Firewall traite le trafic.
• Le Auxiliary Firewall reste en veille.
• Les sessions sont synchronisées dans la mesure où le service le permet.
• Seul l’appareil titulaire de la licence nécessite les abonnements de protection pour les appliances matérielles.
• Le Auxiliary Firewall prend le relais en cas de basculement avec la même adresse MAC virtuelle.
• Les appareils réseau n’ont généralement pas besoin de réapprendre leurs voisins.

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

Active-Active

En mode Active-Active, les deux pare-feux traitent le trafic. Cependant, l’architecture reste asymétrique : le Primary Firewall reçoit le trafic et décide s’il traite une connexion lui-même ou la transmet au Auxiliary Firewall.

Sophos utilise notamment l’adresse IP source pour la distribution. Les connexions TCP provenant d’adresses IP sources paires sont généralement traitées sur le Primary, tandis que les adresses IP sources impaires peuvent être transmises au Auxiliary. Le trafic non-TCP et certains services ne sont pas distribués de manière égale.

Caractéristiques typiques :

• Les deux pare-feux peuvent traiter le trafic.
• Le Primary Firewall reste le point d’entrée central.
• Les deux pare-feux nécessitent des licences appropriées.
• Tous les services ne sont pas distribués.
• Les journaux et rapports sont générés sur l’appareil qui traite le trafic respectif.
• Le dépannage est plus complexe car les connexions peuvent atterrir sur les deux nœuds.

Active-Active est pertinent lorsqu’il existe un objectif de performance clair et que l’on a testé au préalable si le trafic pertinent est effectivement distribué. Pour une haute disponibilité pure, Active-Passive est généralement plus propre.

Rôles, statut et architecture

Rôles dans le cluster HA

Statuts en exploitation

Adresse MAC virtuelle

Le Sophos Firewall utilise des adresses MAC virtuelles pour les interfaces productives dans le cluster HA. Seul le Primary répond aux requêtes ARP pour le cluster. En cas de basculement, le Auxiliary prend cette adresse MAC virtuelle. Cela maintient la stabilité de l’accessibilité pour les commutateurs, routeurs et clients, car l’association IP et MAC ne change pas fondamentalement.

L’ID de cluster est important. Cet ID est utilisé pour l’adresse MAC virtuelle. Si plusieurs clusters HA sont exploités dans le même environnement de couche 2, chaque cluster doit avoir un ID de cluster unique. Sinon, des conflits MAC peuvent survenir.

Ce qui est synchronisé

• Règles de pare-feu, policies, objets, routage et configuration CLI sont synchronisés du Primary vers le Auxiliary.
• Sessions actives sont synchronisées selon le protocole et le service.
• Secure Storage Master Key et identifiants WebAdmin sont synchronisés.
• Dedicated HA link n’est pas synchronisé comme une configuration d’interface productive normale.
• Peer Admin Port est traité séparément et non comme une interface normale.
• Logs et reports ne sont pas synchronisés entre les appareils.

Comportement de basculement

Un basculement peut être déclenché par divers événements :

• absence de heartbeats sur le lien HA
• panne d’un port surveillé
• panne de courant
• panne matérielle
• problème logiciel ou de service
• changement de rôle planifié
• mise à jour du firmware

Les heartbeats passent par le lien HA dédié. Par défaut, des intervalles très courts sont utilisés. Si plusieurs heartbeats consécutifs manquent, le pair est considéré comme inaccessible. Ensuite, le pare-feu vérifie l’état et effectue le changement de rôle.

Lors d’un basculement, de nombreuses connexions sont maintenues ou rapidement rétablies. Cependant, un basculement n’est pas complètement transparent pour chaque application. En particulier, les connexions TCP avec état, les sessions Web, les connexions proxy ou certains scénarios VPN peuvent être brièvement interrompus ou nécessiter un nouveau démarrage.

Équilibrage de charge en Active-Active

Active-Active ne signifie pas que les deux pare-feux se tiennent comme deux routeurs égaux dans le réseau. Le Primary Firewall reste le point d’entrée central et distribue certaines connexions au Auxiliary Firewall.

Points importants :

• L’équilibrage de charge n’existe qu’en Active-Active.
• La méthode ne peut pas être librement ajustée.
• Les équilibreurs de charge externes devant un cluster HA ne sont pas utilisés comme design standard par Sophos pour cette logique HA.
• Tout le trafic n’est pas distribué.
• Le trafic non-TCP, SD-RED, le trafic tunnelé et certaines fonctions de couche 7 peuvent être traités différemment.
• Le dépannage doit inclure les deux nœuds.

En pratique, Active-Active ne doit être utilisé que si l’on sait à l’avance quel trafic crée le goulot d’étranglement et si ce trafic est effectivement distribué.

Services pris en charge et limités

Sophos HA prend en charge la plupart des services de pare-feu. Certains services ont cependant des particularités.

• Règles de pare-feu 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 sessions ne basculent pas sans interruption. IPsec peut mieux reprendre UDP/ICMP sans état que TCP avec état.
• Web Protection fonctionne dans le cluster. En Active-Active, des alertes peuvent provenir des deux nœuds.
• Email Protection peut avoir un comportement lié au nœud pour quarantaine et libération, car chaque appareil stocke ses propres données pour le trafic mail traité.
• Synchronized Application Control n’est pas adapté à Active-Active si la fonction n’est pas prise en charge dans la version SFOS utilisée.
• NDR Essentials doit être planifié uniquement avec Active-Passive en environnement HA.
• sFlow fonctionne en HA uniquement sur le Primary.
• Reports sont générés localement par appareil. Les reports consolidés sont plus utiles via Sophos Central Firewall Reporting.
• Cellular WAN doit être désactivé pour HA.
• Modèles XGS Wi-Fi ne prennent pas en charge HA.

Si les rapports ou la conservation des journaux sont importants, il est conseillé de planifier tôt si un serveur Syslog externe ou Sophos Central Firewall Reporting sera utilisé. Plus d’informations sont disponibles dans Activer le Central Firewall Reporting.

Prérequis

Avant la mise en œuvre, il est important de vérifier soigneusement les prérequis HA par rapport à votre environnement. En particulier, l’égalité des modèles, la version du firmware, les interfaces, le WAN cellulaire et les plateformes virtuelles sont des points où de petites différences peuvent avoir de grandes conséquences plus tard.

Compatibilité matérielle 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 : différentes révisions matérielles sont possibles avec le même modèle XGS.
• Modèles XGS Wi-Fi : non pris en charge. Exemples : XGS 126w ou XGS 136w.
• Modules Flexi Port : si des modules d’extension sont utilisés, le nombre de Flexi Ports doit être identique sur les deux appareils.
• Firmware : les deux appareils doivent utiliser la même version SFOS, y compris Maintenance Release et build.
• Appliance matérielle plus appliance virtuelle : non possible comme paire HA.

Appliances virtuelles et logicielles

Les appliances virtuelles ou logicielles doivent également être très bien assorties.

• Plateforme : même type d’appliance et même plateforme SFOS.
• Hyperviseur : même type d’hyperviseur.
• Ressources : mêmes 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 pour les adresses MAC attribuées par l’hyperviseur peut être pertinente afin d’éviter le mode promiscuité. Un changement provoque toutefois une interruption.

Déploiements Cloud

Dans les environnements Cloud, des exigences supplémentaires de plateforme s’appliquent. Le routage, les interfaces virtuelles, les adresses IP, les groupes de sécurité, les UDR ou les mécanismes de basculement spécifiques au Cloud doivent correspondre à la conception Cloud respective. L’approche HA normale de l’appliance ne peut pas être appliquée sans vérification préalable à Azure, AWS ou d’autres environnements Cloud.

Si un Sophos Firewall est exploité dans le Cloud, il est conseillé de vérifier la documentation Sophos actuelle pour la plateforme respective et l’architecture réseau Cloud avant de planifier HA.

Licence et enregistrement

La licence HA diffère selon la plateforme et le mode HA. Trois questions sont cruciales : s’agit-il de matériel ou de virtuel/logiciel ? Utilise-t-on Active-Passive ou Active-Active ? Et quel appareil est l’Initial Primary, c’est-à-dire l’appareil qui détient la licence pour le cluster ? Ces points doivent être vérifiés avant la mise en œuvre avec le statut de licence, les numéros de série et le mode cible.

Les points de licence les plus importants :

• Base Firewall : une licence Base Firewall est requise pour HA. Les appliances matérielles ont cette licence par défaut. Pour les appliances virtuelles/logiciels, elle doit être correctement licenciée.
• Active-Passive matériel : seul l’appareil Initial Primary nécessite les subscriptions productives. La Auxiliary Firewall reçoit une copie des subscriptions et peut traiter le trafic après un basculement.
• Active-Active matériel : les deux firewalls nécessitent leurs propres licences adaptées. Les types de licence doivent correspondre, les dates d’expiration peuvent être différentes.
• Active-Passive virtuel/logiciel : seul le Primary nécessite les licences nécessaires, y compris Base Firewall.
• Active-Active virtuel/logiciel : les deux appareils nécessitent une licence Base Firewall propre et d’autres licences de protection adaptées.
• Enregistrement matériel : les deux appareils matériels doivent être connus dans Sophos Central ou le portail de licences Sophos et pouvoir synchroniser leurs licences.
• Enregistrement virtuel/logiciel Active-Passive : en Active-Passive virtuel/logiciel, selon Sophos, seul le Primary est claimé.
• Sophos Central Management : synchronisation des licences et claiming ne signifient pas automatiquement que les firewalls sont aussi gérées via Sophos Central Firewall Management. Une subscription supplémentaire appropriée est nécessaire.
• RMA et support : pour remplacement matériel et Advance Replacement, le statut de support est important. En Active-Passive matériel, Sophos mentionne Enhanced Plus Support sur l’appareil Primary comme condition pertinente pour Advance Hardware Replacement. En Active-Active, le statut de support doit correspondre sur les deux appareils.

Important : En Active-Passive, l’Initial Primary est particulièrement important car cet appareil détient la licence pour le cluster. Dans la vue HA, l’appareil correspondant indique qu’il détient la licence pour le cluster. En cas de doute, l’appareil doit être clairement documenté dans le manuel d’exploitation.

Si les licences ne correspondent pas en Active-Active, selon Sophos, l’équilibrage de charge s’arrête d’abord. Si la divergence persiste, HA peut être désactivé. Lors d’une première configuration, Active-Active HA ne sera pas activé correctement avec des licences non correspondantes. Par conséquent, une vérification des licences est impérative dans la routine d’exploitation.

Pour les appliances virtuelles/logiciels, la licence Base Firewall est particulièrement critique. Si elle est désactivée ou si l’Initial Primary ne peut pas synchroniser la licence pendant une période prolongée, HA peut être désactivé et d’autres fonctions de protection deviennent inactives. Une synchronisation avec le serveur de licences est nécessaire au moins une fois tous les 90 jours. Pour les environnements de production, cela signifie que le cluster HA doit non seulement fonctionner techniquement, mais aussi pouvoir atteindre régulièrement le serveur de licences.

Pour l’exploitation, il est conseillé de documenter au moins :

• quel appareil est l’Initial Primary
• quels numéros de série ou IDs d’appliance appartiennent au cluster
• quelles licences sont actives sur quel appareil
• quand les licences ont été synchronisées pour la dernière fois
• quel niveau de support est disponible pour RMA ou remplacement avancé
• qui approuve les modifications de licence, les renouvellements et les processus RMA

Prérequis réseau

• HA-Link : connexion dédiée entre les deux firewalls, idéalement directement avec un câble Ethernet.
• Zone HA-Link : zone DMZ avec SSH activé pour la zone.
• Adresses IP HA-Link : adresses IP statiques dans le même sous-réseau, mais adresses différentes.
• Qualité HA-Link : bande passante élevée, faible latence, pas de perte de paquets.
• Commutateurs : activer RSTP sur les commutateurs connectés aux ports de la firewall.
• Monitored Ports : surveiller uniquement les ports réellement connectés et critiques.
• Cellular WAN : désactiver pour HA.
• Peer Admin Port : planifier séparément pour que la Auxiliary Firewall reste accessible.

Le lien HA ne traite pas le trafic client ou serveur normal. Il est uniquement pertinent pour les heartbeats, le statut, la synchronisation des sessions, la synchronisation des configurations et la distribution Active-Active. Cependant, il est extrêmement critique. Si le lien HA tombe en panne, les deux pare-feux peuvent croire qu’ils sont Primary. Il est essentiel d’éviter ce scénario de Split-Brain.

Le Peer Admin Port est un accès d’exploitation propre à la Auxiliary Firewall. Les ports d’administration des deux appareils doivent se trouver dans le même sous-réseau, mais utiliser des adresses IP différentes. Après la mise en place HA, la Auxiliary Firewall n’est accessible que via cette adresse Peer Admin et uniquement depuis un réseau adapté. Si les deux appareils utilisent encore la même IP par défaut ou si les ports admin se trouvent dans des sous-réseaux différents, HA échoue ou la Auxiliary n’est ensuite pas joignable proprement.

Ports et interfaces

• Dedicated HA link : sert aux heartbeats, au statut et à la synchronisation des configurations et sessions. Le connecter directement ou via un commutateur très fiable. Ne pas l’utiliser pour le trafic productif.
• Monitored ports : surveillent les liens productifs critiques. Surveiller WAN, DMZ importantes ou uplinks Core, mais ne pas sélectionner de ports inutilisés.
• Peer Admin Port : permet l’accès au Auxiliary WebAdmin. Planifier et documenter séparément ; le client doit être dans le sous-réseau adapté.
• Interfaces de production : câbler et concevoir LAN, WAN, DMZ, VLANs et LAGs de manière identique sur les deux firewalls.

En tant que lien HA dédié, des interfaces physiques, VLANs ou LAGs sont possibles. Les interfaces de pont et les adresses IP alias ne peuvent pas être utilisées comme lien HA dédié. Si un LAG est utilisé comme lien HA, les interfaces parent 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 est déjà utilisée dans une configuration productive et qu’elle est malgré tout sélectionnée comme HA-Link, la firewall peut modifier ou supprimer des configurations d’interface dépendantes. Le HA-Link doit donc être libre et documenté à l’avance.

Planification et conception

Topologie recommandée pour Active-Passive

Un design typique Active-Passive ressemble à ceci :

• les deux pare-feux sont dans le même rack ou dans des racks proches
• toutes les interfaces productives sont câblées de manière identique
• le WAN est connecté à des commutateurs redondants ou à des transitions de fournisseur bien documentées
• le LAN/DMZ est connecté à des structures de commutateurs redondantes
• le lien HA est connecté directement
• un accès de gestion ou d’administration séparé est prévu
• les ports WAN et Core/DMZ sont définis comme ports surveillés

Le point le plus important : le second pare-feu doit pouvoir prendre la même position réseau en cas de panne. Par conséquent, les VLANs, trunks, LAGs, ports de commutateur et connexions de fournisseur doivent être planifiés de manière cohérente.

Topologie recommandée pour Active-Active

Active-Active nécessite la même propreté physique qu’Active-Passive, mais aussi une attente claire concernant le trafic distribuable.

Avant Active-Active, il faut répondre :

• Quel trafic crée le goulot d’étranglement ?
• Ce trafic est-il effectivement distribué en Active-Active ?
• Les deux appliances sont-elles entièrement et correctement licenciées ?
• Les journaux, rapports et processus de dépannage sont-ils préparés pour les deux nœuds ?
• Existe-t-il des services comme VPN, NDR, Contrôle des applications synchronisé ou scénarios proxy qui vont à l’encontre d’Active-Active ?

Sans réponse claire, Active-Passive est le meilleur choix.

LAN, WAN, DMZ et lien HA

• LAN : zoner proprement les réseaux internes. Planifier les VLANs non seulement techniquement, mais aussi du point de vue sécurité.
• WAN : considérer séparément connexion fournisseur, passerelles de failover et SD-WAN. HA ne remplace pas un concept de redondance WAN.
• DMZ : garder les réseaux serveurs et les publications externes séparés des réseaux clients.
• HA-Link : connexion dédiée, adressée statiquement, zone DMZ, SSH autorisé pour DMZ. Ne pas faire passer de communication utilisateur ou serveur dessus.
• Management : restreindre consciemment accès admin, Device Access et ACLs.

Pour sécuriser les services locaux du pare-feu, consultez Sécuriser l’accès Sophos Firewall : configurer correctement Device Access.

Exigences des commutateurs

Les commutateurs sont souvent le facteur de risque invisible dans HA. Un cluster HA ne fonctionne que aussi bien que l’environnement de couche 2 en dessous.

Recommandations :

• Activer RSTP sur les commutateurs impliqués.
• Configurer les trunks de manière identique sur les deux pare-feux.
• Autoriser les VLANs de manière cohérente sur tous les ports impliqués.
• Construire les LAGs de manière identique.
• Ne pas sélectionner de ports surveillés à moitié finis ou inutilisés.
• Connecter le lien HA directement si possible.
• Si le lien HA passe par des commutateurs, le chemin doit être stable, à faible latence et sans perte de paquets.

VLANs, LAGs, ponts et RED

Les VLANs et LAGs sont possibles en HA, mais ils augmentent les exigences de planification. Le cluster HA ne doit pas être le premier endroit où un design VLAN ou LAG est testé.

• VLAN : planifier de manière identique sur les deux appareils. Tenir compte de l’interface parent. Un VLAN comme HA-Link est possible, mais uniquement avec un design très propre.
• LAG : utile pour les uplinks Core ou une connexion redondante aux commutateurs. Les interfaces parent doivent être cohérentes.
• Bridge : HA en Bridge Mode est pris en charge, mais rend le troubleshooting plus complexe. Pour les nouveaux designs, Gateway Mode est généralement plus transparent.
• RED : les scénarios RED et remote peuvent influencer HA, surtout si les réseaux sont étendus entre sites. Vérifier à l’avance performance, latence et symptômes d’erreur.
• VPN : le failover VPN fonctionne plus ou moins bien selon le protocole et le type de session. Tester IPsec et Remote Access séparément.

Éviter le Split-Brain

Le Split-Brain signifie que les deux pare-feux croient qu’ils sont actifs ou autonomes. Cela peut se produire si le lien HA tombe en panne, mais que les appareils restent dans le réseau de production.

Mesures :

• Ne pas faire passer le lien HA par des chemins de commutateur non sécurisés ou instables.
• Préférer la connexion directe pour le lien HA.
• Sélectionner consciemment les ports surveillés.
• Configurer RSTP proprement.
• Pas de câblage asymétrique.
• Vérifier le statut HA après chaque changement de commutateur ou de VLAN.
• Ajuster les valeurs de Keepalive uniquement avec raison.

Préparer la configuration

Avant de configurer HA, il ne faut pas improviser dans le réseau de production. Cette préparation permet de gagner beaucoup de temps par la suite.

Préparation des deux pare-feux

• Mettre les deux pare-feux à la même version SFOS, y compris le build.
• Vérifier le statut de licence et d’enregistrement.
• Désactiver le WAN cellulaire.
• S’assurer que les modèles sont compatibles.
• Vérifier l’équipement Flexi Port.
• Documenter les interfaces et les ports de commutateur.
• Définir le port de lien HA.
• Connecter directement le lien HA ou vérifier le chemin du commutateur.
• Prévoir la zone DMZ et l’accès SSH pour le lien HA.
• Documenter l’accès admin aux deux appareils.
• Créer une sauvegarde de la configuration existante.

Les sauvegardes ne sont pas facultatives en HA. Avant la configuration, avant les mises à jour du firmware et avant les modifications importantes des interfaces, une sauvegarde doit être disponible. Les bases sont expliquées dans Créer ou restaurer une sauvegarde Sophos Firewall.

Avant de cliquer sur Initiate HA, il faut aussi vérifier :

• Ports admin dans le même sous-réseau, mais avec des IP différentes : sinon HA ne peut pas être construit proprement ou la Auxiliary ne sera pas joignable ensuite.
• Dedicated HA link sans dépendances productives : HA peut modifier des adresses IP d’interface et des configurations dépendantes.
• Monitored Ports connectés sur les deux appareils : un Monitored Port non connecté peut empêcher le cluster ou déclencher immédiatement un failover.
• Cluster ID unique : plusieurs clusters HA dans le même domaine Layer 2 nécessitent des MAC virtuelles différentes.
• Backup, SSMK et firmware build documentés : en cas de Restore, RMA ou Reimage, le cluster doit être reproductible.

QuickHA ou configuration manuelle

• QuickHA : cas standard. Rapide, robuste et suffisant pour la plupart des configurations Active-Passive et Active-Active.
• Configuration manuelle : utile lorsque ports admin, HA-Link, Cluster ID, adresses peer et valeurs détaillées doivent être définis consciemment.

QuickHA reconnaît le pair via les interfaces de lien HA choisies. Une fois que les appareils se sont trouvés, le cluster est construit. La phrase de passe est utilisée pour établir le tunnel SSH chiffré et n’est pas traitée comme un mot de passe réutilisable. Si un appareil est remplacé, HA doit être désactivé et reconfiguré.

Les étapes décrites ici s’inspirent de la configuration HA officielle de Sophos, mais sont délibérément formulées comme une liste de contrôle pratique pour les administrateurs. Pour les modifications productives, il ne suffit pas de cliquer sur l’assistant, mais il faut documenter à l’avance les rôles, le lien HA, l’accès admin, la sauvegarde, le statut de licence et le retour.

Configurer Active-Passive avec QuickHA

1. Préparer le Primary Firewall

1. Se connecter au WebAdmin sur le futur Primary Firewall.
2. Aller à System services > High availability.
3. Choisir le mode Primary (active-passive).
4. Utiliser QuickHA.
5. Optionnellement, attribuer un nom de nœud, par exemple FW01.
6. Définir une phrase de passe HA.
7. Enregistrer la phrase de passe en toute sécurité, car elle sera nécessaire sur le Auxiliary Firewall.
8. Sélectionner le lien HA dédié.
9. Démarrer Initiate HA.

Remarques :

• Le lien HA ne doit pas avoir de dépendances productives.
• Si QuickHA utilise une interface non liée, Sophos attribue à cette interface la zone DMZ et applique des paramètres spécifiques à HA.
• Le lien HA utilise des adresses IP statiques dans la plage Link-Local si QuickHA utilise les valeurs par défaut.
• SSH doit être autorisé pour la zone de lien HA, car le tunnel HA est établi dessus.

2. Préparer le Auxiliary Firewall

1. Se connecter au futur Auxiliary Firewall.
2. Aller à System services > High availability.
3. Choisir le rôle Auxiliary.
4. Utiliser QuickHA.
5. Optionnellement, attribuer un nom de nœud, par exemple FW02.
6. Entrer la même phrase de passe HA.
7. Sélectionner le même port de lien HA que sur le côté Primary.
8. Démarrer Initiate HA.

Après la configuration, le Primary Firewall synchronise la configuration sur le Auxiliary Firewall. Sur le Auxiliary Firewall, de nombreux paramètres locaux sont écrasés. Par conséquent, le Auxiliary ne doit pas être configuré en parallèle comme un pare-feu productif autonome avant la configuration HA.

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

Après la configuration du cluster, il ne faut pas simplement cliquer pour fermer, mais vérifier les points suivants :

• Statut HA des deux nœuds
• Rôle et statut en haut à droite dans le WebAdmin
• Lien HA dédié
• Ports surveillés
• Port Admin du pair
• Primary préféré
• Intervalle de Keepalive et tentatives
• Titulaire de la licence en Active-Passive
• Enregistrement Sophos Central, si utilisé

4. Définir les ports surveillés

Les ports surveillés déterminent si une panne d’interface déclenche un basculement. Candidats typiques :

• Liaison montante WAN
• Liaison montante LAN principale
• Liaisons montantes DMZ ou serveur importantes

Il ne faut pas surveiller les ports qui sont parfois délibérément hors ligne, non câblés ou utilisés uniquement pour des scénarios optionnels. Un port surveillé mal configuré est une cause fréquente de basculements inattendus ou d’un cluster qui ne démarre pas.

Configurer Active-Active avec QuickHA

Active-Active est configuré de manière similaire, mais avec un objectif différent. Au préalable, les deux pare-feux doivent être correctement licenciés.

1. Vérifier au préalable

• Les deux pare-feux ont des licences appropriées.
• Les types de licence correspondent.
• Les deux appareils sont enregistrés.
• Les deux appareils fonctionnent sur la même version SFOS, y compris le build.
• Le trafic pertinent bénéficie réellement d’Active-Active.
• Les services avec des restrictions Active-Active ont été vérifiés.
• La surveillance et le dépannage sont conçus pour les deux nœuds.

2. Configurer le Primary Firewall

1. Aller à System services > High availability.
2. Sélectionner Primary (active-active).
3. Utiliser QuickHA.
4. Attribuer un nom de nœud.
5. Définir une phrase de passe HA.
6. Sélectionner le lien HA dédié.
7. Démarrer HA.

3. Configurer le Auxiliary Firewall

1. Sur le second appareil, aller à System services > High availability.
2. Sélectionner Auxiliary.
3. Utiliser QuickHA.
4. Entrer la même phrase de passe.
5. Sélectionner le même port de lien HA.
6. Démarrer HA.

4. Tester après la configuration

En Active-Active, il faut tester plus que le statut HA :

• Les connexions sont-elles distribuées sur les deux nœuds ?
• Les journaux sont-ils visibles sur les deux appareils ?
• Les connexions VPN fonctionnent-elles après un changement de rôle ?
• La protection Web, IPS, le contrôle des applications et les fonctionnalités de sécurité pertinentes fonctionnent-ils ?
• Y a-t-il des applications qui se distinguent par un comportement asymétrique ?
• Les rapports et alertes sont-ils générés comme prévu ?

Configuration manuelle de HA

La configuration manuelle de HA est pertinente lorsque la logique automatique QuickHA ne fournit pas suffisamment de contrôle.

Raisons typiques :

• des adresses IP de lien HA fixes doivent être utilisées
• le port Admin du pair doit être défini précisément
• l’ID de cluster doit être défini consciemment
• plusieurs clusters HA existent dans le même environnement de couche 2
• les appliances virtuelles doivent être exploitées avec certaines options MAC
• un déploiement très contrôlé est nécessaire

Lors de la configuration manuelle, le Auxiliary Firewall est préparé en premier, puis le Primary Firewall est configuré. Le Primary doit connaître l’adresse IP de lien HA du pair.

Champs importants :

• Operation mode : Active-Passive ou Active-Active.
• Initial device role : Primary ou Auxiliary.
• Dedicated HA link : interface pour heartbeat, statut et synchronisation.
• Peer HA link IPv4 : adresse de l’interface HA-Link sur le second appareil.
• Cluster ID : base pour les adresses MAC virtuelles. À définir de manière unique si plusieurs clusters existent.
• Monitored ports : ports critiques dont la panne doit déclencher un failover.
• Peer administration settings : accès à la Auxiliary Firewall.
• Preferred primary : appareil qui doit redevenir Primary après un failover.
• Keepalive interval / Attempts : sensibilité de la détection HA. À ajuster uniquement consciemment.

Valider le cluster

Après la configuration, le cluster HA doit être vérifié systématiquement.

Vérification WebAdmin

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

Vérification CLI

Dans la console de l’appareil, on peut afficher le statut HA :

system ha show details

Si l’on ne sait pas quel appareil est l’Initial Primary titulaire de la licence, cette valeur peut aider dans la console avancée :

nvram get "#li.master"

YES indique l’appareil initial Primary, NO l’appareil Auxiliary. Ces commandes doivent être documentées et utilisées uniquement dans des cas de maintenance ou de diagnostic clairs.

Si l’accès Shell n’est pas encore préparé, le guide Connecter Sophos Firewall via SSH peut être utile.

Test fonctionnel

• Tester un client du LAN vers Internet.
• Tester l’accès aux serveurs internes.
• Tester le VPN.
• Tester les scénarios DNAT ou WAF.
• Tester DNS et DHCP si le pare-feu fournit ces services.
• Vérifier les journaux dans le Log Viewer.
• Tester le changement de rôle HA dans une fenêtre de maintenance.
• Ensuite, documenter les rôles, statuts et comportement des sessions.

Exploitation et maintenance

Surveillance continue

Un cluster HA doit être surveillé activement. Ce n’est pas parce que deux pare-feux sont dans le rack que l’environnement est automatiquement hautement disponible.

Il faut surveiller :

• Statut HA
• Statut des rôles Primary/Auxiliary
• Lien HA
• Ports surveillés
• Statut des licences et abonnements
• Versions du firmware
• Ressources comme CPU, RAM, disque
• Services centraux comme IPS, Web, VPN, DNS, DHCP
• Journaux dans le Log Viewer
• Alertes dans Sophos Central ou par e-mail

Pour les sujets de disque et de matériel, il faut considérer les deux nœuds séparément. Les rapports locaux, fichiers journaux et état des SSD peuvent différer. Les articles Vérifier l’espace de stockage Sophos Firewall et gérer les rapports et Vérifier la santé des SSD Sophos Firewall via SMART sont pertinents.

Journaux et rapports

Les journaux et rapports ne sont pas simplement fusionnés en un ensemble de données local commun. Chaque appareil écrit des journaux pour le trafic qu’il traite. En Active-Active, c’est particulièrement important car le trafic peut apparaître sur les deux nœuds.

Sophos Central Firewall Reporting est utile dans les environnements HA car il peut analyser les données de plusieurs pare-feux de manière centralisée. Les journaux de dépannage locaux se trouvent sur le pare-feu lui-même. L’article Dépannage Sophos Firewall : Services et journaux explique quels services et fichiers journaux sont pertinents pour les analyses.

Runbook pour l’exploitation HA

Un cluster HA nécessite un court runbook d’exploitation. Il doit indiquer quel appareil est l’Initial Primary, quels ports sont surveillés, comment atteindre le Auxiliary, qui approuve les mises à jour du firmware et quand HA est désactivé pour un remplacement ou un reimage.

Documenter au moins :

• Numéro de série, emplacement, position dans le rack et rôle des deux appliances.
• Lien HA dédié, port Admin du pair, ID de cluster et ports surveillés.
• Primary préféré et comportement attendu après un basculement.
• Titulaire de la licence, statut de support et contact RMA.
• Procédure pour mise à jour du firmware, sauvegarde, reimage et remplacement matériel.
• Personne responsable des journaux, Central Reporting, Syslog et cas de support.

Si seul le WebAdmin sur un nœud est bloqué, cela ne signifie pas automatiquement que tout le cluster HA est défectueux. Il faut alors vérifier si un redémarrage de l’interface WebAdmin ou un redémarrage contrôlé des services suffit avant de déclencher un basculement ou un redémarrage.

Modifications du cluster

Les modifications de configuration sont effectuées sur le Primary Firewall. Le Auxiliary Firewall n’est pas l’endroit pour les modifications normales de règles, d’interfaces ou de politiques.

Avant les modifications importantes :

• Créer une sauvegarde.
• Définir une fenêtre de maintenance.
• Vérifier le statut HA.
• Mettre à jour la documentation.
• Définir un chemin de retour.
• Après la modification, tester la synchronisation et le trafic.

Cela s’applique particulièrement à :

• Interfaces
• VLANs
• LAGs
• Zones
• Routage
• NAT
• VPN
• Device Access
• SD-WAN

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

Processus typique :

1. Lancer la mise à jour sur le Primary Firewall.
2. Le Auxiliary Firewall est mis à jour.
3. Le Auxiliary Firewall redémarre et prend temporairement le relais.
4. Le Primary précédent est mis à jour.
5. Le Primary précédent redémarre.
6. Si le Primary préféré est actif, un retour sur l’appareil préféré peut avoir lieu.

Cependant, les mises à jour du firmware doivent être planifiées dans une fenêtre de maintenance. Même si le processus est conçu pour minimiser les interruptions, certaines sessions, connexions VPN ou applications spéciales peuvent réagir brièvement.

Pour la préparation, consultez Mise à jour du firmware Sophos Firewall - Préparation et meilleures pratiques.

Mises à jour des modèles

Les mises à jour des modèles sont installées sur le Primary Firewall et synchronisées sur le Auxiliary Firewall. Cela s’applique également aux environnements où les mises à jour sont contrôlées ou installées hors ligne.

Si un cluster HA est exploité dans un environnement isolé, il doit être clair avant chaque mise à jour manuelle des modèles ou des licences quel nœud est l’Initial Primary et quel nœud est actuellement Primary. Le processus Air-Gap est décrit dans Exploiter la licence et les mises à jour des modèles Sophos Firewall Air-Gap.

Sauvegarde et restauration

La sauvegarde et la restauration ont des particularités dans les environnements HA :

• Les sauvegardes doivent être créées régulièrement et avant chaque modification importante.
• La restauration s’effectue sur le Primary Firewall actuel.
• Après la restauration, les deux pare-feux sont désenregistrés de Sophos Central et doivent être réenregistrés.
• La restauration provoque un redémarrage et un temps d’arrêt, pas un basculement normal.
• Si une sauvegarde sans configuration HA est restaurée sur un cluster HA, HA est désactivé et doit être reconstruit.

Remplacement d’un nœud de cluster

Lors du remplacement ou du reimage d’un nœud, HA ne doit pas simplement continuer avec l’ancien pair.

Points importants :

• Sophos distingue dans le processus RMA si la Auxiliary ou la Primary est remplacée.
• RMA et Reimage en Active-Passive provoquent une downtime planifiée et ne doivent pas être traités comme un failover normal.
• Avant le reimage ou le remplacement, désactiver HA proprement.
• Documenter la version du firmware et le build.
• Créer une sauvegarde.
• Identifier le titulaire de la licence.
• Retirer l’appareil de la gestion Sophos Central s’il est retourné ou remplacé.
• Enregistrer le nouvel appareil.
• Reconfigurer HA, car l’ancienne phrase de passe HA ne peut pas être réutilisée pour un nouvel appareil.

Si la Auxiliary est remplacée, la Primary saine continue généralement d’abord comme appareil HA standalone. Si la Primary est remplacée, il faut clarifier avec une attention particulière quel appareil était l’Initial Primary, quelle sauvegarde est utilisée et quand les câbles sont déplacés vers l’appareil de remplacement. Dans les deux cas, modèle, révision matérielle, version firmware, build, transfert de licence, statut Sophos Central et statut msync doivent être documentés. Le service et le fichier log correspondant sont classés dans l’article Dépannage Sophos Firewall : Services et journaux.

Pour la nouvelle installation technique, consultez Réinstaller Sophos Firewall OS : Reimage avec une clé USB. Si un défaut matériel ou un processus RMA est en cours, il est conseillé de planifier également Préparer correctement un défaut matériel et un RMA Sophos.

Dépannage

En cas de problèmes profonds, il est important de rester structuré : vérifier d’abord le statut, le lien HA, les ports surveillés, la version du firmware et le statut de la licence, puis seulement se pencher sur les cas spéciaux ou les conseils du fabricant. Cela permet de savoir clairement s’il s’agit d’un véritable problème HA ou si la licence, l’interface, la version du firmware ou la surveillance sont à l’origine du problème.

Journaux et lieux de diagnostic importants

• Statut HA : System services > High availability.
• Event Logs : Log viewer > System.
• Troubleshooting Logs : Diagnostics > Tools ou via SSH sous /log.
• Détails HA CLI : system ha show details.
• Problèmes d’interface : show network interfaces, ifconfig, dmesg dans les cas de diagnostic appropriés.
• Titulaire de la licence : vue HA WebAdmin ou nvram get "#li.master".

Pour des analyses plus approfondies, l’article Dépannage CLI Sophos Firewall : commandes importantes est souvent utile.

Symptômes HA typiques

• Le cluster ne se forme pas, version ou build firmware différents : vérifier la version sur les deux appareils et mettre les deux firewalls sur la même version SFOS.
• Le cluster ne se forme pas, modèle ou appliance incompatible : vérifier modèle et numéro de série. Pour une HA hardware, utiliser uniquement des modèles XGS identiques compatibles.
• HA could not be enabled : le Dedicated HA link n’est peut-être pas connecté ou le peer est inaccessible. Vérifier statut du port, câble, switch et ping vers l’IP HA-Link, puis stabiliser le câblage ou le HA-Link.
• HA-Link down : câble, switchport, VLAN ou LAG peut être défectueux. Vérifier statut d’interface, Speed/Duplex, VLAN-Trunk et membres LAG.
• Les deux appareils deviennent Standalone : le HA-Link est tombé, risque de Split-Brain. Vérifier la connexion physique HA-Link et le chemin switch, arrêter un appareil de manière contrôlée, réparer le HA-Link puis redémarrer.
• Auxiliary WebAdmin inaccessible : Peer Admin Port, sous-réseau, route ou Device Access ne correspondent pas. Vérifier l’IP du port admin et l’accès depuis le réseau de management.
• Validation failed for HA interface IP : ports admin ou adresses HA-Link ne sont 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 Monitored Ports et statut switch, puis ne surveiller que des ports vraiment critiques et stables.
• Failover ne se produit pas : le port pertinent 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 type de connexion, protocole et logs des deux nœuds ; si le bénéfice n’est pas clair, utiliser Active-Passive ou adapter le design.
• Logs apparemment manquants : le trafic a peut-être été traité par l’autre nœud ou le logging n’est pas actif. Vérifier sur les deux nœuds et dans le Log Viewer, activer le logging dans les règles et utiliser Central Reporting ou Syslog.
• Reports différents : les reports locaux sont liés au nœud. Comparer les reports 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 harmoniser les licences.
• Problèmes après firmware update : un nœud n’est pas correctement mis à jour ou le cluster n’est pas synchronisé. Vérifier statut HA, versions firmware et logs ; pour les clusters productifs, utiliser une fenêtre de maintenance et impliquer Sophos Support.
• Flexi-Port-HA-Link ne fonctionne pas : Speed/Duplex ou Auto-Negotiation ne correspond pas. Vérifier Interface Advanced settings sur les deux appareils et configurer les deux côtés de manière identique ou utiliser un port fixe.

Procédure en cas de panne de lien HA

Si le lien HA dédié tombe en panne, il faut être prudent. Les deux pare-feux peuvent ne plus se voir mutuellement. Dans le pire des cas, les deux appareils envoient des ARP/GARP et tentent de revendiquer la MAC du cluster pour eux-mêmes.

Procédure sécurisée :

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, le port de commutateur, le VLAN ou le LAG du lien HA.
5. Redémarrer l’appareil.
6. Vérifier le statut HA.
7. Contrôler les journaux et les rôles.

Commandes CLI pertinentes

system ha show details

Affiche les détails HA dans la console de l’appareil.

show network interfaces

Aide pour le statut des interfaces et les informations de lien.

nvram get "#li.master"

Indique dans la console avancée si l’appareil est l’Initial Primary titulaire de la licence.

dmesg | grep PortE

Peut donner des indications sur les fluctuations de lien dans certains problèmes matériels/interfaces.

Toutes les commandes ne conviennent pas à chaque environnement. Pour les systèmes productifs, il est conseillé de documenter d’abord l’état, puis de vérifier de manière ciblée.

Listes de vérification des meilleures pratiques

Planification

• Examiner Active-Passive comme variante standard.
• Utiliser Active-Active uniquement avec un objectif de performance clair.
• Vérifier les deux appareils pour le modèle, le firmware, les ports Flexi et la licence.
• Connecter le lien HA de manière dédiée et aussi directement que possible.
• Sélectionner consciemment les ports surveillés.
• Planifier l’accès de gestion au Primary et au Auxiliary.
• Documenter l’ID de cluster de manière unique.
• Documenter la conception des commutateurs, VLANs et LAGs.
• Planifier RSTP sur les commutateurs pertinents.
• Réfléchir au scénario de Split-Brain.
• Documenter le processus de sauvegarde et de restauration.

Mise en œuvre

• Créer une sauvegarde au préalable.
• Mettre les deux pare-feux à la même version SFOS.
• Désactiver le WAN cellulaire.
• Préparer le lien HA avec une adresse statique et une zone DMZ.
• Autoriser SSH pour la zone de lien HA.
• Nommer proprement le Primary et le Auxiliary.
• Utiliser la phrase de passe uniquement pour la configuration et ne pas la traiter comme un mot de passe admin permanent.
• Après QuickHA, vérifier les paramètres avancés.
• Ne définir les ports surveillés que lorsqu’il est clair quels liens sont stables et critiques.
• Tester le basculement dans une fenêtre de maintenance.

Exploitation

• Vérifier régulièrement le statut HA.
• Surveiller les licences et la synchronisation.
• Effectuer les mises à jour du firmware uniquement préparées et avec une fenêtre de maintenance.
• Tester régulièrement les sauvegardes.
• Effectuer les modifications de configuration uniquement sur le Primary.
• Après les modifications de commutateur, VLAN ou interface, vérifier le statut HA.
• Inclure les journaux des deux nœuds.
• Utiliser Sophos Central Firewall Reporting ou Syslog pour des analyses plus longues.
• Effectuer le remplacement ou le reimage d’un nœud uniquement avec une désactivation HA planifiée et une reconfiguration.

À ne pas faire

• Ne pas regrouper des modèles différents.
• Ne pas planifier de modèles Wi-Fi XGS pour HA.
• Ne pas laisser le WAN cellulaire actif en HA.
• Ne pas définir de ports non câblés comme ports surveillés.
• Ne pas utiliser de VLAN ou de chemin de commutateur instable comme lien HA.
• Ne pas conduire de services productifs sur le lien HA.
• Ne pas considérer Active-Active comme un simple doublement de la performance.
• Ne pas attendre ou planifier de modifications sur le Auxiliary Firewall.
• Ne pas effectuer de restauration sans fenêtre de maintenance.

FAQ