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

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

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

Als schnelle Orientierung 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 unter anderem die Quell-IP-Adresse: TCP-Verbindungen von geraden Quell-IP-Adressen verarbeitet typischerweise die Primary, ungerade können an die Auxiliary gehen. Verteilt werden weitergeleitete oder übersetzte TCP-Verbindungen. 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.
• Preferred primary: Bevorzugtes Gerät, das nach einem Failover wieder Primary werden soll, sobald es stabil verfügbar ist.

Statuswerte im Betrieb

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

Virtuelle MAC-Adresse

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

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

Was synchronisiert wird

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

Failover-Verhalten

Ein Failover kann durch verschiedene Ereignisse ausgelöst werden:

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

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

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

Unterstützte und eingeschränkte Dienste

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

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

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

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

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.

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

Cloud-Deployments

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

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

Lizenzierung und Registrierung

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

Die wichtigsten Lizenzpunkte:

• Base Firewall: Für HA ist eine Base Firewall Lizenz erforderlich. Hardware-Appliances haben diese Lizenz standardmässig. Bei Virtual/Software-Appliances muss sie passend lizenziert sein.
• Active-Passive Hardware: Nur das Initial-Primary-Gerät benötigt die produktiven Subscriptions. Die Auxiliary Firewall erhält eine Kopie der Subscriptions und kann nach einem Failover Traffic verarbeiten.
• Active-Active Hardware: Beide Firewalls benötigen eigene passende Lizenzen. Die Lizenztypen müssen übereinstimmen, Ablaufdaten dürfen unterschiedlich sein.
• Active-Passive Virtual/Software: Nur die Primary benötigt die nötigen Lizenzen inklusive Base Firewall.
• Active-Active Virtual/Software: Beide Geräte benötigen eine eigene Base Firewall Lizenz und passende weitere Schutzlizenzen.
• Registrierung Hardware: Beide Hardware-Geräte müssen vor der HA-Einrichtung in 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 Hardwaretausch und Advance Replacement ist der Supportstatus wichtig. Bei Active-Passive Hardware nennt Sophos Enhanced Plus Support auf dem Primary-Gerät als relevante Voraussetzung für Advance Hardware Replacement. Bei Active-Active muss der Supportstatus auf beiden Geräten passen.

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

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

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

Der Peer Admin Port ist ein eigener Betriebszugang zur Auxiliary Firewall. Die Administrationsports beider Geräte müssen im gleichen Subnetz liegen, aber unterschiedliche IP-Adressen verwenden. 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 die Peer-Admin-Adresse aus einem passenden Netz.

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.

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

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.

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 Central Registrierung, falls verwendet

4. Monitored Ports setzen

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

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

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

Active-Active mit QuickHA

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.

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. Standardmässig sendet die Firewall alle 250 Millisekunden einen Heartbeat und bewertet den Peer nach 16 fehlenden Heartbeats als nicht erreichbar.

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

Welches Gerät das lizenzhaltende Initial Primary ist, prüft man primär unter System services > High availability. In einem dokumentierten Supportfall kann zusätzlich in der Advanced Shell folgender interner read-only Wert helfen:

nvram get "#li.master"

YES steht üblicherweise für das Initial Primary, NO für die Auxiliary. Sophos dokumentiert diesen internen Advanced-Shell-Befehl nicht als reguläre Admin-Schnittstelle; die HA-Ansicht bleibt deshalb die Referenz.

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

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.

Firmware-Updates und Backups

Firmware-Updates in HA-Umgebungen

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

Typischer Ablauf:

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

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

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

Pattern Updates

Pattern Updates werden auf der Primary 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

Backup und Restore haben in HA-Umgebungen Besonderheiten:

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

Verwendet der Cluster Sophos Central 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 Central 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 Central deregistrieren.
2. Ersatzgerät auf denselben Firmware-Build bringen, in Sophos Central 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 Central 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-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

Offizielle Quellen: Registrierung und Lizenzen · LINCE in HA-Umgebungen · RMA im Active-Passive-Cluster · HA-FAQ