Sophos Firewall High Availability (HA) einrichten

High Availability, kurz HA, verbindet zwei Sophos Firewalls zu einem Cluster. Ziel ist nicht, eine einzelne Firewall unzerstörbar zu machen, sondern den Ausfall eines Geräts, einzelner kritischer Ports oder geplanter Wartungsarbeiten kontrolliert abzufangen.

Eine HA-Umgebung ist trotzdem kein Ersatz für gutes Netzwerkdesign, saubere Backups und dokumentierte Wartungsprozesse. Ein falsch geplanter Cluster kann im Fehlerfall sogar schwieriger zu betreiben sein als eine einzelne Firewall. Dieser Artikel erklärt deshalb nicht nur, wo man HA einschaltet, sondern wie man einen Sophos Firewall HA-Cluster sinnvoll plant, einrichtet, betreibt und im Fehlerfall prüft.

Inhaltsverzeichnis

• Kurzfazit
• Videoanleitungen
• Was High Availability auf der Sophos Firewall bedeutet
• Active-Passive oder Active-Active
• Rollen, Status und Architektur
• Voraussetzungen
• Planung und Design
• Einrichtung vorbereiten
• Active-Passive mit QuickHA einrichten
• Active-Active mit QuickHA einrichten
• Manuelle HA-Konfiguration
• Cluster validieren
• Betrieb und Pflege
• Firmware-Updates und Backups
• Troubleshooting
• Best-Practice-Checklisten

Kurzfazit

In den meisten produktiven Umgebungen ist Active-Passive die bessere HA-Variante. Eine Firewall verarbeitet den gesamten Traffic, die zweite Firewall steht bereit und übernimmt bei Ausfall oder Wartung. Das Design ist einfacher, die Lizenzierung ist günstiger und das Verhalten im Fehlerfall ist leichter nachvollziehbar.

Active-Active lohnt sich nur, wenn man die Grenzen und Einschränkungen bewusst akzeptiert. Es ist kein klassisches symmetrisches Load Balancing, bei dem beide Firewalls gleichberechtigt an allen Stellen im Netzwerk stehen. Die Primary Firewall nimmt weiterhin den Traffic entgegen und verteilt bestimmte Verbindungen an die Auxiliary Firewall. Nicht jeder Dienst und nicht jede Traffic-Art wird verteilt.

Als schnelle Orientierung:

• Maximale Stabilität und einfache Betriebsführung: Active-Passive.
• Zweite Firewall ohne separate Schutzlizenz nutzen: Active-Passive.
• Mehr Durchsatz für bestimmte TCP-Verbindungen benötigt: Active-Active prüfen.
• Viele VPN-, Proxy-, RED-, NDR- oder Sonderfälle: Active-Passive bevorzugen.
• Kleine oder mittlere Umgebung ohne klares Performance-Problem: Active-Passive.
• Klare Performance-Anforderung und passende Lizenzierung für beide Appliances: Active-Active nach Test.

Videoanleitungen

Die folgenden Sophos-Techvids zeigen HA auf der Sophos Firewall visuell. Die Videos ersetzen keine saubere Planung, sind aber hilfreich, um QuickHA, Rollen, Status und das grundsätzliche Verhalten eines HA-Clusters besser einzuordnen.

Was High Availability auf der Sophos Firewall bedeutet

Ein Sophos Firewall HA-Cluster besteht aus zwei Firewalls. Die Geräte tauschen über einen dedizierten HA-Link Heartbeats, Gerätestatus, Verbindungsinformationen und Konfigurationsdaten aus. Die Konfiguration wird von der Primary Firewall auf die Auxiliary Firewall synchronisiert.

HA schützt vor typischen Ausfällen:

• Ausfall der Primary Firewall
• Strom- oder Hardwarefehler
• Ausfall eines überwachten Interfaces
• Software- oder Dienstproblem, das ein Gerät nicht mehr arbeitsfähig macht
• geplante Firmware-Updates
• geplanter Rollenwechsel bei Wartung

HA löst aber nicht jedes Problem:

• Ein falsches Firewall-Regelwerk bleibt auch im Cluster falsch.
• Ein gemeinsamer Switch-Ausfall kann beide Firewalls gleichzeitig betreffen.
• Ein defektes VLAN-Design oder ein fehlerhaftes Routing-Konzept wird nicht automatisch korrigiert.
• Logs und Reports werden nicht vollständig zwischen beiden Firewalls synchronisiert.
• Ein Backup bleibt weiterhin Pflicht.

Wer HA plant, sollte vorher die Grundlagen für Zonen, Interfaces, VLANs, LAGs und Bridges sauber geklärt haben. Dazu passt die Anleitung Sophos Firewall Zonen und Interfaces planen und konfigurieren.

Active-Passive oder Active-Active

Active-Passive

Bei Active-Passive verarbeitet eine Firewall den gesamten produktiven Traffic. Die zweite Firewall ist passiv und übernimmt erst, wenn die aktive Firewall ausfällt oder ein Failover manuell bzw. durch Wartung ausgelöst wird.

Typische Eigenschaften:

• Primary Firewall verarbeitet den Traffic.
• Auxiliary Firewall bleibt im Standby.
• Sessions werden synchronisiert, soweit der jeweilige Dienst das unterstützt.
• Nur das lizenzhaltende Gerät benötigt bei Hardware-Appliances die Schutzsubscriptions.
• Die Auxiliary Firewall übernimmt bei Failover mit derselben virtuellen MAC-Adresse.
• Netzwerkgeräte müssen ihre Nachbarschaften in der Regel nicht neu lernen.

Active-Passive ist meistens die beste Wahl für klassische Firmenumgebungen, Filialen, Rechenzentren und Umgebungen, in denen Stabilität wichtiger ist als ein möglicher Performance-Gewinn.

Active-Active

Bei Active-Active verarbeiten beide Firewalls Traffic. Trotzdem bleibt die Architektur asymmetrisch: Die Primary Firewall nimmt den Traffic entgegen und entscheidet, ob sie eine Verbindung selbst verarbeitet oder an die Auxiliary Firewall weitergibt.

Sophos verwendet für die Verteilung unter anderem die Quell-IP-Adresse. TCP-Verbindungen von geraden Quell-IP-Adressen werden typischerweise auf der Primary verarbeitet, ungerade Quell-IP-Adressen können an die Auxiliary weitergeleitet werden. Nicht-TCP-Traffic und bestimmte Dienste werden nicht gleich verteilt.

Typische Eigenschaften:

• Beide Firewalls können Traffic verarbeiten.
• Die Primary Firewall bleibt der zentrale Einstiegspunkt.
• Beide Firewalls benötigen passende Lizenzen.
• Nicht alle Dienste werden verteilt.
• Logs und Reports entstehen auf dem Gerät, das den jeweiligen Traffic verarbeitet.
• Troubleshooting wird komplexer, weil Verbindungen auf beiden Nodes landen können.

Active-Active ist sinnvoll, wenn ein klares Performance-Ziel besteht und man vorher getestet hat, ob der relevante Traffic tatsächlich verteilt wird. Für reine Hochverfügbarkeit ist Active-Passive meist sauberer.

Rollen, Status und Architektur

Rollen im HA-Cluster

• Primary: Gerät, das die zentrale Cluster-Konfiguration führt. In beiden HA-Modi nimmt die Primary den Traffic entgegen.
• Auxiliary: Zweites Gerät im Cluster. Es synchronisiert die Konfiguration von der Primary und übernimmt bei Bedarf.
• Initial primary: Das Gerät, das bei der Einrichtung als Primary gestartet wurde. In Active-Passive ist es in der Regel auch das lizenzhaltende Gerät.
• Preferred primary: Bevorzugtes Gerät, das nach einem Failover wieder Primary werden soll, sobald es stabil verfügbar ist.

Statuswerte im Betrieb

• Active: Das Gerät verarbeitet Traffic.
• Passive: Das Gerät ist bereit, verarbeitet aber in Active-Passive keinen produktiven Traffic.
• Standalone: Das Gerät sieht den Peer nicht oder HA ist nicht vollständig aktiv. Bei HA-Link-Problemen können beide Geräte Standalone werden.
• Faulty: Das Gerät ist für den Cluster nicht gesund genug, um normal teilzunehmen.

Virtuelle MAC-Adresse

Die Sophos Firewall verwendet im HA-Cluster virtuelle MAC-Adressen für die produktiven Interfaces. Nur die Primary beantwortet ARP-Anfragen für den Cluster. Bei einem Failover übernimmt die Auxiliary diese virtuelle MAC-Adresse. Dadurch bleibt die Erreichbarkeit für Switches, Router und Clients stabiler, weil sich IP- und MAC-Zuordnung nicht grundlegend ändern.

Wichtig ist die Cluster ID. Diese ID wird für die virtuelle MAC-Adresse verwendet. Wenn mehrere HA-Cluster im selben Layer-2-Umfeld betrieben werden, muss jeder Cluster eine eindeutige Cluster ID haben. Sonst können MAC-Konflikte entstehen.

Was synchronisiert wird

• Firewall-Regeln, Policies, Objekte, Routing und CLI-Konfiguration werden von Primary zu Auxiliary synchronisiert.
• Aktive Sessions werden je nach Protokoll und Dienst synchronisiert.
• Secure Storage Master Key und WebAdmin-Zugangsdaten werden synchronisiert.
• Dedicated HA link wird nicht als normale produktive Interface-Konfiguration synchronisiert.
• Peer Admin Port wird separat behandelt und nicht wie ein normales Interface synchronisiert.
• Logs und Reports werden nicht zwischen den Geräten synchronisiert.

Failover-Verhalten

Ein Failover kann durch verschiedene Ereignisse ausgelöst werden:

• keine Heartbeats mehr über den HA-Link
• Ausfall eines überwachten Ports
• Stromausfall
• Hardwarefehler
• Software- oder Dienstproblem
• geplanter Rollenwechsel
• Firmware-Update

Die Heartbeats laufen über den dedizierten HA-Link. Standardmässig werden sehr kurze Intervalle verwendet. Wenn mehrere Heartbeats nacheinander fehlen, gilt der Peer als nicht erreichbar. Danach prüft die Firewall den Zustand und führt den Rollenwechsel aus.

Bei einem Failover werden viele Verbindungen weitergeführt oder schnell neu aufgebaut. Vollständig transparent ist ein Failover aber nicht für jede Anwendung. Besonders stateful TCP-Verbindungen, Websessions, Proxy-Verbindungen oder bestimmte VPN-Szenarien können kurz abbrechen oder neu aufgebaut werden müssen.

Load Balancing in Active-Active

Active-Active bedeutet nicht, dass beide Firewalls wie zwei gleichberechtigte Router im Netzwerk stehen. Die Primary Firewall bleibt der zentrale Einstiegspunkt und verteilt bestimmte Verbindungen an die Auxiliary Firewall.

Wichtige Punkte:

• Load Balancing gibt es nur in Active-Active.
• Die Methode kann nicht frei angepasst werden.
• Externe Load Balancer vor einem HA-Cluster werden von Sophos für diese HA-Logik nicht als Standarddesign verwendet.
• Nicht jeder Traffic wird verteilt.
• Nicht-TCP-Traffic, SD-RED, getunnelter Traffic und einige Layer-7-Funktionen können anders behandelt werden.
• Troubleshooting muss beide Nodes einbeziehen.

In der Praxis sollte Active-Active nur eingesetzt werden, wenn vorher klar ist, welcher Traffic den Engpass erzeugt und ob genau dieser Traffic verteilt wird.

Unterstützte und eingeschränkte Dienste

Sophos HA unterstützt die meisten Firewall-Dienste. Einige Dienste haben aber Besonderheiten.

• Firewall-Regeln und NAT werden synchronisiert. In Active-Active muss man wissen, welcher Node eine Verbindung verarbeitet.
• VPN funktioniert in vielen HA-Szenarien, aber nicht jede Session-Art fällt ohne Unterbruch um. IPsec kann stateless UDP/ICMP besser übernehmen als stateful TCP.
• Web Protection funktioniert im Cluster. Bei Active-Active können Alerts von beiden Nodes kommen.
• Email Protection kann bei Quarantäne und Freigabe nodebezogen wirken, weil jedes Gerät eigene Daten für verarbeiteten Mail-Traffic speichert.
• Synchronized Application Control ist nicht für Active-Active geeignet, wenn die Funktion in der eingesetzten SFOS-Version nicht unterstützt wird.
• NDR Essentials sollte in HA-Umgebungen nur mit Active-Passive geplant werden.
• sFlow läuft in HA-Umgebungen nur auf der Primary.
• Reports werden lokal pro Gerät erzeugt. Zusammengeführte Reports sind über Sophos Central Firewall Reporting sinnvoller.
• Cellular WAN muss für HA deaktiviert werden.
• XGS Wi-Fi Modelle unterstützen HA nicht.

Wenn Reporting oder Log-Aufbewahrung wichtig ist, sollte man früh planen, ob ein externer Syslog-Server oder Sophos Central Firewall Reporting genutzt wird. Mehr dazu steht in Central Firewall Reporting aktivieren.

Voraussetzungen

Vor der Umsetzung sollte man die HA-Voraussetzungen sauber gegen die eigene Umgebung prüfen. Besonders Modellgleichheit, Firmwarestand, Interfaces, Cellular WAN und virtuelle Plattformen sind Punkte, bei denen kleine Abweichungen später grosse Wirkung haben können.

Hardware und Modellkompatibilität

• Appliance-Modell: Beide Firewalls müssen dasselbe XGS-Modell sein, zum Beispiel XGS 2100 mit XGS 2100.
• Hardware-Revision: Unterschiedliche Hardware-Revisionen sind bei gleichem XGS-Modell möglich.
• XGS Wi-Fi Modelle: Nicht unterstützt. Beispiele sind XGS 126w oder XGS 136w.
• Flexi Port Module: Wenn Erweiterungsmodule genutzt werden, muss die Anzahl der Flexi Ports auf beiden Geräten gleich sein.
• Firmware: Beide Geräte müssen dieselbe SFOS-Version inklusive Maintenance Release und Build verwenden.
• Hardware plus virtuelle Appliance: Nicht als HA-Paar möglich.

Virtuelle und Software-Appliances

Virtuelle oder Software-Appliances müssen ebenfalls sehr sauber zueinander passen.

• Plattform: Gleicher Appliance-Typ und gleiche SFOS-Plattform.
• Hypervisor: Gleicher Hypervisor-Typ.
• Ressourcen: Gleiche CPU-Kerne, vergleichbare Ressourcen und gleiche Anzahl Netzwerkinterfaces.
• Firmware: Gleiche SFOS-Version inklusive Build.
• MAC-Adressen: In virtuellen Umgebungen kann die Option für hypervisorzugewiesene MAC-Adressen relevant sein, damit kein Promiscuous Mode benötigt wird. Eine Änderung verursacht aber Downtime.

Cloud-Deployments

In Cloud-Umgebungen gelten zusätzliche Plattformvorgaben. Routing, virtuelle Interfaces, IP-Adressen, Security Groups, UDRs oder Cloud-spezifische Failover-Mechanismen müssen zum jeweiligen Cloud-Design passen. Der normale Appliance-HA-Ansatz lässt sich nicht ungeprüft auf Azure, AWS oder andere Cloud-Umgebungen übertragen.

Wenn eine Sophos Firewall in der Cloud betrieben wird, sollte man vor der HA-Planung die aktuelle Sophos-Dokumentation für die jeweilige Plattform und die Cloud-Netzwerkarchitektur prüfen.

Lizenzierung und Registrierung

Die HA-Lizenzierung unterscheidet sich je nach Plattform und HA-Modus. Entscheidend sind drei Fragen: Handelt es sich um Hardware oder Virtual/Software? Wird Active-Passive oder Active-Active eingesetzt? Und welches Gerät ist das Initial Primary, also das Gerät, das die Lizenz für den Cluster hält? Diese Punkte sollten vor der Umsetzung mit Lizenzstatus, Seriennummern und Zielmodus abgeglichen werden.

Die wichtigsten Lizenzpunkte:

• Base Firewall: Für HA ist eine Base Firewall Lizenz erforderlich. Hardware-Appliances haben diese Lizenz standardmässig. Bei Virtual/Software-Appliances muss sie passend lizenziert sein.
• Active-Passive Hardware: Nur das Initial-Primary-Gerät benötigt die produktiven Subscriptions. Die Auxiliary Firewall erhält eine Kopie der Subscriptions und kann nach einem Failover Traffic verarbeiten.
• Active-Active Hardware: Beide Firewalls benötigen eigene passende Lizenzen. Die Lizenztypen müssen übereinstimmen, Ablaufdaten dürfen unterschiedlich sein.
• Active-Passive Virtual/Software: Nur die Primary benötigt die nötigen Lizenzen inklusive Base Firewall.
• Active-Active Virtual/Software: Beide Geräte benötigen eine eigene Base Firewall Lizenz und passende weitere Schutzlizenzen.
• Registrierung Hardware: Beide Hardware-Geräte müssen in Sophos Central beziehungsweise im Sophos Licensing-Portal bekannt sein und ihre Lizenzen synchronisieren können.
• Registrierung Virtual/Software Active-Passive: Bei Active-Passive Virtual/Software wird nach Sophos-Angaben nur die Primary geclaimt.
• Sophos Central Management: Lizenzsynchronisierung und Claiming bedeuten nicht automatisch, dass die Firewalls auch über Sophos Central Firewall Management verwaltet werden. Dafür ist eine passende zusätzliche Subscription nötig.
• RMA und Support: Für Hardwaretausch und Advance Replacement ist der Supportstatus wichtig. Bei Active-Passive Hardware nennt Sophos Enhanced Plus Support auf dem Primary-Gerät als relevante Voraussetzung für Advance Hardware Replacement. Bei Active-Active muss der Supportstatus auf beiden Geräten passen.

Wichtig: Bei Active-Passive ist das Initial Primary besonders wichtig, weil dieses Gerät die Lizenz für den Cluster hält. In der HA-Ansicht steht beim entsprechenden Gerät sinngemäss, dass es die Lizenz für den Cluster hält. Im Zweifel sollte man das Gerät im Betriebshandbuch eindeutig dokumentieren.

Wenn sich Lizenzen in Active-Active nicht entsprechen, stoppt nach Sophos-Angaben zunächst das Load Balancing. Bleibt die Abweichung länger bestehen, kann HA deaktiviert werden. Bei einer Erstkonfiguration wird Active-Active HA mit nicht passenden Lizenzen nicht sauber aktiviert. Deshalb gehört ein Lizenzcheck zwingend zur Betriebsroutine.

Bei Virtual/Software-Appliances ist die Base Firewall Lizenz besonders kritisch. Wird sie deaktiviert oder kann das Initial Primary die Lizenz über längere Zeit nicht synchronisieren, kann HA deaktiviert werden und andere Schutzfunktionen werden inaktiv. Relevant ist hier eine Synchronisierung mit dem Lizenzserver mindestens einmal innerhalb von 90 Tagen. Für produktive Umgebungen heisst das: Der HA-Cluster muss nicht nur technisch funktionieren, sondern auch regelmässig den Lizenzserver erreichen können.

Für den Betrieb sollte man mindestens dokumentieren:

• welches Gerät das Initial Primary ist
• welche Seriennummern oder Appliance-IDs zum Cluster gehören
• welche Lizenzen auf welchem Gerät aktiv sind
• wann die Lizenzen zuletzt synchronisiert wurden
• welche Supportstufe für RMA oder Advance Replacement vorhanden ist
• wer Lizenzänderungen, Renewals und RMA-Prozesse freigibt

Netzwerkvoraussetzungen

• HA-Link: Dedizierte Verbindung zwischen beiden Firewalls, idealerweise direkt mit Ethernet-Kabel.
• HA-Link-Zone: DMZ-Zone mit aktiviertem SSH für die Zone.
• HA-Link-IP-Adressen: Statische IP-Adressen im selben Subnetz, aber unterschiedliche Adressen.
• HA-Link-Qualität: Hohe Bandbreite, geringe Latenz, kein Paketverlust.
• Switches: RSTP auf Switches aktivieren, die mit Firewall-Ports verbunden sind.
• Monitored Ports: Nur Ports überwachen, die wirklich angeschlossen und kritisch sind.
• Cellular WAN: Für HA deaktivieren.
• Peer Admin Port: Separat planen, damit die Auxiliary Firewall erreichbar bleibt.

Der HA-Link verarbeitet keinen normalen Client- oder Servertraffic. Er ist nur für Heartbeats, Status, Session-Synchronisierung, Konfigurationssynchronisierung und Active-Active-Verteilung relevant. Trotzdem ist er extrem kritisch. Wenn der HA-Link ausfällt, können beide Firewalls glauben, sie seien Primary. Genau dieses Split-Brain-Szenario muss man vermeiden.

Der Peer Admin Port ist ein eigener Betriebszugang zur Auxiliary Firewall. Die Administrationsports beider Geräte müssen im gleichen Subnetz liegen, aber unterschiedliche IP-Adressen verwenden. Nach dem HA-Aufbau erreicht man die Auxiliary Firewall nur über diese Peer-Admin-Adresse und nur aus einem passenden Netz. Wenn beide Geräte noch die gleiche Default-IP verwenden oder die Admin-Ports in unterschiedlichen Subnetzen liegen, scheitert HA oder die Auxiliary ist später nicht sauber erreichbar.

Ports und Interfaces

• Dedicated HA link: Dient Heartbeat, Status, Konfigurations- und Session-Synchronisierung. Direkt verbinden oder über einen sehr zuverlässigen Switch führen. Nicht für produktiven Traffic verwenden.
• Monitored ports: Überwachen kritische produktive Links. WAN, wichtige DMZ- oder Core-Uplinks überwachen, aber keine ungenutzten Ports auswählen.
• Peer Admin Port: Ermöglicht Zugriff auf den Auxiliary WebAdmin. Separat planen und dokumentieren; der Client muss im passenden Subnetz liegen.
• Produktionsinterfaces: LAN, WAN, DMZ, VLANs und LAGs auf beiden Firewalls identisch verkabeln und gleichwertig designen.

Als Dedicated HA link sind physische Interfaces, VLANs oder LAGs möglich. Bridge Interfaces und Alias-IP-Adressen können nicht als dedizierter HA-Link verwendet werden. Wenn ein LAG als HA-Link eingesetzt wird, müssen die Parent Interfaces auf beiden Appliances gleich aufgebaut sein.

Wichtig: Der Dedicated HA link und ein Monitored Port dürfen nicht dasselbe Interface sein. Wenn ein Interface bereits in einer produktiven Konfiguration verwendet wird und trotzdem als HA-Link ausgewählt wird, kann die Firewall abhängige Interface-Konfigurationen ändern oder entfernen. Deshalb sollte der HA-Link vorab frei und dokumentiert sein.

Planung und Design

Empfohlene Topologie für Active-Passive

Ein typisches Active-Passive-Design sieht so aus:

• beide Firewalls stehen im selben Rack oder in nahe beieinanderliegenden Racks
• alle produktiven Interfaces sind gleich verkabelt
• WAN geht auf redundante Switches oder sauber dokumentierte Provider-Übergaben
• LAN/DMZ gehen auf redundante Switch-Strukturen
• der HA-Link ist direkt verbunden
• ein separater Management- oder Admin-Zugriff ist vorgesehen
• WAN- und Core-/DMZ-Ports werden als Monitored Ports definiert

Der wichtigste Punkt: Die zweite Firewall muss im Fehlerfall dieselbe Netzposition übernehmen können. Deshalb müssen VLANs, Trunks, LAGs, Switchports und Provideranschlüsse konsistent geplant sein.

Empfohlene Topologie für Active-Active

Active-Active braucht dieselbe physische Sauberkeit wie Active-Passive, aber zusätzlich eine klare Erwartung an den verteilbaren Traffic.

Vor Active-Active sollte man beantworten:

• Welcher Traffic ist der Engpass?
• Wird genau dieser Traffic in Active-Active verteilt?
• Sind beide Appliances vollständig und passend lizenziert?
• Sind Logs, Reports und Troubleshooting-Prozesse auf beide Nodes vorbereitet?
• Gibt es Dienste wie VPN, NDR, Synchronized Application Control oder Proxy-Szenarien, die gegen Active-Active sprechen?

Ohne klare Antwort ist Active-Passive die bessere Wahl.

LAN, WAN, DMZ und HA-Link

• LAN: Interne Netze sauber zonieren. VLANs nicht nur technisch, sondern auch sicherheitlich planen.
• WAN: Provideranschluss, Failover-Gateways und SD-WAN getrennt von HA betrachten. HA ersetzt kein WAN-Redundanzkonzept.
• DMZ: Servernetze und externe Veröffentlichungen getrennt von Clientnetzen halten.
• HA-Link: Eigene Verbindung, statisch adressiert, DMZ-Zone, SSH für DMZ erlaubt. Keine Nutzer- oder Serverkommunikation darüber führen.
• Management: Admin-Zugriff, Device Access und ACLs bewusst einschränken.

Zum Absichern der lokalen Firewall-Dienste passt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

Switch-Anforderungen

Switches sind bei HA oft der unsichtbare Risikofaktor. Ein HA-Cluster funktioniert nur so gut wie die Layer-2-Umgebung darunter.

Empfehlungen:

• RSTP auf beteiligten Switches aktivieren.
• Trunks auf beiden Firewalls identisch konfigurieren.
• VLANs auf allen beteiligten Ports konsistent erlauben.
• LAGs identisch bauen.
• Keine halbfertigen oder ungenutzten Monitored Ports auswählen.
• HA-Link möglichst direkt verbinden.
• Wenn der HA-Link über Switches läuft, muss der Pfad stabil, latenzarm und paketverlustfrei sein.

VLANs, LAGs, Bridges und RED

VLANs und LAGs sind in HA möglich, aber sie erhöhen die Planungsanforderung. Der HA-Cluster sollte nicht der erste Ort sein, an dem ein VLAN- oder LAG-Design ausprobiert wird.

• VLAN: Auf beiden Geräten identisch planen. Parent Interface beachten. VLAN als HA-Link ist möglich, aber nur bei sehr sauberem Design.
• LAG: Sinnvoll für Core-Uplinks oder redundante Switch-Anbindung. Parent Interfaces müssen konsistent sein.
• Bridge: HA im Bridge Mode wird unterstützt, macht Troubleshooting aber komplexer. Für neue Designs ist Gateway Mode meistens transparenter.
• RED: RED- und Remote-Szenarien können HA beeinflussen, besonders wenn Netze über Standorte gestreckt werden. Performance, Latenz und Fehlerbilder vorher prüfen.
• VPN: VPN-Failover funktioniert je nach Protokoll und Session-Art unterschiedlich gut. IPsec und Remote Access separat testen.

Split-Brain vermeiden

Split-Brain bedeutet, dass beide Firewalls glauben, sie seien aktiv oder standalone zuständig. Das kann passieren, wenn der HA-Link ausfällt, die Geräte sich aber weiterhin im Produktionsnetz befinden.

Massnahmen:

• HA-Link nicht über unsichere oder instabile Switchpfade führen.
• Direktverbindung für HA-Link bevorzugen.
• Monitored Ports bewusst auswählen.
• RSTP sauber konfigurieren.
• Keine asymmetrische Verkabelung.
• HA-Status nach jeder Switch- oder VLAN-Änderung prüfen.
• Keepalive-Werte nur mit Grund anpassen.

Einrichtung vorbereiten

Vor der HA-Einrichtung sollte man nicht im Produktivnetz improvisieren. Diese Vorbereitung spart später viel Zeit.

Vorbereitung beider Firewalls

• Beide Firewalls auf dieselbe SFOS-Version inklusive Build bringen.
• Lizenz- und Registrierungsstatus prüfen.
• Cellular WAN deaktivieren.
• Sicherstellen, dass die Modelle kompatibel sind.
• Flexi Port Ausstattung prüfen.
• Interfaces und Switchports dokumentieren.
• HA-Link-Port festlegen.
• HA-Link direkt verkabeln oder den Switchpfad prüfen.
• Für den HA-Link DMZ-Zone und SSH-Zugriff einplanen.
• Admin-Zugriff auf beide Geräte dokumentieren.
• Backup der bestehenden Konfiguration erstellen.

Backups sind bei HA nicht optional. Vor der Einrichtung, vor Firmware-Updates und vor grösseren Interface-Änderungen sollte ein Backup vorhanden sein. Die Grundlagen stehen in Sophos Firewall Backup erstellen oder wiederherstellen.

Vor dem Klick auf Initiate HA sollte zusätzlich geprüft werden:

• Admin-Ports im gleichen Subnetz, aber mit unterschiedlichen IPs: Sonst ist HA nicht sauber aufbaubar oder die Auxiliary später nicht erreichbar.
• Dedicated HA link ohne produktive Abhängigkeiten: HA kann Interface-IP-Adressen und abhängige Konfigurationen verändern.
• Monitored Ports auf beiden Geräten verbunden: Ein unverbundener Monitored Port kann den Cluster verhindern oder sofort Failover auslösen.
• Cluster ID eindeutig: Mehrere HA-Cluster im gleichen Layer-2-Bereich brauchen unterschiedliche virtuelle MACs.
• Backup, SSMK und Firmware-Build dokumentiert: Bei Restore, RMA oder Reimage muss der Cluster reproduzierbar sein.

QuickHA oder manuelle Konfiguration

• QuickHA: Standardfall. Schnell, robust und für die meisten Active-Passive- und Active-Active-Setups ausreichend.
• Manuelle Konfiguration: Sinnvoll, wenn Admin-Ports, HA-Link, Cluster ID, Peer-Adressen und Detailwerte bewusst vorgegeben werden müssen.

QuickHA erkennt den Peer über die gewählten HA-Link-Interfaces. Sobald sich die Geräte gefunden haben, wird der Cluster aufgebaut. Die Passphrase wird für den Aufbau des verschlüsselten SSH-Tunnels verwendet und danach nicht als wiederverwendbares Kennwort behandelt. Wenn ein Gerät ersetzt wird, muss HA deaktiviert und neu konfiguriert werden.

Die hier beschriebenen Schritte orientieren sich an der offiziellen Sophos-HA-Konfiguration, sind aber bewusst als praxisnahe Admin-Checkliste formuliert. Für produktive Änderungen sollte man nicht nur den Assistenten durchklicken, sondern Rollen, HA-Link, Admin-Zugriff, Backup, Lizenzstatus und Rückweg vorab dokumentieren.

Active-Passive mit QuickHA einrichten

1. Primary Firewall vorbereiten

1. Auf der späteren Primary Firewall im WebAdmin anmelden.
2. Zu System services > High availability wechseln.
3. Als Modus Primary (active-passive) wählen.
4. QuickHA verwenden.
5. Optional einen Node-Namen vergeben, zum Beispiel FW01.
6. Eine HA-Passphrase festlegen.
7. Die Passphrase sicher zwischenspeichern, weil sie gleich auf der Auxiliary Firewall benötigt wird.
8. Den Dedicated HA link auswählen.
9. Initiate HA starten.

Hinweise:

• Der HA-Link darf keine produktiven Abhängigkeiten haben.
• Wenn QuickHA ein ungebundenes Interface verwendet, weist Sophos diesem Interface die DMZ-Zone zu und setzt HA-spezifische Einstellungen.
• Der HA-Link nutzt statische IP-Adressen im Link-Local-Bereich, wenn QuickHA die Standardwerte verwendet.
• SSH muss für die HA-Link-Zone erlaubt sein, weil der HA-Tunnel darüber aufgebaut wird.

2. Auxiliary Firewall vorbereiten

1. Auf der späteren Auxiliary Firewall anmelden.
2. Zu System services > High availability wechseln.
3. Als Rolle Auxiliary wählen.
4. QuickHA verwenden.
5. Optional einen Node-Namen vergeben, zum Beispiel FW02.
6. Dieselbe HA-Passphrase eintragen.
7. Denselben HA-Link-Port wie auf der Primary-Seite auswählen.
8. Initiate HA starten.

Nach dem Aufbau synchronisiert die Primary Firewall die Konfiguration auf die Auxiliary Firewall. Auf der Auxiliary Firewall werden viele lokale Einstellungen überschrieben. Deshalb sollte die Auxiliary vor der HA-Einrichtung nicht parallel als eigenständige produktive Firewall konfiguriert werden.

3. Erweiterte Einstellungen prüfen

Nach dem Cluster-Aufbau sollte man nicht einfach wegklicken, sondern folgende Punkte prüfen:

• HA-Status beider Nodes
• Rolle und Status oben rechts im WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval und Attempts
• Lizenzhalter bei Active-Passive
• Sophos Central Registrierung, falls verwendet

4. Monitored Ports setzen

Monitored Ports entscheiden, ob ein Interface-Ausfall ein Failover auslöst. Typische Kandidaten:

• WAN-Uplink
• Core-LAN-Uplink
• wichtige DMZ- oder Server-Uplinks

Nicht überwachen sollte man Ports, die manchmal bewusst offline sind, nicht verkabelt sind oder nur für optionale Szenarien genutzt werden. Ein falsch gesetzter Monitored Port ist eine häufige Ursache für unerwartete Failover oder einen nicht startenden Cluster.

Active-Active mit QuickHA einrichten

Active-Active wird ähnlich eingerichtet, aber mit einem anderen Ziel. Vorher müssen beide Firewalls passend lizenziert sein.

1. Vorab prüfen

• Beide Firewalls haben passende Lizenzen.
• Die Lizenztypen stimmen überein.
• Beide Geräte sind registriert.
• Beide Geräte laufen auf gleicher SFOS-Version inklusive Build.
• Der relevante Traffic profitiert tatsächlich von Active-Active.
• Dienste mit Active-Active-Einschränkungen wurden geprüft.
• Monitoring und Troubleshooting sind auf beide Nodes ausgelegt.

2. Primary Firewall konfigurieren

1. Zu System services > High availability wechseln.
2. Primary (active-active) auswählen.
3. QuickHA verwenden.
4. Node-Namen vergeben.
5. HA-Passphrase setzen.
6. Dedicated HA link auswählen.
7. HA starten.

3. Auxiliary Firewall konfigurieren

1. Auf dem zweiten Gerät zu System services > High availability wechseln.
2. Auxiliary auswählen.
3. QuickHA verwenden.
4. Dieselbe Passphrase eintragen.
5. Denselben HA-Link-Port auswählen.
6. HA starten.

4. Nach der Einrichtung testen

Bei Active-Active muss mehr getestet werden als nur der HA-Status:

• Werden Verbindungen auf beide Nodes verteilt?
• Sind Logs auf beiden Geräten sichtbar?
• Funktionieren VPN-Verbindungen nach einem Rollenwechsel?
• Funktionieren Web Protection, IPS, Application Control und relevante Security Features?
• Gibt es Anwendungen, die durch asymmetrisches Verhalten auffallen?
• Werden Reports und Alerts erwartungsgemäss erzeugt?

Manuelle HA-Konfiguration

Die manuelle HA-Konfiguration ist sinnvoll, wenn die automatische QuickHA-Logik nicht genug Kontrolle bietet.

Typische Gründe:

• feste HA-Link-IP-Adressen sollen verwendet werden
• Peer Admin Port muss genau definiert werden
• Cluster ID soll bewusst gesetzt werden
• mehrere HA-Cluster existieren im gleichen Layer-2-Umfeld
• virtuelle Appliances sollen mit bestimmten MAC-Optionen betrieben werden
• ein sehr kontrollierter Rollout ist notwendig

Bei der manuellen Einrichtung wird zuerst die Auxiliary Firewall vorbereitet und danach die Primary Firewall konfiguriert. Die Primary muss die HA-Link-IP-Adresse des Peers kennen.

Wichtige Felder:

• Operation mode: Active-Passive oder Active-Active.
• Initial device role: Primary oder Auxiliary.
• Dedicated HA link: Interface für Heartbeat, Status und Synchronisierung.
• Peer HA link IPv4: Adresse des HA-Link-Interfaces auf dem zweiten Gerät.
• Cluster ID: Grundlage für virtuelle MAC-Adressen. Bei mehreren Clustern eindeutig setzen.
• Monitored ports: Kritische Ports, deren Ausfall ein Failover auslösen soll.
• Peer administration settings: Zugriff auf die Auxiliary Firewall.
• Preferred primary: Gerät, das nach Failover wieder Primary werden soll.
• Keepalive interval / Attempts: Empfindlichkeit der HA-Erkennung. Nur bewusst anpassen.

Cluster validieren

Nach der Einrichtung sollte der HA-Cluster systematisch geprüft werden.

WebAdmin-Prüfung

1. Auf der Primary Firewall anmelden.
2. Oben rechts den HA-Status prüfen.
3. Zu System services > High availability wechseln.
4. Rollen, Status, Seriennummern und Modus prüfen.
5. Sicherstellen, dass der Cluster synchronisiert ist.
6. Bei Active-Passive prüfen, welches Gerät die Lizenz für den Cluster hält.

CLI-Prüfung

In der Device Console kann man den HA-Status anzeigen:

system ha show details

Wenn unklar ist, welches Gerät das lizenzhaltende Initial Primary ist, kann in der Advanced Shell dieser Wert helfen:

nvram get "#li.master"

YES steht für das initiale Primary-Gerät, NO für das Auxiliary-Gerät. Solche Befehle sollte man dokumentieren und nur in klaren Wartungs- oder Diagnosefällen nutzen.

Wenn der Shell-Zugriff noch nicht vorbereitet ist, hilft die Anleitung Sophos Firewall per SSH verbinden.

Funktionaler Test

• Client aus dem LAN ins Internet testen.
• Zugriff auf interne Server testen.
• VPN testen.
• DNAT- oder WAF-Szenarien testen.
• DNS und DHCP testen, falls die Firewall diese Dienste bereitstellt.
• Logs im Log Viewer prüfen.
• HA-Rollenwechsel in einem Wartungsfenster testen.
• Danach Rollen, Status und Session-Verhalten dokumentieren.

Betrieb und Pflege

Laufende Überwachung

Ein HA-Cluster sollte aktiv überwacht werden. Nur weil zwei Firewalls im Rack stehen, ist die Umgebung nicht automatisch hochverfügbar.

Überwacht werden sollten:

• HA-Status
• Rollenstatus Primary/Auxiliary
• HA-Link
• Monitored Ports
• Lizenz- und Subscription-Status
• Firmware-Versionen
• Ressourcen wie CPU, RAM, Disk
• zentrale Dienste wie IPS, Web, VPN, DNS, DHCP
• Logs im Log Viewer
• Alerts in Sophos Central oder per E-Mail

Für Disk- und Hardwarethemen sollte man beide Nodes getrennt betrachten. Lokale Reports, Logdateien und SSD-Zustand können sich unterscheiden. Dazu passen die Artikel Sophos Firewall Speicherplatz prüfen und Reports verwalten und Sophos Firewall SSD-Gesundheit per SMART prüfen.

Logs und Reports

Logs und Reports werden nicht einfach zu einem gemeinsamen lokalen Datenbestand verschmolzen. Jedes Gerät schreibt Logs für den Traffic, den es verarbeitet. In Active-Active ist das besonders wichtig, weil Traffic auf beiden Nodes auftauchen kann.

Sophos Central Firewall Reporting ist in HA-Umgebungen hilfreich, weil es Daten über mehrere Firewalls zentral auswerten kann. Lokale Troubleshooting-Logs findet man auf der Firewall selbst. Der Artikel Sophos Firewall Troubleshooting: Services und Logs erklärt, welche Services und Logdateien für Analysen relevant sind.

Runbook für den HA-Betrieb

Ein HA-Cluster braucht ein kurzes Betriebs-Runbook. Darin sollte stehen, welches Gerät das Initial Primary ist, welche Ports überwacht werden, wie man die Auxiliary erreicht, wer Firmware-Updates freigibt und wann HA für Austausch oder Reimage deaktiviert wird.

Mindestens dokumentieren:

• Seriennummer, Standort, Rackposition und Rolle beider Appliances.
• Dedicated HA link, Peer Admin Port, Cluster ID und Monitored Ports.
• Preferred primary und erwartetes Verhalten nach Failover.
• Lizenzhalter, Supportstatus und RMA-Kontaktweg.
• Vorgehen für Firmware-Update, Backup, Reimage und Hardwaretausch.
• Zuständige Person für Logs, Central Reporting, Syslog und Supportfälle.

Wenn nur der WebAdmin auf einem Node hängt, ist nicht automatisch der ganze HA-Cluster defekt. Dann sollte man gezielt prüfen, ob ein Neustart der WebAdmin GUI oder ein kontrollierter Service-Neustart ausreicht, bevor man Failover oder Reboot auslöst.

Änderungen am Cluster

Konfigurationsänderungen werden auf der Primary Firewall vorgenommen. Die Auxiliary Firewall ist nicht der Ort für normale Regel-, Interface- oder Policy-Änderungen.

Vor grösseren Änderungen:

• Backup erstellen.
• Wartungsfenster definieren.
• HA-Status prüfen.
• Dokumentation aktualisieren.
• Rollback-Weg festlegen.
• Nach der Änderung Synchronisierung und Traffic testen.

Das gilt besonders für:

• Interfaces
• VLANs
• LAGs
• Zonen
• Routing
• NAT
• VPN
• Device Access
• SD-WAN

Firmware-Updates und Backups

Firmware-Updates in HA-Umgebungen

Firmware-Updates werden auf der Primary Firewall gestartet. Die Geräte werden nacheinander aktualisiert, und der Cluster kann währenddessen die Rollen wechseln.

Typischer Ablauf:

1. Update auf der Primary Firewall starten.
2. Auxiliary Firewall wird aktualisiert.
3. Auxiliary Firewall startet neu und übernimmt temporär.
4. Bisherige Primary wird aktualisiert.
5. Bisherige Primary startet neu.
6. Wenn Preferred primary aktiv ist, kann ein Rückwechsel auf das bevorzugte Gerät erfolgen.

Trotzdem gilt: Firmware-Updates gehören in ein Wartungsfenster. Auch wenn der Prozess auf minimale Downtime ausgelegt ist, können einzelne Sessions, VPN-Verbindungen oder spezielle Anwendungen kurz reagieren.

Zur Vorbereitung passt Sophos Firewall Firmware Update - Vorbereitung und Best Practices.

Pattern Updates

Pattern Updates werden auf der Primary Firewall installiert und auf die Auxiliary Firewall synchronisiert. Das gilt auch für Umgebungen, in denen Updates kontrolliert oder offline eingespielt werden.

Wenn ein HA-Cluster in einer isolierten Umgebung betrieben wird, sollte vor jedem manuellen Pattern- oder Lizenzupdate klar sein, welcher Node der Initial Primary ist und welcher Node aktuell Primary ist. Der Air-Gap-Ablauf ist in Sophos Firewall Air-Gap-Lizenzierung und Pattern-Updates betreiben beschrieben.

Backup und Restore

Backup und Restore haben in HA-Umgebungen Besonderheiten:

• Backups sollten regelmässig und vor jeder grösseren Änderung erstellt werden.
• Restore erfolgt auf die aktuelle Primary Firewall.
• Nach Restore werden beide Firewalls aus Sophos Central deregistriert und müssen wieder registriert werden.
• Restore verursacht Neustart und Downtime, kein normales Failover.
• Wenn ein Backup ohne HA-Konfiguration auf einen HA-Cluster restored wird, wird HA deaktiviert und muss neu aufgebaut werden.

Austausch eines Cluster-Knotens

Beim Austausch oder Reimage eines Knotens sollte HA nicht einfach mit dem alten Peer weiterlaufen gelassen werden.

Wichtige Punkte:

• Sophos unterscheidet beim RMA-Ablauf, ob die Auxiliary oder die Primary ersetzt wird.
• RMA und Reimage in Active-Passive verursachen geplante Downtime und sollten nicht als normales Failover behandelt werden.
• Vor Reimage oder Ersatz HA sauber deaktivieren.
• Firmware-Version und Build dokumentieren.
• Backup erstellen.
• Lizenzhalter identifizieren.
• Gerät aus Sophos Central Management entfernen, wenn es retourniert oder ersetzt wird.
• Neues Gerät registrieren.
• HA neu konfigurieren, weil die alte HA-Passphrase nicht für ein neues Gerät wiederverwendet wird.

Wenn die Auxiliary ersetzt wird, läuft die gesunde Primary typischerweise zunächst als Standalone-HA-Gerät weiter. Wenn die Primary ersetzt wird, muss besonders sorgfältig geklärt werden, welches Gerät das Initial Primary war, welches Backup verwendet wird und wann die Kabel auf das Ersatzgerät umgesteckt werden. In beiden Fällen sollten Modell, Hardware-Revision, Firmware-Version, Build, Lizenztransfer, Sophos-Central-Status und der msync-Status dokumentiert werden. Der Dienst und die passende Logdatei sind im Artikel Sophos Firewall Troubleshooting: Services und Logs eingeordnet.

Für die technische Neuinstallation passt Sophos Firewall OS neu installieren: Reimage mit USB-Stick. Wenn ein Hardwaredefekt oder RMA-Prozess im Raum steht, sollte zusätzlich Sophos Hardwaredefekt und RMA richtig vorbereiten eingeplant werden.

Troubleshooting

Bei tiefen Fehlerbildern sollte man strukturiert bleiben: zuerst Status, HA-Link, Monitored Ports, Firmwarestand und Lizenzstatus prüfen, danach erst Spezialfälle oder Herstellerhinweise heranziehen. So bleibt klar, ob ein echtes HA-Problem vorliegt oder ob Lizenz, Interface, Firmwarestand oder Monitoring den Fehler auslösen.

Wichtige Logs und Diagnoseorte

• HA-Status: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Diagnostics > Tools oder per SSH unter /log.
• HA-Details CLI: system ha show details.
• Interface-Probleme: show network interfaces, ifconfig, dmesg in passenden Diagnosefällen.
• Lizenzhalter: WebAdmin HA-Ansicht oder nvram get "#li.master".

Bei tieferen Analysen hilft oft der Artikel Sophos Firewall CLI Troubleshooting: wichtige Befehle.

Typische HA-Fehlerbilder

• Cluster wird nicht gebildet, Firmware-Version oder Build unterschiedlich: Version auf beiden Geräten prüfen und beide Firewalls auf identische SFOS-Version bringen.
• Cluster wird nicht gebildet, Modell oder Appliance passt nicht: Modell und Seriennummer prüfen. Für Hardware-HA nur kompatible gleiche XGS-Modelle verwenden.
• HA could not be enabled: Dedicated HA link ist möglicherweise nicht verbunden oder der Peer ist nicht erreichbar. Portstatus, Kabel, Switch und Ping auf die HA-Link-IP prüfen, dann Verkabelung oder HA-Link stabilisieren.
• HA-Link down: Kabel, Switchport, VLAN oder LAG kann fehlerhaft sein. Interface-Status, Speed/Duplex, VLAN-Trunk und LAG-Mitglieder prüfen.
• Beide Geräte werden Standalone: Der HA-Link ist ausgefallen, Split-Brain-Gefahr. Physische HA-Link-Verbindung und Switchpfad prüfen, ein Gerät kontrolliert herunterfahren, HA-Link reparieren und danach wieder starten.
• Auxiliary WebAdmin nicht erreichbar: Peer Admin Port, Subnetz, Route oder Device Access passen nicht. Admin-Port-IP und Zugriff aus dem Managementnetz prüfen.
• Validation failed for HA interface IP: Admin-Ports oder HA-Link-Adressen liegen nicht im erwarteten Subnetz. IP-Adressen und /log/syslog.log prüfen und Adressierung korrigieren.
• Failover passiert unerwartet: Häufig ist ein Monitored Port ausgefallen oder falsch ausgewählt. Monitored Ports und Switchstatus prüfen und nur wirklich kritische stabile Ports überwachen.
• Failover passiert nicht: Der relevante Port wird wahrscheinlich nicht überwacht. Kritische WAN-, Core- oder DMZ-Ports als Monitored Ports eintragen.
• Active-Active verteilt nicht wie erwartet: Die Traffic-Art wird möglicherweise nicht load-balanced. Verbindungstyp, Protokoll und Logs beider Nodes prüfen; bei unklarem Nutzen Active-Passive verwenden oder Design anpassen.
• Logs fehlen scheinbar: Traffic wurde eventuell vom anderen Node verarbeitet oder Logging ist nicht aktiv. Auf beiden Nodes und im Log Viewer prüfen, Logging in Regeln aktivieren und Central Reporting oder Syslog nutzen.
• Reports unterscheiden sich: Lokale Reports sind nodebezogen. Reports beider Geräte vergleichen oder Sophos Central Firewall Reporting nutzen.
• Lizenzproblem in Active-Active: Lizenztypen stimmen möglicherweise nicht überein. Licensing auf beiden Firewalls prüfen und Lizenzen angleichen.
• Probleme nach Firmware-Update: Ein Node ist nicht sauber aktualisiert oder der Cluster ist nicht synchron. HA-Status, Firmware-Versionen und Logs prüfen; bei produktiven Clustern Wartungsfenster nutzen und Sophos Support einbeziehen.
• Flexi-Port-HA-Link funktioniert nicht: Speed/Duplex oder Auto-Negotiation passt nicht. Interface Advanced settings auf beiden Geräten prüfen und beide Seiten gleich konfigurieren oder festen Port verwenden.

Vorgehen bei HA-Link-Ausfall

Wenn der dedizierte HA-Link ausfällt, ist Vorsicht nötig. Beide Firewalls können sich gegenseitig nicht mehr sehen. Im ungünstigen Fall senden beide Geräte ARP/GARP und versuchen, die Cluster-MAC für sich zu beanspruchen.

Sicheres Vorgehen:

1. Netzwerkzustand stabilisieren.
2. Entscheiden, welches Gerät aktiv bleiben soll.
3. Das andere Gerät kontrolliert herunterfahren oder vom Produktionsnetz trennen.
4. HA-Link-Kabel, Switchport, VLAN oder LAG reparieren.
5. Gerät wieder starten.
6. HA-Status prüfen.
7. Logs und Rollen kontrollieren.

Relevante CLI-Befehle

system ha show details

Zeigt HA-Details in der Device Console.

show network interfaces

Hilft bei Interface-Status und Linkinformationen.

nvram get "#li.master"

Zeigt in der Advanced Shell, ob das Gerät das lizenzhaltende Initial Primary ist.

dmesg | grep PortE

Kann bei bestimmten Hardware-/Interface-Problemen Hinweise auf Link-Flaps geben.

Nicht jeder Befehl gehört in jede Umgebung. Für produktive Systeme gilt: Erst Zustand dokumentieren, dann gezielt prüfen.

Best-Practice-Checklisten

Planung

• Active-Passive als Standardvariante prüfen.
• Active-Active nur mit klarem Performance-Ziel einsetzen.
• Beide Geräte auf Modell, Firmware, Flexi Ports und Lizenzierung prüfen.
• HA-Link dediziert und möglichst direkt verkabeln.
• Monitored Ports bewusst auswählen.
• Management-Zugriff auf Primary und Auxiliary planen.
• Cluster ID eindeutig dokumentieren.
• Switchdesign, VLANs und LAGs dokumentieren.
• RSTP auf relevanten Switches einplanen.
• Split-Brain-Szenario durchdenken.
• Backup- und Restore-Prozess dokumentieren.

Implementierung

• Vorher Backup erstellen.
• Beide Firewalls auf dieselbe SFOS-Version bringen.
• Cellular WAN deaktivieren.
• HA-Link mit statischer Adressierung und DMZ-Zone vorbereiten.
• SSH für die HA-Link-Zone erlauben.
• Primary und Auxiliary sauber benennen.
• Passphrase nur für die Einrichtung verwenden und danach nicht als dauerhaftes Admin-Passwort behandeln.
• Nach QuickHA erweiterte Einstellungen prüfen.
• Monitored Ports erst setzen, wenn klar ist, welche Links stabil und kritisch sind.
• Failover in einem Wartungsfenster testen.

Betrieb

• HA-Status regelmässig prüfen.
• Lizenzen und Synchronisierung überwachen.
• Firmware-Updates nur vorbereitet und mit Wartungsfenster durchführen.
• Backups regelmässig testen.
• Konfigurationsänderungen nur auf der Primary vornehmen.
• Nach Switch-, VLAN- oder Interface-Änderungen HA-Status prüfen.
• Logs beider Nodes einbeziehen.
• Sophos Central Firewall Reporting oder Syslog für längere Analysen nutzen.
• Austausch oder Reimage eines Knotens nur mit geplantem HA-Disable und Reconfigure durchführen.

Don’ts

• Keine unterschiedlichen Modelle clustern.
• Keine Wi-Fi-XGS-Modelle für HA planen.
• Kein Cellular WAN in HA aktiv lassen.
• Keine unverkabelten Ports als Monitored Ports setzen.
• Kein instabiles VLAN oder Switchpfad als HA-Link verwenden.
• Keine produktiven Dienste über den HA-Link führen.
• Active-Active nicht als einfache Verdopplung der Performance betrachten.
• Keine Änderungen auf der Auxiliary Firewall erwarten oder planen.
• Kein Restore ohne Wartungsfenster durchführen.

FAQ