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 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 die Quell-IP-Adresse: TCP-Verbindungen von geraden Quell-IP-Adressen verarbeitet typischerweise die Primary, ungerade gehen an die Auxiliary. Verteilt werden weitergeleitete oder übersetzte TCP-Verbindungen, 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. Nicht-TCP-, SD-RED- und getunnelter Traffic sowie Layer-7-Verbindungen über DPI oder Proxy, darunter SMTP Proxy, HTTPS, gescanntes FTP und H.323, werden nicht verteilt. Externe Load Balancer vor dem Cluster unterstützt Sophos für diese HA-Logik nicht.

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

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

Startet ein einzelner Node im Failsafe-Modus, wird zuerst dessen Rolle und der Zustand des Peers dokumentiert. Der Ablauf Sophos Firewall im Failsafe-Modus prüfen zeigt den lesenden Diagnosebefehl 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. Standardmässig sendet Sophos Firewall alle 250 Millisekunden einen Heartbeat. Erst wenn 16 Heartbeats in Folge fehlen, gilt der Peer als nicht erreichbar. Bei Monitored Ports reicht dagegen bereits ein ausgefallener Port, damit das Gerät als nicht verfügbar gilt und ein Failover ausgelöst wird.

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, auch wenn der Cluster während des Vorgangs grundsätzlich verfügbar bleibt.

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.

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 dasselbe 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-Appliance oder eine passende virtuelle Plattform ersetzt werden.

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.

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 Use host or hypervisor-assigned MAC address in HA wählen; dann sind diese Plattformänderungen nicht erforderlich.

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 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 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: Wurden die Subscriptions irrtümlich der Auxiliary statt der Initial Primary zugewiesen, reicht eine Synchronisierung nicht aus. Auf der aktuellen Primary HA geplant deaktivieren, die Subscriptions in Sophos Fusion von der Auxiliary auf die Primary übertragen und den HA-Cluster danach neu konfigurieren. Derselbe Lizenztransfer ist bei einem RMA oder beim Ersatz älterer Modelle relevant; wegen der Modellgleichheit müssen bei einem Modellwechsel beide HA-Geräte ersetzt werden.

Wenn sich die Lizenzen in Active-Active unterscheiden, stoppt das Load Balancing für bis zu drei Tage. Besteht die Abweichung danach weiter, deaktiviert die Firewall HA. Bei der Erstkonfiguration wird Active-Active mit nicht passenden Lizenzen nicht aktiviert.

Das Initial Primary muss die Lizenzen 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.

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.
• Interface-Adressen: Active-Active verlangt statische IP-Adressen auf allen Interfaces. Active-Passive erlaubt DHCP oder PPPoE, für diese Verbindungen gibt es aber 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.

Breakout-Interfaces werden auf der Primary konfiguriert. Danach zuerst die Primary neu starten, damit die Änderung angewendet wird, und anschliessend die Auxiliary neu starten. Existiert auf der Primary keine entsprechende Breakout-Konfiguration, löscht die Synchronisierung eine nur auf der Auxiliary vorhandene Breakout-Konfiguration.

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 zur Auxiliary Firewall. Für beide Nodes wird dasselbe Managementnetz verwendet. SFOS synchronisiert jedoch die normale Interface-Konfiguration einschliesslich der PortMGMT-IP von der Primary auf die Auxiliary; diese Interface-IP kann deshalb nicht pro Node unterschiedlich gesetzt werden. Der separate Peer-Administration-Wert weist der Auxiliary eine zusätzliche, abweichende Admin-IP im selben Subnetz zu. QuickHA übernimmt dafür automatisch das Interface, über das die aktuelle WebAdmin-Sitzung läuft. Nach dem HA-Aufbau erreicht man die Auxiliary nur über diese Peer-Admin-Adresse aus dem passenden Subnetz.

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.

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. Danach Show recommended settings > Load recommended configuration für Negotiation und Forward Error Correction (FEC) verwenden. Bleiben die Empfehlungen leer, Auto-Negotiation für Media Type und FEC deaktivieren. 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 im selben 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:

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

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. Bei einem Geräteaustausch muss HA deshalb deaktiviert und neu konfiguriert werden.

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.

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. Optional einen Node-Namen vergeben, zum Beispiel FW01.
6. Eine HA-Passphrase mit 10 bis 20 Zeichen sowie Gross- und Kleinbuchstabe, Zahl und 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. 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 Fusion 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.

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.

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?
• 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.
5. Kritische Monitored ports auswählen.
6. Unter Peer administration settings das Managementinterface und eine eigene IP-Adresse für FW02 angeben.
7. Bei virtuellen Appliances bei Bedarf die vom Host oder Hypervisor zugewiesene MAC-Adresse wählen. Eine spätere Änderung verursacht Downtime.
8. Preferred primary festlegen und Initiate HA wählen.

Nach dem Aufbau die Keepalive-Werte nur ändern, wenn ein dokumentierter Grund vorliegt. Zulässig sind 250 bis 500 Millisekunden für das Intervall und 16 bis 24 Versuche. Der Default von 250 Millisekunden und 16 Versuchen ergibt einen Timeout von vier Sekunden. 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.

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. 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 Active-Passive im Interactive mode vorbereiten. Dedicated HA Link, Peer-IP, Peer-Administration und die HA-Passphrase dokumentieren; die Primary kann bis zum Beitritt der neuen Auxiliary Standalone anzeigen.
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 HA-Passphrase, dasselbe Dedicated-HA-Link-Interface sowie eine freie IP-Adresse mit gleicher Subnetzmaske eintragen.
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.

Für HA-Ereignisse wird auf jedem Node separat Log viewer > System geöffnet und nach dem betroffenen Zeitraum gefiltert. Für die detaillierte Analyse auf beiden Geräten Diagnostics > Tools > Troubleshooting logs > Select files öffnen, mindestens csc.log auswählen und das jeweilige Paket mit Download getrennt sichern. Erst der Vergleich beider Nodes zeigt den vollständigen Clusterablauf.

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

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

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.

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:

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.

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.

1. Modell und Hardware-Revision des Ersatzgeräts auf Eignung prüfen und exakt denselben Firmware-Build wie auf der gesunden Primary installieren.
2. 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.
2. Ersatzgerät auf denselben Firmware-Build bringen, 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, 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 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: Monitor & Analyze > Logs > Troubleshooting logs 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: 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. 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 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.

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.

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