Sophos Firewall High Availability (HA) einrichten

High Availability, kurz HA, verbindet zwei Sophos Firewalls zu einem Cluster. In den meisten Umgebungen ist Active-Passive mit QuickHA die beste Wahl: Eine Firewall verarbeitet den Traffic, die zweite übernimmt bei Ausfall oder Wartung. Vor dem Start müssen beide Geräte, Firmware-Build, Lizenzen, Verkabelung und Managementzugriff zusammenpassen.

Dieser Artikel führt von der Auswahl des HA-Modus über die Einrichtung bis zu Failover-Test, Betrieb und RMA. HA ersetzt weder ein sauberes Netzwerkdesign noch Backups.

HA-Modus und Architektur wählen

Avanet-Betriebsempfehlung: 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. Das ist eine Designempfehlung, keine Vorgabe von Sophos.

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 gilt:

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

Die beiden Sophos-Techvids zeigen Einrichtung und Rollenwechsel visuell:

Was High Availability 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 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.
• Bei Verwendung der virtuellen Cluster-MAC übernimmt die Auxiliary Firewall bei Failover mit derselben virtuellen MAC-Adresse.
• In diesem Fall müssen Netzwerkgeräte 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 die Quell-IP-Adresse: Geeignete TCP-Verbindungen von geraden Quell-IP-Adressen verarbeitet die Primary, ungerade gehen an die Auxiliary. Verteilt werden weitergeleiteter TCP-Traffic sowie übersetzte TCP-Verbindungen, einschliesslich SNAT und Virtual-Host-Traffic, auch über VLAN-Interfaces. Hat die Auxiliary eine Verbindung verarbeitet, sendet sie die Pakete direkt zum Ziel und nicht zurück über die Primary. Dieses Gerade-Ungerade-Verfahren ist fest vorgegeben und kann nicht geändert werden. Die Layer-7-Unterstützung ist differenziert: DPI Engine, transparente, direkte und Parent Proxies sowie SMTP-Proxy-Traffic und HTTPS sind laut Sophos load-balancing-fähig. Gescanntes FTP und H.323 sind es nicht. Ebenfalls ausgeschlossen sind Nicht-TCP-Traffic wie UDP, ICMP, Multicast und Broadcast, SD-RED sowie getunnelter TCP- und Nicht-TCP-Traffic einschliesslich VPN. Externe Load Balancer werden für HA nicht unterstützt.

Beide Nodes benötigen passende Lizenzen und schreiben die Logs des jeweils verarbeiteten Traffics lokal. Active-Active ist deshalb nur sinnvoll, wenn ein klares Performance-Ziel besteht und der relevante Traffic nachweislich verteilt wird. Für reine Hochverfügbarkeit ist Active-Passive meist sauberer.

Rollen, Status und Failover

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. Diese Eigentümerrolle bleibt bestehen, unabhängig davon, ob der Node aktuell Active oder Passive ist.
• Preferred primary: Bevorzugtes Gerät, das nach einem Failover wieder Primary werden soll, sobald es stabil verfügbar ist.

Im Active-Passive-Modus zeigt WebAdmin auf der Auxiliary keine Live Users, DHCP Leases oder aktiven IPsec-Verbindungen an. Das ist erwartetes Verhalten und kein Beweis für eine fehlerhafte Synchronisierung. Für diese Laufzeitdaten ist immer die aktuell aktive Primary massgebend.

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

Bei Verwendung der virtuellen Cluster-MAC weist SFOS den physischen Interfaces virtuelle MAC-Adressen zu, ausgenommen Dedicated HA Link und Administrationsports. Der Dedicated HA Link verwendet seine eigene physische MAC-Adresse. Nur die Primary beantwortet ARP-Anfragen für den Cluster. Bei einem Failover übernimmt die Auxiliary die virtuelle MAC-Adresse des jeweiligen produktiven Interfaces. Dadurch bleibt die Erreichbarkeit für Switches, Router und Clients stabiler, weil sich IP- und MAC-Zuordnung nicht grundlegend ändern. Die unten beschriebene Interface-MAC-Option ist eine andere Variante; für sie darf man nicht dieselbe Übernahme der virtuellen MAC voraussetzen.

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. In Active-Active tauschen beide Geräte Status und Details aktiver Sessions mit dem Peer aus; die Konfigurationssynchronisierung bleibt dagegen von Primary zu Auxiliary gerichtet.
• Secure Storage Master Key und WebAdmin-Zugangsdaten werden synchronisiert.
• Dedicated HA link und Administrationsports sind laut offizieller Beschreibung der HA-Modi und Rollen von der Konfigurationssynchronisierung ausgeschlossen. Die widersprüchlichen Vorgaben zur Managementadressierung werden unter Netzwerkvoraussetzungen erläutert.
• Logs und Reports werden nicht zwischen den Geräten synchronisiert.

Failover-Verhalten

In Active-Passive übernimmt die Auxiliary den gesamten Traffic, wenn die Primary ausfällt. In Active-Active kann dagegen der Ausfall eines der beiden aktiven Geräte die Übernahme durch den gesunden Peer auslösen. Fällt die Auxiliary aus, verarbeitet die Primary den gesamten Traffic allein; das ist nicht zwingend ein Rollenwechsel. Ist ein Peer nicht mehr verfügbar, arbeitet das verbleibende Gerät als Standalone. Dieser Status allein beweist daher noch keinen beidseitigen HA-Link-Ausfall; Rollen und Erreichbarkeit beider Nodes prüfen, bevor man das Split-Brain-Runbook anwendet.

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

Startet ein einzelner Node im Failsafe-Modus, werden zuerst dessen Rolle und der Zustand des Peers dokumentiert. Der Ablauf Sophos Firewall im Failsafe-Modus prüfen zeigt den sicheren Diagnoseablauf und erklärt, warum beide Nodes nicht unkoordiniert neu gestartet oder HA auf Verdacht deaktiviert werden sollten.

Die Heartbeats über den Dedicated HA Link sind VRRP-Anfragen. SFOS 22 verwendet standardmässig 250 ms und 16 fehlende Heartbeats, also einen Heartbeat-Timeout von 4 Sekunden. SFOS 23 verwendet standardmässig 100 ms und 3 Versuche, also 300 ms Heartbeat-Timeout; für LAG-basierte HA-Links sind andere Werte erforderlich, wie unten beschrieben. Diese Timeouts garantieren keine Dauer bis zur Wiederherstellung des Traffics. Bei Monitored Ports reicht dagegen bereits ein ausgefallener Port, damit das Gerät als nicht verfügbar gilt und ein Failover ausgelöst wird.

Abweichende Heartbeat-Angaben für SFOS 23: Die allgemeine Failover-Beschreibung nennt weiterhin 250 ms und 16 Versuche, die detaillierte SFOS-23-Einrichtung dagegen 100 ms und 3 Versuche. Die hier genannten SFOS-23-Defaults stammen aus der detaillierten Einrichtung, nicht aus einer Messung am Gerät. Vor einer Änderung unter System services > High availability die tatsächlich konfigurierten Werte und die HA-Link-Topologie auf beiden Nodes dokumentieren. Weder die ältere Angabe noch der kürzere Setup-Default ist ein Grund, einen bestehenden Cluster ungeprüft umzustellen; bei unklaren oder nicht zur LAG-Vorgabe passenden Werten die Planung mit Sophos Support klären.

Beim Failover zeigt WebAdmin auf der bisherigen Auxiliary Firewall die Konfiguration der Primary. Für laufende Sessions gelten unterschiedliche Grenzen:

Kehrt die Initial Primary zurück, bleibt sie ohne Preferred primary als Auxiliary im Cluster. Ist sie als Preferred primary festgelegt, synchronisiert SFOS zuerst die Dienste und führt danach automatisch zurück. Dabei startet das bis dahin allein arbeitende Gerät neu. Dieser Failback gehört deshalb in ein Wartungsfenster. Die beschriebenen Rollenwechsel und Neustarts garantieren keine unterbrechungsfreie Verarbeitung bestehender Verbindungen.

Unterstützte und eingeschränkte Dienste

Sophos HA unterstützt die meisten Firewall-Dienste. Die Betriebsgrenzen unterscheiden sich jedoch deutlich:

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.

Für Konfiguration, Sicherheitsgrenzen und Tests verwendet man die Anleitung mDNS Reflector konfigurieren. Diensterkennung erlaubt noch keinen Anwendungszugriff; die HA-Unterstützung garantiert keine unterbrechungsfreien Anwendungssessions. Diese mDNS-Aussage gilt für SFOS 23, nicht für SFOS 22.

Voraussetzungen und Netzwerkdesign

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 vom selben XGS Appliance-Modell sein, zum Beispiel XGS 2100 mit XGS 2100.
• Hardware-Revision: Unterschiedliche Hardware-Revisionen sind bei gleichem XGS Appliance-Modell möglich.
• XGS Appliance Wi-Fi Modelle: Nicht unterstützt. Beispiele sind XGS 126w oder XGS 136w.
• Flexi Port Module: Wenn Erweiterungsmodule genutzt werden, müssen Anzahl und Modulmodell 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.

Wichtig: Flexi-Port-Module sind nicht hot-swappable. Für eine Nachrüstung beide Firewalls kontrolliert herunterfahren, auf beiden Geräten dasselbe Modulmodell einsetzen und beide Geräte wieder starten. Die neuen Flexi Ports danach ausschliesslich auf der aktuellen Primary unter Network > Interfaces konfigurieren. SFOS synchronisiert diese Portkonfiguration auf die Auxiliary. Nicht nur einen Node im laufenden Cluster umbauen.

SFOS 22 unterstützt keine XG- oder SG-Series Hardware mehr. Solche Geräte müssen vor einer Migration auf SFOS 22 durch eine unterstützte XGS-Appliance oder eine passende virtuelle Plattform ersetzt werden.

Virtuelle und Software-Appliances

Virtuelle oder Software-Appliances müssen ebenfalls sehr sauber zueinander passen. Beispiele für virtuelle Plattformen sind Microsoft Hyper-V, VMware und Nutanix Prism; Software-Appliances laufen auf eigener Hardware. Die Nennung einer Plattform ersetzt nicht die Prüfung der folgenden HA-Anforderungen.

• Plattform: Gleicher Appliance-Typ und gleiche SFOS-Plattform.
• Hypervisor: Gleicher Hypervisor-Typ.
• Ressourcen: Identisch zugewiesene Hardware-Ressourcen, darunter dieselbe Anzahl CPU-Kerne, sowie dieselbe 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.

Verwendet der Cluster die von SFOS erzeugte virtuelle MAC-Adresse, muss die Virtualisierungsplattform MAC-Wechsel akzeptieren. Bei VMware ESXi im vSwitch oder in der Port Group MAC Address Changes und Forged Transmits auf Accept setzen; Port Groups müssen die vSwitch-Werte erben oder selbst passend konfiguriert sein. Bei Hyper-V Enable MAC address spoofing auf allen virtuellen Netzwerkadaptern der beiden Firewalls aktivieren, ausser auf dem Adapter des Dedicated HA Link. Alternativ in SFOS 22 Use host or hypervisor-assigned MAC address oder in SFOS 23 Use interface MAC address wählen; beide verwenden bei virtuellen Appliances die vom Hypervisor zugewiesene MAC, sodass diese Plattformänderungen entfallen. Die SFOS-23-Option verwendet bei Hardware-Appliances stattdessen die Interface-MAC anstelle der virtuellen Cluster-MAC. Ein- oder Ausschalten aktualisiert die Interface-Konfiguration und verursacht 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.

Gateway, Bridge und Discover/TAP

HA ist im Gateway- und Bridge-Modus möglich. Im Discover- oder TAP-Modus wird dagegen nur Active-Passive unterstützt. Sobald mindestens ein Node im Discover-Modus arbeitet, kann kein Active-Active-Cluster aufgebaut werden. Ein laufendes TAP-Interface blockiert auch den Active-Passive-Aufbau: Das TAP-Interface deshalb per CLI auf beiden Firewalls deaktivieren, HA aufbauen und TAP danach auf jedem Node einzeln wieder aktivieren. TAP bleibt auch auf der passiven Auxiliary aktiv.

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; sie endet dort mit dem End of Life des Geräts. Bei Cloud-, Virtual- und Software-Appliances läuft die Base Firewall Lizenz nicht ab, muss für HA aber vorhanden 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 vor der HA-Einrichtung in Sophos Fusion (ehemals Sophos Central) geclaimt 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 Advance Hardware Replacement benötigt das Primary-Gerät eines Active-Passive-Hardware-Clusters Enhanced Plus Support. In Active-Active benötigt jedes Gerät entweder Enhanced Support oder Enhanced Plus Support.

HA-Paar in Sophos Fusion verwalten

Ein HA-Paar kann an Access-Layer-Switches angeschlossen werden, darunter Sophos Switches. Sophos Fusion, ehemals Sophos Central, ermöglicht die zentrale Verwaltung der Firewalls und der Sophos Switches. Das ersetzt kein redundantes Switch-Design: Ein gemeinsam genutzter Switch kann weiterhin beide Nodes betreffen. Die ältere SFOS-23-Übersicht verwendet noch den Namen Sophos Central; daraus folgt keine andere HA-Architektur.

Ein bereits aufgebautes HA-Paar wird in Sophos Fusion als ein gemeinsames Paar verwaltet, nicht als zwei unabhängige Firewalls. Beide Nodes benötigen denselben Firmwarestand und für Central Management einen funktionierenden IPv4-Internetzugang sowie die passende Subscription. Claiming und Lizenzsynchronisierung allein aktivieren die Verwaltung noch nicht.

Werden zwei bereits eigenständig durch Sophos Fusion verwaltete Firewalls zu einem HA-Paar, empfiehlt Sophos, beide zuerst aus Central zu deregistrieren. Danach HA lokal aufbauen, das fertige Paar erneut für Central Management registrieren und bei Bedarf in eine andere Central-Gruppe verschieben.

Auf der aktuellen Primary unter System > Sophos Central wird Register both HA devices gewählt. Danach Central Management aktivieren und in Sophos Fusion unter My Products > Firewall Management > Firewalls beim Eintrag der Primary die Anzeige Approval Pending öffnen und accept-services bestätigen. Nach einigen Minuten sollte das Paar einmal mit HA-Symbol erscheinen; Änderungen aus Sophos Fusion gelten dann für beide Firewalls.

Der Central-Status ersetzt die lokale Abnahme nicht. Nach der Registrierung HA-Rollen, Synchronisierung, Lizenzstatus und einen harmlosen Konfigurationsabgleich lokal prüfen. Erscheinen zwei unabhängige Einträge oder bleibt Approval Pending bestehen, keine der beiden Firewalls vorsorglich deregistrieren, sondern zuerst Seriennummern, Central-Tenant, IPv4-Pfad und lokalen HA-Status vergleichen.

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.

Lizenz auf der falschen Firewall – nur Active-Passive: Wurden in Active-Passive die Subscriptions irrtümlich der Auxiliary statt der lizenzhaltenden Initial Primary zugewiesen, reicht eine Synchronisierung nicht aus. Vor jeder Änderung die irrtümlich lizenzierte Quellseriennummer der Auxiliary und die vorgesehene Zielseriennummer der Initial Primary getrennt von den aktuellen HA-Rollen dokumentieren und in SFOS sowie Sophos Fusion abgleichen. Dieser verkürzte Korrekturablauf gilt nur, wenn aktuelle Primary und Initial Primary dasselbe physische Gerät sind. Sind sie verschieden oder ist die Zuordnung unklar, vor HA-Deaktivierung oder Lizenztransfer stoppen und den passenden Ablauf anhand der Sophos-Anleitung oder mit Sophos Support klären; keinen Rollenrückwechsel improvisieren. Erst bei eindeutiger Zuordnung auf der aktuellen Primary HA geplant deaktivieren, in Sophos Fusion von der dokumentierten Quellseriennummer auf die dokumentierte Initial-Primary-Zielseriennummer übertragen und den Active-Passive-Cluster danach neu konfigurieren. Lizenztransfers sind auch bei RMA oder Modellwechsel relevant, benötigen aber die passende Anleitung für den konkreten Fall; wegen der Modellgleichheit müssen bei einem Modellwechsel beide HA-Geräte ersetzt werden. In Active-Active muss auch die Auxiliary eigene Lizenzen halten. Das ist kein Fehler und wird nicht mit diesem Transfer korrigiert. Dieses Active-Passive-Verfahren nicht ohne passende Sophos-Anleitung für Active-Active-RMA verwenden.

Abgelaufene oder nicht synchronisierte Active-Active-Lizenzen können Load Balancing stoppen und HA deaktivieren. Sophos beschreibt für Hardware und Virtual/Software den Beginn des Load-Balancing-Stopps widersprüchlich: Die Zusammenfassung nennt das Ende von drei Tagen, die Detailpunkte die ersten drei Tage und anschliessend die HA-Deaktivierung. Der genaue Beginn ist ungeklärt; daraus ergibt sich keine garantierte dreitägige Schonfrist. Lizenzprobleme zeitnah korrigieren und bei Bedarf mit Sophos Support einen sicheren Betriebsplan für den installierten Build klären. Bei der Erstkonfiguration wird Active-Active mit nicht passenden Lizenzen nicht aktiviert.

In Active-Passive synchronisiert man die Lizenzen der Primary. Die lizenzhaltende Initial Primary muss sie mindestens einmal innerhalb von 90 Tagen synchronisieren. Bei Hardware stoppen sonst die betroffenen Schutzsubscriptions; Base Firewall und Enhanced Support bleiben aktiv. Bei Virtual/Software wird die Base Firewall Lizenz deaktiviert, HA abgeschaltet und weitere Schutzfunktionen werden inaktiv. Online lizenzierte Cluster benötigen dafür DNS, korrekte Systemzeit, Routing und Internetzugriff zu den Sophos-Lizenzdiensten. Isolierte Cluster verwenden stattdessen den dokumentierten manuellen Air-Gap-Lizenzworkflow.

In Active-Active muss man auf Hardware und Virtual/Software die Lizenzen beider Geräte einzeln mit Sophos Fusion synchronisieren und den Erfolg auf Primary und Auxiliary prüfen. Passende Lizenztypen und vorhandene Lizenzen ersetzen diesen Schritt nicht. Bei Hardware bleiben Base Firewall und Enhanced Support bei den beschriebenen Lizenzproblemen aktiv; bei Virtual/Software deaktiviert eine deaktivierte Base Firewall Lizenz HA und macht die weiteren Lizenzen inaktiv. Keine ungeklärte Drei-Tage-Angabe als Synchronisierungsintervall verwenden.

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 erfolgreich synchronisiert wurden; in Active-Active Status und Zeitpunkt für beide Nodes getrennt
• 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.
• Interface-Adressen: Active-Active verlangt statische IP-Adressen auf allen Interfaces. Active-Passive erlaubt DHCP, DHCP Prefix Delegation oder PPPoE. Für die PPPoE-Verbindung gibt es kein Session-Failover.

Bei Active-Passive dürfen Produktionsinterfaces DHCP, DHCP Prefix Delegation oder PPPoE verwenden; Dedicated HA Link und beide Administrationsports benötigen trotzdem statische Adressen. In Active-Active müssen sämtliche Interfaces statisch adressiert sein. Die dokumentierte PPPoE-Grenze belegt keine pauschale Session-Failover-Ausnahme für DHCP-Interfaces: Adresszuweisung und DHCP-Protokolltraffic sind von der Erhaltung weitergeleiteter TCP-Sessions zu unterscheiden. Es gelten die oben beschriebenen Protokoll- und Dienstgrenzen; daraus folgt auch keine pauschale Garantie für alle Sessions auf DHCP-Interfaces.

Breakout-Interfaces werden auf der Primary konfiguriert. Bei einer neuen Breakout-Konfiguration zuerst die Primary neu starten, damit die Änderung angewendet wird, und anschliessend die Auxiliary neu starten. Ist die passende Breakout-Konfiguration auf der Primary bereits vorhanden, nach der Synchronisierung nur die Auxiliary neu starten. Existiert auf der Primary keine entsprechende Breakout-Konfiguration, löscht die Synchronisierung eine nur auf der Auxiliary vorhandene Breakout-Konfiguration. Die einzelnen Fälle erklärt Breakout-Interfaces konfigurieren.

Der HA-Link verarbeitet keinen normalen Client- oder Servertraffic. Er ist nur für Heartbeats, Status, Session-Synchronisierung, Konfigurationssynchronisierung und Active-Active-Verteilung relevant. Für HSRP kann er nicht wiederverwendet werden, weil HSRP-Hello-Nachrichten den Dedicated HA Link nicht durchlaufen. 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 zum WebAdmin der Auxiliary Firewall; das Admin-Endgerät muss im selben Subnetz wie deren Administrationsport liegen. QuickHA wählt dafür automatisch das Interface, über das die aktuelle WebAdmin-Sitzung läuft. Widersprüchliche offizielle Vorgaben zur Managementadressierung: Die HA-spezifischen Interface-Anforderungen verlangen für beide Administrations-/Managementports unterschiedliche statische IP-Adressen im selben Subnetz. Die offizielle Beschreibung der HA-Modi und Rollen schliesst Administrationsports und den Dedicated HA Link von der Synchronisierung aus. Die Anleitung zur Inbetriebnahme des Managementports untersagt dagegen unterschiedliche PortMGMT-IP-Adressen in HA mit der Begründung, dass die Konfiguration synchronisiert werde. Diese Vorgaben widersprechen sich; eine gemeinsame PortMGMT-IP plus zusätzliche Peer-Admin-IP ist keine belegte Auflösung. Vor der Einrichtung oder Änderungen an Managementadressen die aktuellen Primary-/Auxiliary-Rollen beziehungsweise bei noch eigenständigen Geräten die vorgesehenen Rollen, den exakten installierten SFOS-Build, das ausgewählte Admininterface und die aktuellen IP-Adressen dokumentieren, ein Backup sicher ablegen und einen separaten administrativen Zugang über Konsole oder lokalen Zugriff sicherstellen. Das für den installierten Build geltende Adressverhalten anhand der passenden Dokumentation verifizieren oder mit Sophos Support klären. Bleibt der Widerspruch ungeklärt, vor Initiate HA oder Änderungen an Managementadressen stoppen.

Die Standardadresse normaler Ports ist 172.16.16.16, jene eines dedizierten PortMGMT auf grösseren Appliances 10.0.1.1. Die Primary ist aus jeder Zone erreichbar, für die unter Administration > Device access HTTPS erlaubt wurde. Für WebAdmin auf der Auxiliary muss das Admin-Endgerät dagegen im selben Subnetz wie deren Administrationsport liegen.

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. QuickHA kann bis zu vier ungebundene physische Interfaces zu einem HA redundant link zusammenfassen; bei einem bereits konfigurierten LAG müssen die Parent Interfaces auf beiden Appliances gleich aufgebaut sein.

Bei SFOS 23 muss für einen Dedicated HA link mit LAG oder VLAN über LAG Keepalive request interval × Keepalive attempts ≥ 2500 ms gelten. Der SFOS-23-Setup-Default von 100 ms × 3 = 300 ms erfüllt diese LAG-Vorgabe nicht und darf hier nicht unverändert übernommen werden. Ein zulässiges Beispiel ist 250 ms × 10 Versuche = 2500 ms, kein allgemeiner Default. QuickHA erzeugt bei mehr als einem ausgewählten ungebundenen physischen Interface einen HA redundant link als LAG; die Vorgabe gilt deshalb auch für diese Topologie. Die tatsächliche Link-Konfiguration prüfen. Keine automatische Aushandlung passender Werte durch QuickHA voraussetzen; die konfigurierten Werte prüfen, bevor man sich im Produktivbetrieb auf den Cluster verlässt.

High-Speed-Ports: Bei 25-, 50- und 100-GbE-Ports der XGS 7500/8500 Series unter Network > Interfaces > Advanced settings auf beiden Seiten denselben Link mode mit passender Geschwindigkeit und Duplex wählen und mit Save speichern. Danach das Interface erneut zum Bearbeiten öffnen, Show recommended settings > Load recommended configuration für Negotiation und Forward Error Correction (FEC) verwenden und erneut mit Save speichern. Bleiben die Empfehlungen nach dem ersten Speichern und erneuten Öffnen leer, Auto-Negotiation für Media Type und FEC deaktivieren und die Änderung speichern. Bei anderen Ports Automatic oder identische Speed/Duplex-Werte nutzen und MTU sowie MSS auf den Defaultwerten belassen. Wählt QuickHA ein ungebundenes Interface, setzt SFOS dessen Advanced settings zurück; diese Werte nach dem HA-Aufbau erneut prüfen.

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.

Netzwerkdesign

Beide Firewalls müssen im Fehlerfall dieselbe Netzposition übernehmen können. Produktive Interfaces, VLAN-Trunks, LAGs, Switchports und Provideranschlüsse werden deshalb auf beiden Seiten gleichwertig verkabelt. WAN-Redundanz, SD-WAN und Provider-Failover bleiben separate Aufgaben; HA ersetzt sie nicht.

• Den Dedicated HA link möglichst direkt verbinden. Über Switches muss der Pfad stabil, latenzarm und paketverlustfrei sein.
• Standortübergreifende HA-Nodes sind nur über ein latenzarmes Layer-2-Netz in derselben Broadcast-Domain sinnvoll. Der Dedicated HA Link bleibt im selben IP-Subnetz; hohe Latenz oder Paketverlust machen dieses Design ungeeignet.
• RSTP auf den beteiligten Switches aktivieren sowie VLANs, Trunks und LAGs auf beiden Seiten identisch konfigurieren.
• Nur dauerhaft angeschlossene WAN-, Core- oder DMZ-Uplinks überwachen. Ein absichtlich unverbundener Monitored Port löst sonst Failover aus.
• VLANs und LAGs sind möglich, müssen aber auf beiden Nodes dieselben Parent Interfaces verwenden. Bridge Mode funktioniert, ist beim Troubleshooting jedoch komplexer als Gateway Mode.
• VPN-, RED- und Remote-Szenarien separat testen, weil nicht jede Session transparent übernommen wird.
• Managementzugriff und Device Access bewusst einschränken. Dazu passt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

Für Active-Active muss zusätzlich klar sein, welcher Engpass durch den tatsächlich verteilbaren TCP-Traffic entschärft wird. Sind Lizenzierung, Dienste und Troubleshooting auf beiden Nodes nicht geklärt, bleibt Active-Passive die bessere Wahl.

Achtung: Bei einem Split-Brain halten sich beide Firewalls für zuständig. Das kann doppelte IP- und MAC-Nutzung sowie einen Produktionsausfall verursachen. Wenn der HA-Link ausfällt, zuerst festlegen, welcher Node aktiv bleiben soll, und den anderen kontrolliert herunterfahren oder vom Produktionsnetz trennen.

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.
• Falls LINCE benötigt wird, den Modus vor HA auf beiden Geräten angleichen.

FIPS folgt einer anderen Reihenfolge als LINCE. Der FIPS-140-3-Modus wird zuerst auf der eigenständigen Primary aktiviert, was einen Factory Reset auslöst; beim anschliessenden HA-Aufbau aktiviert Sophos FIPS automatisch auf der Auxiliary.

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:

• Managementadressierung vorab klären: Wegen der oben beschriebenen widersprüchlichen Vorgaben aktuelle Primary-/Auxiliary-Rollen beziehungsweise vorgesehene Rollen noch eigenständiger Geräte, exakten SFOS-Build, ausgewähltes Admininterface und aktuelle IPs dokumentieren, Backup sicher ablegen und separaten Konsolen-/lokalen Adminzugang sichern. Das geltende Adressverhalten für den installierten Build verifizieren oder mit Sophos Support klären; bei ungeklärtem Widerspruch vor Initiate HA oder Managementadressänderungen stoppen.
• 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.

LINCE vor HA festlegen

Seit SFOS 21.5 MR1 lässt sich LINCE nach dem Aufbau eines HA-Clusters weder aktivieren noch deaktivieren. Wenn die Zertifizierung benötigt wird, muss man den folgenden Befehl in der Device Console auf beiden noch eigenständigen Firewalls ausführen.

Achtung: Vorher einen alternativen Adminzugang über WebAdmin oder die lokale Konsole sicherstellen. Der Befehl aktiviert LINCE, startet den SSH-Dienst neu und trennt bestehende SSH-Sitzungen.

system certification lince enable

Danach auf beiden Geräten den LINCE-Status prüfen und erst dann HA aufbauen. Bei einem Restore müssen Backup und Zielcluster denselben LINCE-Status haben.

Warum der LINCE-Modus nicht automatisch eine Zertifizierung des eingesetzten SFOS-Builds belegt und welche SSH-Algorithmen vor der Aktivierung geprüft werden müssen, erklärt LINCE-Modus auf Sophos Firewall einordnen und aktivieren.

QuickHA oder Interactive mode

• QuickHA: Standardfall. Schnell, robust und für die meisten Active-Passive- und Active-Active-Setups ausreichend.
• Interactive mode: Sinnvoll, wenn Admin-Ports, HA-Link-Adressen, Cluster ID, Monitored Ports und Detailwerte vor dem Aufbau bewusst vorgegeben werden müssen.

QuickHA fragt zunächst nur Rolle, Node-Name, Passphrase und Dedicated HA link ab. Die Passphrase muss 10 bis 20 Zeichen lang sein und mindestens einen Grossbuchstaben, einen Kleinbuchstaben, eine Zahl und ein Sonderzeichen enthalten. Sie wird einmal zum Erzeugen der SSH-Schlüssel verwendet und danach gelöscht. Vor dem Austausch eines Geräts in einem noch funktionierenden HA-Paar muss HA deshalb deaktiviert und anschliessend mit dem Ersatzgerät neu konfiguriert werden. Den gesonderten Ausgangszustand nach RMA und die abweichenden Reimage-Beschreibungen erläutern die entsprechenden Abschnitte weiter unten.

Vorbereitete QuickHA-Geräte suchen weiter nach ihrem Peer, bis sie ihn finden. Sie können deshalb vorab konfiguriert und erst danach am Ziel verbunden werden. Sobald ein Gerät den Peer gefunden hat und HA aufgebaut wird, lässt sich dieser Discovery-Vorgang nicht mehr stoppen. Interface-Auswahl, Passphrase und vorgesehener Peer müssen daher stimmen, bevor beide HA-Links gleichzeitig erreichbar sind.

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.

Node-Namen in QuickHA: In SFOS 22 ist die Namensvergabe optional. Bei SFOS 23 fordern die detaillierten Anleitungen einen Node-Namen, während die Beispielanleitungen ihn weiterhin als optional bezeichnen. Die folgende Checkliste vergibt deshalb auf beiden Geräten unterschiedliche, gut erkennbare Namen. Das ist eine konservative Anleitung und kein Nachweis, dass die GUI ein leeres Namensfeld ablehnt.

HA einrichten

Active-Passive mit QuickHA

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. Einen eindeutigen Node-Namen vergeben, zum Beispiel FW01.
6. Eine HA-Passphrase mit 10 bis 20 Zeichen sowie mindestens einem Grossbuchstaben, einem Kleinbuchstaben, einer Zahl und einem Sonderzeichen 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:

• Wenn QuickHA ein ungebundenes Interface verwendet, weist Sophos diesem Interface die DMZ-Zone und standardmässig 169.254.192.1 zu. SSH für die Zone wird automatisch aktiviert.
• Die Firewall entfernt abhängige Konfigurationen des gewählten HA-Link-Interfaces. Deshalb muss es frei von produktiven Abhängigkeiten sein.

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. Einen anderen Node-Namen als auf der Primary 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 Fusion Registrierung, falls verwendet

4. Monitored Ports setzen

Monitored Ports entscheiden, ob ein Interface-Ausfall ein Failover auslöst. Das Auswahlfeld heisst in SFOS 22 Select ports to be monitored, in den detaillierten SFOS-23-Anleitungen Monitored interfaces. 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.

Auswählbar sind physische Interfaces, LAGs und ungebundene Interfaces mit konfiguriertem VLAN. Ein ungebundenes Interface ohne VLAN kann nicht als Monitored Port gewählt werden. Monitored Ports benötigen in beiden HA-Modi statische IP-Adressen.

SFOS 23 erlaubt höchstens 24 Monitored ports. Die Auswahl vom Dedicated HA link getrennt halten und nur tatsächlich benötigte produktive Links aufnehmen.

HA funktioniert auch ohne ausgewählte Monitored Ports. Dann löst ein Produktionsport-Ausfall allein kein Failover aus; Heartbeat-, Geräte- oder Stromausfälle können weiterhin einen Rollenwechsel auslösen. Jeder tatsächlich ausgewählte Port muss auf beiden Nodes verbunden sein. Portstatus-Überwachung erkennt nicht jeden Ausfall eines vorgelagerten Providers.

Erweiterte HA-Einstellungen wie Monitored interfaces, Peer administration, Preferred primary und Keepalive-Werte werden nach dem QuickHA-Aufbau auf der aktuellen Primary geändert. Vorher Backup, Wartungsfenster und gesicherten Adminzugang prüfen; Änderungen an Peer administration oder Managementadressen sowie Initiate HA dürfen den oben beschriebenen Vorlauf zur Klärung der Managementadressierung nicht umgehen. Bei ungeklärtem Widerspruch stoppen. Die oben beschriebene MAC-Umstellung verursacht Downtime. Bei einem LAG-basierten HA-Link die Keepalive-Vorgabe beachten und Werte nicht im Status Standalone oder Faulty ändern. Nach der gewünschten Auswahl zum Seitenanfang zurückscrollen und Initiate HA wählen. Damit synchronisiert die Primary die Änderungen auf die Auxiliary. Anschliessend auf beiden Nodes HA-Rollen, Status, Synchronisierung und die geänderten Werte prüfen; bei Abweichungen zuerst HA-Link und Logs beider Geräte vergleichen. Dieser Abschluss gilt auch für die nachfolgende Active-Active-Variante und ist vom ersten Beitritt beider Geräte zu unterscheiden.

Active-Active mit QuickHA

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

Der Ablauf entspricht Active-Passive, auf FW01 wählt man jedoch Primary (active-active). Vorher müssen beide Geräte geclaimt sein, denselben SFOS-Build und passende Lizenztypen haben; alle Interfaces benötigen statische IP-Adressen. Monitoring und Troubleshooting müssen beide Nodes abdecken, und der relevante Traffic muss von der oben beschriebenen TCP-Verteilung profitieren.

Nach der Einrichtung testen

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

• Werden Verbindungen auf beide Nodes verteilt?
• Wurden die Lizenzen beider Nodes einzeln erfolgreich synchronisiert und Status sowie Zeitpunkt getrennt dokumentiert?
• 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?

Interactive mode

Interactive mode ist sinnvoll, wenn die automatische QuickHA-Logik nicht genug Kontrolle bietet.

Vor der Konfiguration müssen auf beiden Geräten unter Administration > Device access für die DMZ-Zone SSH sowie Ping/Ping6 erlaubt sein. Interactive mode wählt zunächst automatisch das erste DMZ-Interface als Dedicated HA link. Falls dieses Interface nicht vorgesehen oder produktiv belegt ist, wird vor dem Speichern ein freies physisches, VLAN- oder vorbereitetes LAG-Interface gewählt.

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

Im Interactive mode wird zuerst die Auxiliary und danach die Primary konfiguriert. Dadurch läuft die Peer-Erkennung auf der Primary nicht ab, während der zweite Node noch vorbereitet wird.

1. Auxiliary konfigurieren

1. Auf FW02 zu System services > High availability wechseln.
2. Initial device role > Auxiliary und HA configuration mode > Interactive mode wählen.
3. Node-Namen und eine Passphrase mit den oben genannten Regeln festlegen.
4. Den freien DMZ-Port für den Dedicated HA link auswählen. Die Firewall löscht vorhandene abhängige Konfigurationen dieses Interfaces.
5. Speichern und auf die Bestätigung warten, dass die Auxiliary-Konfiguration angewendet wurde.

2. Primary konfigurieren

1. Auf FW01 Primary (active-passive) oder Primary (active-active) und Interactive mode wählen.
2. Eine eindeutige Cluster ID und den Node-Namen festlegen.
3. Die Passphrase von FW02 einfügen.
4. Denselben Dedicated HA link sowie die statische HA-Link-IP-Adresse der Auxiliary angeben. Das Feld heisst in SFOS 22 Dedicated peer HA link IPv4 address, in den detaillierten SFOS-23-Anleitungen Peer IPv4 address of dedicated HA link. Beide HA-Link-Adressen müssen im selben Subnetz liegen. Dies ist nicht die Peer-Admin-Adresse unter Peer administration settings; deren Verhältnis zur Interface-IP ist vorab wie oben beschrieben zu klären.
5. Kritische Monitored ports auswählen; SFOS 23 erlaubt höchstens 24.
6. Unter Peer administration settings das Managementinterface und die für FW02 vorgesehene Peer-Admin-Adresse erst nach dem oben beschriebenen Vorlauf und der Klärung des Adressverhaltens für den installierten Build angeben. Bei ungeklärtem Widerspruch vor Adressänderungen oder Initiate HA stoppen.
7. Bei Bedarf in SFOS 22 für virtuelle Appliances Use host or hypervisor-assigned MAC address oder in SFOS 23 Use interface MAC address wählen. Die SFOS-23-Option verwendet bei virtuellen Appliances die Hypervisor-MAC und bei Hardware die Interface-MAC anstelle der virtuellen Cluster-MAC. Ein- oder Ausschalten verursacht Downtime.
8. Preferred primary festlegen und Initiate HA wählen.

Nach dem Aufbau die Keepalive-Werte nur ändern, wenn ein dokumentierter Grund vorliegt. SFOS 22 erlaubt Intervalle von 250–500 ms und 16–24 Versuche; die Defaults von 250 ms und 16 Versuchen ergeben 4 Sekunden Timeout. SFOS 23 erlaubt 100–500 ms und 3–24 Versuche; die Defaults von 100 ms und 3 Versuchen ergeben 300 ms Timeout. Für SFOS-23-Dedicated-HA-Links mit LAG oder VLAN über LAG muss das Produkt mindestens 2500 ms betragen: 250 ms × 10 Versuche ist ein zulässiges Beispiel, nicht der allgemeine Default. Auch von QuickHA erzeugte redundante LAGs darauf prüfen. In den Status Standalone oder Faulty lassen sich diese Werte nicht ändern. Nach dem Timeout führt die neue Primary zuerst interne Prüfungen aus und beginnt erst danach mit der Traffic-Verarbeitung. Keiner dieser Timeouts garantiert eine Wiederherstellungsdauer für den Traffic.

API-Abweichung in SFOS 22: Die Beschreibung von Keepalive attempts nennt 8–16 Versuche, die detaillierte Parameterbeschränkung und das XML-Beispiel dagegen 16–24. Der hier genannte Bereich folgt der detaillierten Beschränkung, nicht einem getesteten API-Ergebnis; 8–16 ist kein zweiter bestätigter Bereich. Vor Änderungen den installierten SFOS-Build und die aktuellen Keepalive-Werte beider Nodes dokumentieren. Bleiben die anwendbaren Limits unklar, diese vor einer Änderung mit Sophos Support klären; die LAG-Anforderungen bleiben zu beachten.

API-Vorabprüfung für SFOS 22 und 23: Die Parametertabellen dokumentieren ClusterId als optionale Ganzzahl von 0–63 mit Default 0 und NodeName als erforderliche Zeichenfolge mit 1–30 Zeichen. Auch mit dem dokumentierten Default muss jeder Cluster im gemeinsamen Layer-2-Netz eine eigene Cluster ID verwenden, um virtuelle MAC-Konflikte zu vermeiden. Diese API-Metadaten ändern die oben beschriebenen GUI-Hinweise zur optionalen beziehungsweise erforderlichen Namensvergabe nicht und belegen keine GUI-Validierung. Die Tabelle schreibt ClusterId, das XML-Beispiel ClusterID; daraus folgt weder eine getestete Zuordnung der Tags noch ein funktionsfähiger API-Payload.

In den erweiterten HA-Einstellungen von SFOS 23 ist Monitor hardware components optional und ergänzt einen Failover-Auslöser bei einem erkannten Problem eines Speichergeräts, zusätzlich zur Heartbeat- und Monitored-Interface-Ausfallerkennung. Weder eine standardmässige Aktivierung noch die Erkennung aller Hardwarefehler voraussetzen.

API-Hinweis für SFOS 23: Die API-Parametertabelle führt HardwareMonitor als optionalen skalaren Parameter (SCALAR, Mandatory: No) mit den Werten Enable und Disable sowie dem dokumentierten API-Default Enable. Dieser Dokumentationswert belegt weder die tatsächliche GUI-Einstellung noch den Laufzeitzustand des Geräts. Die Einstellung auf dem eingesetzten Gerät prüfen; der oben beschriebene Speichergeräte-Geltungsbereich bleibt unverändert.

Das XML-Beispiel der SFOS-23-API enthält weiterhin Number(250-500) und Number(16-24). Diese Platzhalter stimmen nicht mit den Tabellenbereichen 100–500 ms und 3–24 Versuche überein und dürfen nicht als vollständige Limits übernommen werden. Daraus folgt weder eine Ablehnung der unteren Werte durch das Produkt noch ein getestetes API-Verhalten.

Neue virtuelle Auxiliary als HA spare anbinden

Für eine neue virtuelle Auxiliary in Active-Passive kann der Setup Assistant Connect as HA spare verwenden. Dieser Ablauf ist eine Alternative zum oben beschriebenen Auxiliary-zuerst-Aufbau mit zwei bereits vorhandenen Geräten: Die neue Spare-VM wird nicht vorab als Auxiliary konfiguriert. Vor Initiate HA den oben beschriebenen Vorlauf zur Klärung der Managementadressierung abschliessen; bei ungeklärtem Widerspruch stoppen. Die automatische Konfiguration des Administrationsports löst die widersprüchlichen Adressvorgaben nicht auf. Für Active-Active oder zwei bereits eingerichtete Virtual/Software-Firewalls gilt weiterhin QuickHA oder Interactive mode auf beiden Geräten.

1. Auf der bestehenden Primary DMZ-SSH unter Administration > Device access erlauben und unter System services > High availability Primary (active-passive) sowie Interactive mode wählen. In SFOS 23 vor Initiate HA eine Cluster ID und einen Node-Namen eintragen; die SFOS-22-Anleitung bezeichnet die Eingabe der Cluster ID und die Änderung des Node-Namens als optional. Sind mehrere HA-Cluster im selben Layer-2-Netz vorhanden, für jeden Cluster eine andere Cluster ID verwenden, um Konflikte virtueller MAC-Adressen zu verhindern. Dedicated HA Link, dessen eigene IP und Subnetzmaske, die vorgesehene Peer-IP, Peer-Administration und die auf der Primary verwendete HA-Passphrase sicher dokumentieren. Danach Initiate HA wählen; in SFOS 23 dazu zum Seitenanfang zurückscrollen. Die Sophos-Spare-Anleitung dokumentiert an dieser Stelle vor dem Beitritt der neuen VM die Meldung HA could not be enabled und vorübergehend den Status Standalone. Beides allein belegt in dieser Aufbauphase noch keinen fehlgeschlagenen fertigen Cluster.
2. Die neue virtuelle Firewall mit exakt demselben SFOS-Build installieren, Setup Assistant starten und ein neues Adminpasswort setzen.
3. Connect as HA spare wählen und Seriennummer der bestehenden Primary, dieselbe zuvor auf der Primary verwendete und sicher dokumentierte HA-Passphrase sowie dasselbe Dedicated-HA-Link-Interface eintragen. Für die neue Spare eine eigene, freie und von der Primary verschiedene IP-Adresse im Subnetz des bestehenden Primary-Dedicated-HA-Links mit identischer Subnetzmaske verwenden; sie muss der dort vorbereiteten Peer-IP entsprechen. Keine Passphrase von einer vermeintlich bereits konfigurierten Auxiliary voraussetzen.
4. Apply, Continue und Finish wählen. SFOS erzeugt die Auxiliary, deren Seriennummer mit HAAUX beginnt, und konfiguriert Dedicated HA Link sowie Administrationsport automatisch.
5. Nach einigen Minuten WebAdmin der Auxiliary aktualisieren, neu anmelden und anschliessend Rollen, Synchronisierung, Peer Admin, Monitored Ports und Failover auf der Primary prüfen.

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 zeigt der folgende read-only Befehl Rollen, Status und Synchronisierung des Clusters. Er ändert keine Konfiguration:

system ha show details

SFOS-22-Betriebsparameter prüfen

SFOS 22 veröffentlicht zwei weitere HA-Controls. Beide werden zuerst nur gelesen:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

Das erste Control bestimmt den Pfad für Systemtraffic, den die Auxiliary Firewall selbst sendet. Standardmässig läuft dieser vollständig über den Dedicated HA Link. Neben all stehen none und only_dynamic_interface zur Verfügung. Sophos beschreibt jedoch nicht genauer, welche Flows im letzten Modus als dynamisches Interface gelten. Diese Option wird deshalb nur mit einem für den eingesetzten Build bestätigten Anwendungsfall gewählt und nicht als allgemeiner Routingfix verwendet.

Das zweite Control schaltet die Verteilung des dafür geeigneten Traffics zwischen den Firewalls ein oder aus. Es ersetzt weder die Wahl des HA-Modus noch macht es die weiter oben ausgeschlossenen Dienste und Tunnel load-balancing-fähig. Änderungen erfolgen nur in einem Wartungsfenster, jeweils einzeln und mit zuvor gesicherten Show-Ausgaben:

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

Danach werden Rollen, Synchronisierung, Dedicated HA Link, neue Sessions, node-lokale Logs und die von der Auxiliary selbst gestarteten Systemverbindungen geprüft. Für einen Rollback wird der zuvor gelesene Wert zurückgesetzt. Nur für das erste Control dokumentiert Sophos all als Default; für Load Balancing wird kein Default angenommen.

Welches Gerät das lizenzhaltende Initial Primary ist, prüft man unter System services > High availability. Sophos dokumentiert zusätzlich folgende offizielle CLI-Prüfung in der Advanced Shell:

nvram get "#li.master"

YES kennzeichnet das Initial Primary, das die Clusterlizenzen hält; NO kennzeichnet das als Auxiliary konfigurierte Gerät. Der Befehl ist read-only. Für die tägliche Kontrolle bleibt die HA-Ansicht übersichtlicher, die Shell-Ausgabe ist aber ebenfalls offiziell dokumentiert.

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

Überwacht werden sollten HA- und Rollenstatus, Dedicated HA link, Monitored Ports, Lizenzen, Firmware, CPU, RAM, Disk und die zentralen Dienste. Alerts gehören in Sophos Fusion, E-Mail oder das vorhandene Monitoring.

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

Jeder Node schreibt Logs für den Traffic, den er verarbeitet. Bei Active-Active muss man deshalb beide Geräte prüfen. Für eine gemeinsame Auswertung eignen sich Sophos Central Firewall Reporting oder Syslog. Die lokalen Dateien erklärt Sophos Firewall Troubleshooting: Services und Logs.

Die Auxiliary versendet Report-E-Mails nur für Reports, die auf diesem Node tatsächlich Daten enthalten, beispielsweise E-Mail-Aktivität oder Pattern Updates. Datenlose Reports wie Security Dashboard oder Security Audit versendet sie nicht. Eine fehlende E-Mail dieser Reporttypen ist daher allein noch kein Fehlernachweis.

Bei Active-Active hilft die Quell-IP als erster Hinweis auf den erwarteten Log-Node: Gerade Adressen gehören bei geeignetem TCP-Traffic zur Primary, ungerade zur Auxiliary. Das gilt nicht pauschal für die oben ausgeschlossenen Traffic-Arten und ersetzt nicht den Vergleich beider Geräte, besonders nach einem Rollenwechsel.

Für HA-Ereignisse wird auf jedem Node separat Log viewer > System geöffnet. Über Add filter den passenden Filter und Wert für den betroffenen Zeitraum auswählen und mit dem Add filter-Button anwenden. Für die detaillierte Analyse auf beiden Geräten Diagnostics > Tools > Troubleshooting logs > Select files öffnen und csc.log für den zentralen Dienst auswählen, der die übrigen Dienste verwaltet. Zusätzlich die unten unter Wichtige Logs und Diagnoseorte beschriebenen HA-Dateien auswählen und das jeweilige Paket mit Download getrennt sichern. Für die Rekonstruktion des Clusterablaufs die Aufzeichnungen beider Nodes vergleichen und auf zeitliche Lücken oder rotierte Logs achten.

Runbook für den HA-Betrieb

Im Betriebs-Runbook 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.
• Ablauf und Zuständigkeit für Firmware-Update, Backup, Reimage, Hardwaretausch, Logs 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

Regeln, Interfaces und Policies nur auf der Primary ändern. Vor Änderungen an Interfaces, VLANs, LAGs, Zonen, Routing, NAT, VPN, Device Access oder SD-WAN:

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

Manuelle Synchronisierung und erzwungener Rollenwechsel

Die automatische Synchronisierung ist der Normalfall. Sync auxiliary device darf auf Primary oder Auxiliary nur zur Behebung eines bestätigten Synchronisierungsproblems ausgelöst werden. Die Auxiliary startet dabei neu, übernimmt eine vollständige Synchronisierung von Datenbank und zugehörigen Dateien und bleibt Auxiliary. Logs und Reports bleiben node-lokal. Während des Vorgangs verwirft die Firewall alle masqueradierten Verbindungen, weshalb die Aktion in ein Wartungsfenster gehört.

In Active-Passive lässt sich die Auxiliary mit Switch to passive device auf der aktuellen Primary oder Switch to active device auf der aktuellen Auxiliary zur Übernahme zwingen. Dabei startet die aktuelle Primary neu. Das ist ein geplanter Rollenwechsel mit Session-Risiko und kein harmloser Umschalter.

HA gezielt deaktivieren

Die Sophos-HA-FAQs für SFOS 22 und 23 nennen als allgemeine Voraussetzung: HA vor einem Reimage, vor dem Austausch eines Nodes im HA-Paar und vor einer Lizenzübertragung zwischen den Nodes deaktivieren. Die einmalige Passphrase für den SSH-Tunnel wird nach dessen Aufbau gelöscht; für ein neues Gerät muss HA deshalb deaktiviert und neu konfiguriert werden. Diese Vorgabe ersetzt keine fallbezogene Planung: Die folgenden Reimage-Details enthalten eine dokumentarische Abweichung, und die RMA-Abläufe setzen bereits einen gesunden Node im Zustand Standalone HA voraus. Vorher Backup, gesicherten Adminzugang, Wartungsfenster und Neuaufbau planen; für die Active-Passive-Lizenzkorrektur zusätzlich die oben beschriebene Seriennummern- und Rollenbedingung einhalten.

HA möglichst immer unter System services > High availability > Disable HA auf der aktuellen Primary deaktivieren. Der gewählte Node bestimmt das Ergebnis:

Fusion-Zugriff ab SFOS 22 MR1: Die Sophos Known Issues, NC-186855, beschreiben eine Ausnahme zur obigen allgemeinen Wirkung: Wird HA in der über Sophos Fusion/Central per FRP-SSO geöffneten Firewall-Oberfläche deaktiviert, kann die Auxiliary mit aktivierter HA als Standalone zurückbleiben, während HA auf der Primary bereits aus ist. Dadurch besteht ein Split-Brain-Risiko. Nach der Aktion den HA-Zustand auf beiden Geräten separat prüfen. Bleibt er widersprüchlich, den geplanten Neuaufbau anhalten und die Wiederherstellung mit Sophos Support koordinieren, bevor die Geräte wieder als Paar betrieben werden. Ein erfolgreicher Dialog auf der Primary reicht als Kontrolle nicht aus. Stand 24. Oktober 2026 nennt der Eintrag keine behobene Version.

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 unterbrochen werden und einen erneuten Verbindungsaufbau benötigen.

Ein Firmware-Rollback des HA-Paars folgt demselben Ablauf und erfordert kein vorheriges Deaktivieren von HA.

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

Pattern Updates

Pattern Updates werden auf der Primary installiert und automatisch auf die Auxiliary 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

Backups sollten regelmässig und vor jeder grösseren Änderung erstellt werden. Bei aktiviertem LINCE müssen Backup und Zielcluster denselben LINCE-Status haben. Für den Restore gelten drei unterschiedliche Fälle:

Achtung bei einem Backup ohne HA: Die Sophos-Beschreibungen für SFOS 22 und 23 widersprechen sich zum Zustand der Auxiliary nach diesem Restore: Der Fliesstext nennt den Erhalt der bisherigen Konfiguration, die Zusammenfassung einen Factory Reset mit Ausnahme von Peer Admin Port und Dedicated HA Link. Weder der vollständige Erhalt noch der Factory Reset ist damit als gesichertes Verhalten belegt. Nicht auf eine erhaltene Auxiliary-Konfiguration verlassen. Vorher die Konfigurationen extern sichern, Admin-IP-Adressen und Zugangsdaten dokumentieren und Downtime sowie den HA-Neuaufbau einplanen. Bevor man auf den unklaren Auxiliary-Zustand angewiesen ist, den Ablauf für den installierten SFOS-Build mit Sophos Support klären.

War die Primary als Sophos-ZTNA-Gateway registriert, muss sie nach einem Restore auf dem HA-Cluster zusätzlich wieder als Gateway in Sophos ZTNA hinzugefügt werden.

Reimage von HA-Nodes in Active-Passive

Ein Reimage unterbricht den Betrieb und gilt nach Sophos nur für Active-Passive. Vorher auf beiden Nodes system diagnostics show version-info in der Device Console ausführen, Firmware inklusive Build und Initial Primary dokumentieren und ein aktuelles Backup extern sichern.

Geltungsbereich der folgenden Abläufe: FW1 ist zu Beginn sowohl die aktuelle Primary als auch die lizenzhaltende Initial Primary; FW2 ist die aktuelle Auxiliary. Diese Namen bezeichnen dieselben physischen Geräte während des gesamten Ablaufs, auch nach einem Rollenwechsel. Ziel ist wieder FW1 als Primary und FW2 als Auxiliary. Sind aktuelle Primary und Initial Primary verschiedene Geräte, nicht nach diesen Abläufen improvisieren: zuerst Rollen und Lizenzhalter anhand der passenden Sophos-Anleitung oder mit Sophos Support zuordnen.

Dokumentarische Abweichung vor dem Reimage klären: Die HA-FAQs für SFOS 22 und 23 verlangen allgemein eine HA-Deaktivierung vor dem Reimage. Die detaillierten Active-Passive-Anleitungen beschreiben beim Primary-Reimage und beim Reimage beider Nodes dagegen einen Rollenwechsel mit Switch to passive device und anschliessende Neuinstallation, ohne einen separaten Schritt Disable HA zu nennen. Der Rollenwechsel ist nicht mit der HA-Deaktivierung gleichzusetzen; die Auslassung belegt keine allgemein sichere Ausnahme. Die folgenden Detailfolgen bleiben deshalb als dokumentierte, aber in diesem Punkt widersprüchliche Abläufe erhalten. Bevor man sie ausführt, Rollen, Initial Primary, installierten Build, Backup, Downtime und Rückweg verbindlich planen und die passende Reihenfolge mit Sophos Support klären, wenn man auf diese abweichende Detailfolge angewiesen ist. Bei ungeklärter Reihenfolge vor Rollenwechsel oder Neuinstallation stoppen; nicht eigenmächtig einen Deaktivierungsschritt in die Folge einfügen.

Ist FW1 für Central Management registriert, das Gerät vor jedem der drei Abläufe deregistrieren. Danach im selben Sophos-Central-/Fusion-Tenant unter My Products > Firewall Management > Firewalls prüfen, dass der Eintrag von FW1 nicht mehr vorhanden ist. Erst danach mit Backup, HA-Deaktivierung oder Rollenwechsel fortfahren. Diese Kontrolle gilt für registriertes Firewall Management, nicht nur für Synchronized Security.

Nur die Auxiliary FW2 neu installieren

1. Nach der oben beschriebenen Deregistrierung und Kontrolle das Backup von FW1 extern sichern und HA auf FW1 deaktivieren, niemals auf FW2.
2. In der Advanced Shell von FW1 mit service -S | grep msync prüfen, dass msync den Zustand UNTOUCHED oder STOPPED zeigt. Andernfalls nicht fortfahren.
3. FW2 mit exakt derselben Firmware-Version inklusive Build wie FW1 neu installieren. Lokal anmelden und ausschliesslich WAN für Internet konfigurieren, keine LAN- oder DMZ-Interfaces. Danach FW2 claimen, falls noch nicht geclaimt.
4. HA mit FW1 als Primary und FW2 als Auxiliary neu aufbauen.

Nur die Primary FW1 neu installieren

1. Nach Deregistrierung und Kontrolle das Backup von FW1 extern sichern und mit Switch to passive device die FW2 übernehmen lassen. Die Geräteidentitäten bleiben unverändert.
2. FW1 mit exakt derselben Firmware-Version inklusive Build wie FW2 neu installieren. Lokal anmelden, nur WAN für Internet konfigurieren, keine LAN- oder DMZ-Interfaces, und FW1 claimen, falls noch nicht geclaimt.
3. Für den Restore alle Kabel von FW1 ausser dem Admin-PC trennen, Backup einspielen, Kabel wieder verbinden und Traffic von FW2 auf FW1 zurückführen.
4. FW2 danach auf Werkseinstellungen setzen. Lokal anmelden, ausschliesslich WAN für Internet konfigurieren, keine LAN- oder DMZ-Interfaces, und claimen, falls noch nicht geclaimt.
5. HA mit FW1 als Primary und FW2 als Auxiliary neu aufbauen.

Beide Nodes neu installieren und upgraden

1. Deregistrierung, Kontrolle, Backup und Rollenwechsel wie beim Primary-Reimage ausführen. FW1 jedoch auf die Zielversion inklusive Zielbuild bringen. Danach lokal anmelden, nur WAN für Internet konfigurieren, keine LAN- oder DMZ-Interfaces, und claimen, falls noch nicht geclaimt.
2. Für den Restore alle Kabel von FW1 ausser dem Admin-PC trennen, Backup dort wiederherstellen, Kabel wieder verbinden und den Traffic von FW2 auf FW1 zurückführen.
3. Anders als beim reinen Primary-Reimage FW2 jetzt nicht nur auf Werkseinstellungen setzen, sondern ebenfalls mit exakt derselben Zielversion inklusive Build wie FW1 neu installieren. Lokal anmelden, ausschliesslich WAN für Internet konfigurieren, keine LAN- oder DMZ-Interfaces, und claimen, falls noch nicht geclaimt.
4. Den Active-Passive-Cluster mit FW1 als Primary und FW2 als Auxiliary neu aufbauen. Die geplante Unterbrechung umfasst auch diesen zweiten Neuinstallations- und Beitrittsschritt.

Verwendet der Cluster Sophos Fusion Synchronized Security, muss das HA-Paar vor der Rücksendung im RMA-Prozess aus der Central-Verwaltung entfernt werden. Nach dem Austausch wird der neue HA-Cluster erneut in Central registriert. Das verhindert Konflikte bei Seriennummern- und Lizenzsynchronisierung mit dem noch registrierten Altgerät.

Austausch der Auxiliary nach RMA

Beim Austausch oder Reimage eines Nodes entsteht eine geplante Unterbrechung. Die folgenden Abläufe gelten für Active-Passive; bei Active-Active muss der konkrete Ablauf mit Sophos Support geplant werden. Beide detaillierten RMA-Varianten setzen voraus, dass der gesunde verbleibende Node bereits als Standalone HA arbeitet: beim Auxiliary-RMA die gesunde Primary, beim Primary-RMA die gesunde Auxiliary. Nur für diesen Ausgangszustand beschreiben die Quellen Claim und Lizenztransfer des Ersatzgeräts vor der späteren HA-Deaktivierung beziehungsweise Rücksetzung des gesunden Nodes. Diese Reihenfolge nicht auf den Austausch in einem noch funktionierenden HA-Paar übertragen; dort gilt die allgemeine Disable-before-Vorgabe der FAQs. Stimmt der Ausgangszustand nicht oder ist er unklar, vor Austausch oder Lizenztransfer stoppen und den Ablauf mit Sophos Support planen.

1. Modell und Hardware-Revision des Ersatzgeräts auf Eignung prüfen und exakt denselben Firmware-Build wie auf der gesunden Primary installieren.
2. Am Ersatzgerät zuerst den lokalen Zugang vorbereiten. Das dokumentierte Portbeispiel verbindet einen DHCP-fähigen Admin-PC mit Port 1 und öffnet https://172.16.16.16:4444; WAN wird an Port 2 angeschlossen und im Setup Assistant für Internet konfiguriert. Bei abweichender Portbelegung den Admin- und WAN-Port gemäss Gerätemodell verwenden. Keine weiteren Interfaces konfigurieren. Erst danach das Ersatzgerät in Sophos Fusion claimen und die Lizenz des defekten Auxiliary-Geräts übertragen.
3. Kabel vom defekten Gerät auf das Ersatzgerät umstecken.
4. Auf der gesunden Primary HA unter System services > High availability deaktivieren.
5. In der Advanced Shell prüfen, ob msync beendet ist:

service -S | grep msync

Erwartet wird UNTOUCHED oder STOPPED. Der Befehl ändert nichts; ein anderer Status bedeutet, dass man HA noch nicht neu aufbauen sollte. Danach die gesunde Primary als Primary und das Ersatzgerät als Auxiliary neu konfigurieren.

Austausch der Primary nach RMA

1. Auf der gesunden Auxiliary ein aktuelles Backup herunterladen und das Gerät aus Sophos Fusion deregistrieren. Im selben Sophos-Central-/Fusion-Tenant unter My Products > Firewall Management > Firewalls prüfen, dass der Eintrag dieser gesunden Auxiliary nicht mehr vorhanden ist, bevor man fortfährt.
2. Ersatzgerät auf denselben Firmware-Build bringen und lokal anmelden. Im dokumentierten Portbeispiel einen DHCP-fähigen Admin-PC an Port 1 anschliessen und https://172.16.16.16:4444 öffnen; WAN an Port 2 im Setup Assistant für Internet konfigurieren. Bei abweichender Portbelegung den Admin- und WAN-Port gemäss Gerätemodell verwenden. Keine weiteren Interfaces konfigurieren. Erst danach in Sophos Fusion claimen und die Lizenz der defekten Primary übertragen.
3. Backup auf dem Ersatzgerät wiederherstellen.
4. Kabel der gesunden Auxiliary auf das Ersatzgerät umstecken. Ab diesem Moment verarbeitet das Ersatzgerät den Traffic als eigenständige Firewall.
5. Die bisherige Auxiliary auf Werkseinstellungen zurücksetzen und den lokalen Zugang erneut vorbereiten: Im dokumentierten Portbeispiel einen DHCP-fähigen Admin-PC mit Port 1 verbinden und https://172.16.16.16:4444 öffnen, dann WAN an Port 2 im Setup Assistant für Internet konfigurieren. Bei abweichender Portbelegung den Admin- und WAN-Port gemäss Gerätemodell verwenden. Keine weiteren Interfaces konfigurieren. Erst danach neu in Sophos Fusion claimen und die vorgesehenen Kabel anschliessen.
6. HA mit dem Ersatzgerät als Primary und dem zurückgesetzten Gerät als Auxiliary neu aufbauen.

Achtung: Backup/Restore, Factory Reset und Kabelwechsel verursachen Downtime. Seriennummern, Initial Primary, Firmware-Build, Lizenztransfer, Central-Status und Rückweg müssen vor Beginn dokumentiert sein.

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 komplexen Fehlerbildern sollte man strukturiert vorgehen: 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 > Troubleshooting logs > Select files oder per SSH unter /log.
• HA-Details CLI: Siehe die einmalig beschriebene CLI-Prüfung unter Cluster validieren.
• Interface-Probleme: show network interfaces, ifconfig, dmesg in passenden Diagnosefällen.
• Lizenzhalter: System services > High availability.

Für die erste Eingrenzung sind diese Dateien besonders hilfreich:

• ha.log: Aufbaufehler, erfolgreicher HA-Aufbau und Statuswechsel.
• ha_pair.log: Peer-Erkennung in QuickHA.
• ha_tunnel.log: SSH-Tunnel über den Dedicated HA link.
• msync.log: Synchronisierung der HA-Konfiguration.
• ctsyncd.log: Synchronisierung von Conntrack-Sessions.
• filesync.log: dienstbezogene Dateisynchronisierung, etwa für dynamische Routen oder DHCP.

Jeder Node speichert nur die Logs und Reports des Traffics, den er selbst verarbeitet. Für die Auxiliary meldet man sich über deren Peer-Admin-Adresse an oder ruft die Logdateien per SSH auf diesem Node ab.

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 Appliance-Modelle verwenden.

• HA could not be enabled: Nur beim oben beschriebenen Aufbau mit einer neuen virtuellen HA spare dokumentiert Sophos diese Meldung unmittelbar nach Initiate HA auf der Primary, bevor die Spare beitritt; vorübergehendes Standalone ist dort ebenfalls beschrieben. Das ist kein allgemeiner Freibrief für diese Meldung. Bleibt sie nach Abschluss des Spare-Assistenten und der Warte-/Aktualisierungsphase bestehen oder tritt sie bei einem anderen Aufbau auf, ist der Dedicated HA link möglicherweise nicht verbunden oder der Peer nicht erreichbar. Sicherstellen, dass die dedizierten HA-Link-Interfaces beider Geräte direkt per Ethernet-Kabel oder über den vorgesehenen Switch verbunden sind. Auf beiden Nodes unter Network > Interfaces prüfen, dass das ausgewählte HA-Link-Interface Connected anzeigt. Auf der Primary unter Diagnostics > Tools mit dem Ping-Tool die dedizierte HA-Link-IP der Auxiliary prüfen, nicht deren Peer-Admin-Adresse. Antworten belegen die grundlegende Erreichbarkeit, noch keine abgeschlossene HA-Synchronisierung. Bei fehlenden Antworten zuerst Kabel, Switchpfad, Linkstatus und HA-Link-IP/Subnetz prüfen und korrigieren; danach den Ping wiederholen sowie Rollen und Synchronisierung erneut kontrollieren.

• 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: In /log/syslog.log auf der Primary nach dieser exakten Meldung suchen. Sophos ordnet sie Administrationsports zu, die nicht im selben Subnetz liegen; die Admin-Port-Adressen beider Geräte vergleichen. Die HA-Link-Adressen zusätzlich als separate Voraussetzung auf dasselbe Subnetz prüfen, nicht als belegte Ursache dieser Meldung behandeln. Vor einer Korrektur der Managementadressierung den oben beschriebenen Vorlauf zur Klärung des Quellenwiderspruchs einhalten: Rollen, installierten SFOS-Build, Admininterface und aktuelle IPs dokumentieren, Backup und separaten Konsolen-/lokalen Adminzugang sichern und das geltende Adressverhalten verifizieren oder mit Sophos Support klären. Bei ungeklärtem Verhalten vor Adressänderungen stoppen.

• 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. Hat der betroffene Node tatsächlich neu gebootet und nicht nur die Rolle gewechselt, wird der unerwartete Neustart node-spezifisch geprüft.

• 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 nach einem Update nicht: Bei den 1U-Modellen XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 und XGS 4500 kann HA ausbleiben, wenn ein Flexi Port als Dedicated HA link verwendet wird. Nach Update und Neustart des ersten Geräts steht dessen Interface speed nicht mehr auf Auto negotiation, während das zweite Gerät weiterhin Auto negotiation verwendet.

  Vor der Änderung: HA-Rollen und Portwerte beider Geräte dokumentieren, Backup und separaten Adminzugang sichern und ein Wartungsfenster nutzen. Bei Split-Brain zuerst nach dem folgenden Ablauf für HA-Link-Ausfall festlegen, welcher Node aktiv bleiben soll, und den anderen vom Produktionsnetz trennen oder kontrolliert herunterfahren. Nicht beide Nodes unkoordiniert neu starten.

  1. Auf beiden Geräten Network > Interfaces öffnen.
  2. Das betroffene Flexi-Port-Interface wählen und Advanced settings öffnen.
  3. Interface speed auf Auto negotiation setzen.

  Danach Linkstatus, HA-Rollen, Synchronisierung und produktiven Traffic prüfen. Bleibt der Fehler bestehen, Werte und Logs beider Nodes sichern und Sophos Support einbeziehen. Ein Rücksetzen auf die dokumentierten vorherigen Werte erfolgt nur kontrolliert mit gesichertem Adminzugang; es kann den HA-Link-Fehler wieder auslösen. Alternativ lässt sich ein fest eingebauter Port als Dedicated HA link planen – kein fest vorgegebener Geschwindigkeitswert. Die Änderung ist dokumentarisch geprüft, nicht auf einem Gerät getestet.

WebAdmin und VPN Portal bei Zertifikatssynchronisierung unerreichbar

Die Release Notes zu SFOS 22.0 MR3 Build 576 vom 16. Oktober 2026 nennen NC-186809 als behoben: Auf der Auxiliary konnte die Zertifikatssynchronisierung scheitern, wenn bestimmte Zertifikatsdateinamen mit zwei aufeinanderfolgenden Punkten (..) begannen; WebAdmin und VPN Portal waren dadurch nicht erreichbar. Das Fehlerbild von allgemeinen Routing- oder Device-Access-Problemen unterscheiden und Build, betroffenen Node, Zeitpunkt sowie vorhandene Synchronisierungslogs sichern. Zertifikate nicht auf Verdacht umbenennen oder löschen. Bei passendem Verdacht den Support einbeziehen und einen unterstützten Firmwarewechsel mit gesichertem Managementzugang planen; danach beide Portale und die HA-Synchronisierung erneut prüfen.

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.

Weitere CLI-Befehle

Zusätzlich zur HA-Statusabfrage unter Cluster validieren zeigt der folgende read-only Befehl in der Device Console

show network interfaces

Interface- und Linkstatus. Erwartet werden UP-Zustände für Dedicated HA link und angeschlossene Monitored Ports.

In derselben Ausgabe von show network interfaces die betroffene physische Schnittstelle anhand ihres tatsächlichen Interface-Namens suchen und neben dem Linkstatus die verfügbaren Zähler für Paketverluste (Drops), Fehler und Kollisionen prüfen. Nicht jeder Build zeigt jeden Zähler; fehlende Angaben sind kein Nullwert. Ausgabe mit Node, Interface und Zeitstempel sichern und mit einer späteren Beobachtung vergleichen: Steigende Zähler helfen, Interface-, Kabel- oder Aushandlungsprobleme einzugrenzen, beweisen aber allein keine konkrete Ursache. Kabeltausch oder Speed-/Duplex-Korrektur nur kontrolliert mit gesichertem Adminzugang und den oben beschriebenen HA-/Split-Brain-Vorkehrungen durchführen; danach Zähler, Linkstatus, Rollen und Synchronisierung erneut vergleichen. Diese Interface-Zähler sind von Paket-Drops durch Firewall-Regeln und deren Drop Capture zu unterscheiden.

Für Link-Flaps wechselt man über Device Management > Advanced Shell in die Shell und ersetzt PortE durch den tatsächlichen Interface-Namen:

dmesg | grep PortE

Die Ausgabe filtert Kernelmeldungen für dieses Interface. Wiederholte Link-up/Link-down-Meldungen sprechen für Kabel-, Transceiver-, Port- oder Aushandlungsprobleme. Der Befehl ändert nichts; dmesg enthält jedoch nur den aktuellen Kernelpuffer und ersetzt keine langfristige Logauswertung.

Die vollständige physische Eingrenzung mit ethtool, Moduldaten und bekannten Spezialfällen erklärt SFP und SFP+ für Sophos Firewall auswählen und prüfen.

Vor jedem tieferen Eingriff zuerst Ausgaben und Zeitstempel sichern. Die Befehle wurden gegen die aktuelle Sophos-Dokumentation geprüft, aber nicht auf der individuellen Kundenhardware ausgeführt.

Go-live-Checkliste

• Active-Passive oder Active-Active begründet gewählt.
• Modelle, Flexi Ports, SFOS-Build, LINCE-Status, Claiming und Lizenzen geprüft.
• Backup und Rückweg vorhanden.
• Dedicated HA link frei, stabil und möglichst direkt verbunden.
• VLANs, LAGs, Switchports und RSTP auf beiden Seiten konsistent.
• Peer-Admin-Zugriff auf die Auxiliary getestet.
• Nur stabile, kritische Interfaces als Monitored Ports gewählt.
• Cluster ID, Initial Primary, Preferred primary und Seriennummern dokumentiert.
• WebAdmin, CLI-Status und relevante Logs geprüft.
• LAN, Internet, Server, VPN, DNAT/WAF, DNS und DHCP funktional getestet.
• Failover und Rückwechsel im Wartungsfenster getestet.
• Monitoring, Firmware-, Restore- und RMA-Ablauf im Runbook festgehalten.

FAQ