Sophos Firewall: Hardware, virtuell oder Cloud?

Sophos Firewall kann als XGS Appliance, virtuelle Appliance, Software Appliance oder Cloud Deployment betrieben werden. Technisch läuft überall Sophos Firewall OS, aber das Betriebsmodell ist nicht gleich. Die Entscheidung betrifft Performance, Support, Portdesign, HA, Recovery, Lizenzierung, Monitoring und die Frage, wer im Störungsfall welche Plattform verantwortet.

Für neue Projekte sollte man deshalb nicht nur fragen, welche Variante günstiger wirkt. Entscheidend ist, welche Variante zum Standort, zur Virtualisierungsplattform, zur Cloud-Architektur und zum Betriebsteam passt. Für die Leistungsdimensionierung ist zusätzlich der Sophos Firewall Sizing Guide wichtig.

Die Plattformwahl entscheidet auch über Compliance-Funktionen: Der FIPS-140-3-Modus wird auf XGS Appliances, unterstützten virtuellen Plattformen, AWS und Azure angeboten, nicht aber auf Software Appliances sowie XG- oder SG-Hardware.

Betriebsmodell auswählen

Kurzentscheidung

• XGS Appliance: Passt meistens, wenn ein Standort eine dedizierte, klar supportbare Firewall mit physischen Ports braucht.
• Virtuelle Appliance: Passt meistens, wenn eine stabile Virtualisierungsplattform vorhanden ist und Netzwerkzonen sauber virtuell getrennt werden können.
• Software Appliance: Passt meistens, wenn eigene Hardware bewusst als Firewall-Plattform betrieben und unterstützt werden soll.
• Cloud Deployment: Passt meistens, wenn Workloads in AWS oder Azure geschützt oder mit lokalen Netzen verbunden werden sollen.

Die wichtigste Regel: Eine virtuelle oder Cloud-Firewall ist kein Freipass für weniger Planung. CPU, RAM, Storage, virtuelle Switches, Routing, HA, Backup und Monitoring müssen genauso sauber geplant werden wie bei Hardware.

Wann man vorsichtig sein sollte

Die Entscheidung sollte nicht nur danach fallen, was technisch möglich ist. Manche Umgebungen sehen auf dem Papier flexibel aus, erzeugen aber im Betrieb unnötige Risiken.

• Hypervisor ist bereits stark ausgelastet: IPS, TLS Inspection, VPN und Logging brauchen planbare CPU- und I/O-Reserve.
• WAN, LAN, DMZ und Management laufen über denselben physischen Engpass: Eine logisch saubere Trennung hilft wenig, wenn der reale Datenpfad überlastet oder falsch segmentiert ist.
• Kein Team fühlt sich für Hypervisor und Firewall gemeinsam verantwortlich: Störungen bleiben zwischen Plattform-, Netzwerk- und Firewall-Team hängen.
• HA wurde nur als Checkbox geplant: Ohne Host-, Storage-, Netzwerk- und Restore-Test ist Hochverfügbarkeit nicht bewiesen.
• Cloud-Routing ist nicht vollständig dokumentiert: Die Firewall schützt nur Traffic, der wirklich durch sie geroutet wird.
• Restore wurde nie geübt: Ein Backup ist erst dann belastbar, wenn eine Wiederherstellung realistisch getestet oder mindestens sauber geplant wurde.

In solchen Fällen ist eine XGS Appliance oft nicht weniger modern, sondern schlicht die robustere Betriebsentscheidung. Umgekehrt kann eine virtuelle oder Cloud-Firewall sehr sinnvoll sein, wenn Plattform, Netzwerkdesign, Monitoring und Verantwortlichkeiten sauber geklärt sind.

Plattformen im Vergleich

XGS Appliance

Eine XGS Appliance ist für klassische Standorte meistens die planbarste Variante. Hardware, Ports, Support, RMA, Lifecycle und Firewall OS kommen als abgestimmtes System.

Vorteile:

• dedizierte Firewall-Hardware,
• feste Portausstattung und Erweiterungsmöglichkeiten,
• klare Zuordnung von WAN, LAN, DMZ, HA-Link und Management,
• einfacher Hardware-Support und Austauschprozess,
• keine Abhängigkeit von Hypervisor-Ressourcen,
• gut geeignet für Filialen, Hauptstandorte und Edge-Firewalls.

Der grösste Vorteil liegt im Betrieb: Wenn es ein Problem gibt, muss man nicht zuerst klären, ob Hypervisor, vSwitch, Storage, Cloud-Routing oder Firewall selbst die Ursache ist. Für viele KMU-Standorte ist das wichtiger als maximale Flexibilität.

Virtuelle Appliance

Eine virtuelle Sophos Firewall ist sinnvoll, wenn bereits eine saubere Virtualisierungsplattform vorhanden ist und die Firewall in ein Rechenzentrum, eine mandantenfähige Umgebung oder ein internes Segmentierungsdesign eingebunden werden soll.

Zu den relevanten virtuellen Plattformen gehören VMware, Microsoft Hyper-V, KVM, Nutanix Prism und Citrix Hypervisor. Vor dem Deployment sollte die konkrete Plattformversion gegen die aktuelle Sophos-Kompatibilität geprüft werden. Als technische Untergrenze nennt Sophos eine vCPU, 4 GB RAM, zwei vNICs, 32 GB Primärdisk und 80 GB Report-Disk. Das sind Startwerte für die Installation, keine Sizing-Empfehlung für produktiven Inspection-Traffic.

Die Plattformprüfung darf nicht bei der Produktfamilie enden. Für Nutanix nennt Sophos beispielsweise AOS 6.5.x oder eine neuere LTS-Version, die dazugehörige AHV-Version, ein dazu kompatibles Prism Central und einen dort registrierten AHV-Cluster. KVM setzt einen x86-Host mit aktuellem Linux-Kernel und aktivierter Intel-VT- oder AMD-V-Unterstützung voraus. Wenn vCPU und RAM für mehr Last erhöht werden, sollte auch die Report-Disk für das zusätzliche Logvolumen grösser geplant werden.

Wichtige Betriebsfragen:

• Sind CPU-Ressourcen garantiert oder stark überbucht?
• Sind RAM und Storage ausreichend dimensioniert?
• Sind virtuelle NICs und Portgruppen klar getrennt?
• Gibt es dedizierte Netzpfade für WAN, LAN, DMZ, HA und Management?
• Wird Promiscuous Mode, VLAN-Trunking oder SR-IOV benötigt?
• Gibt es ein sauberes Backup- und Restore-Konzept?
• Ist klar, wer Hypervisor, Storage und Firewall gemeinsam troubleshootet?

Eine virtuelle Firewall kann sehr gut funktionieren. Problematisch wird es aber schnell, wenn sie auf einem überlasteten Host läuft oder wenn WAN, LAN und Management nur logisch sauber aussehen, aber physisch über dieselben Engpässe laufen.

⚠️ Hypervisor-Snapshots oder Backups des Virtualisierungsherstellers sind kein unterstützter Ersatz für das integrierte Sophos-Backup. Für einen supportbaren Restore muss die Konfiguration unter Backup & Firmware > Backup & Restore gesichert werden. Plattform-Backups können zusätzlich existieren, dürfen aber nicht der einzige Recovery-Pfad sein.

Software Appliance

Eine Software Appliance wird auf eigener x86-64-Hardware installiert. Das kann für Labore, Spezialumgebungen oder sehr gezielte Designs sinnvoll sein. Im normalen Kundenbetrieb sollte man diese Variante aber bewusst wählen, weil Hardwareauswahl, Treiber, Ersatzteile, Monitoring und Support stärker beim Betreiber liegen.

Die Installation formatiert und partitioniert den Datenträger neu und löscht dabei das vorhandene Betriebssystem sowie alle Dateien. SFOS 22 setzt für die Software Appliance unter anderem Legacy BIOS, mindestens 4 GB RAM, zwei Netzwerkkarten sowie mindestens 32 GB Storage voraus; 64 GB werden empfohlen. Werden die Mindestanforderungen nicht erfüllt, kann die Firewall in den Fail-safe-Modus wechseln.

Wenn eine Appliance bereits im Failsafe-Modus startet, sollte man vor Ressourcenänderungen die von SFOS erkannte Ursache mit dem Runbook Sophos Firewall im Failsafe-Modus prüfen sichern.

Prüfen:

• Ist die Hardware für den Dauerbetrieb geeignet?
• Sind Netzwerkkarten, Storage und BIOS/UEFI-Konfiguration passend?
• Gibt es Ersatzhardware?
• Ist der Installations- und Recovery-Prozess dokumentiert?
• Wer verantwortet Hardwarefehler?

Für Standardstandorte ist eine XGS Appliance oft einfacher. Für technische Sonderfälle kann eine Software Appliance trotzdem passen, wenn das Betriebsteam die Plattform sauber beherrscht.

Cloud Deployment

Cloud Deployments sind vor allem dann sinnvoll, wenn Workloads in AWS oder Azure geschützt werden sollen oder wenn Cloud-Netze mit lokalen Standorten verbunden werden. In der Cloud sind andere Fragen wichtig als am klassischen Standort.

Einplanen:

• VPC/VNet-Design,
• Routing-Tabellen,
• Availability Zones,
• Elastic IPs oder Public IPs,
• Site-to-Site VPN oder SD-WAN,
• Logging und zentrale Auswertung,
• Cloud-Kosten für Instanz, Storage, Traffic und HA-Design,
• Betriebsverantwortung zwischen Cloud-Team und Firewall-Team.

Eine Cloud-Firewall ersetzt kein sauberes Cloud-Netzdesign. Geschützt werden nur die Pfade, die tatsächlich durch die Firewall geroutet werden. Die konkreten Bereitstellungs- und Routingentscheidungen erklären die Anleitungen für Sophos Firewall auf AWS und Sophos Firewall auf Azure.

Virtuelle und Software Appliance installieren

Das Image wird direkt auf der Sophos-Seite Firewall Installers heruntergeladen. Unter Virtual Installers wählt man für Citrix und VMware das jeweilige OVF-Paket, für Hyper-V das VHD- und für KVM, Proxmox sowie Nutanix das QCOW2-Paket. Für eigene Hardware wird stattdessen die ISO unter Software Installers benötigt.

Vor dem Import prüft man, dass die oben verlinkte Downloadseite über HTTPS geladen, das Paket nicht von einem Drittanbieter-Mirror bezogen und das Archiv ohne Fehler vollständig entpackt wurde. Bei einem OVF-Paket bleiben Manifest, OVF und beide VMDK-Dateien zusammen; meldet der Import eine Manifest- oder Prüfsummenabweichung, wird nicht weiterinstalliert, sondern das Paket erneut direkt bei Sophos heruntergeladen. Für eine interne Übertragung kann man zusätzlich unmittelbar nach dem Download einen SHA-256-Wert erfassen und ihn am Zielsystem erneut vergleichen. Dieser Vergleich erkennt Übertragungsfehler, ersetzt aber keine Herstellersignatur.

Vor dem Import gelten zudem die Mindestwerte 1 vCPU, 4 GB RAM, zwei vNICs, 32 GB Primary Disk und 80 GB Report Disk. Zu wenig Ressourcen führen in den Fail-safe Mode. Hypervisor-Snapshots und Backupfunktionen des Virtualisierungsherstellers sind kein unterstütztes Firewall-Backup; dafür wird die SFOS-Backupfunktion verwendet.

Vor dem ersten Start werden PortA und PortB gegen Management-, LAN- und WAN-Netze geprüft. Eine vertauschte Zuordnung kann WebAdmin direkt ins Internet stellen. Der Erstzugriff erfolgt aus einem isolierten Adminnetz auf https://172.16.16.16:4444; der Adminclient erhält beispielsweise 172.16.16.2/24. Das Standardpasswort wird nicht vor dem Setup-Assistenten in der CLI geändert, weil der Assistent danach nicht mehr startet. Nach dem Wizard werden Lizenz, beide Disks, Interfaces, Reporting, Backup und ein negativer Zugriff aus einem nicht erlaubten Netz geprüft.

Installation prüfen und sicher zurückgehen

Ist https://172.16.16.16:4444 nicht erreichbar, wird nicht sofort neu installiert. Zuerst prüft man, ob der Adminclient direkt im Netz von PortA liegt, die zugehörige vNIC verbunden ist und die Portgruppe beziehungsweise Bridge wirklich dem isolierten Adminnetz zugeordnet wurde. Danach kontrolliert man an der VM-Konsole, ob die Firewall vollständig gestartet ist, und schliesst einen Adresskonflikt mit 172.16.16.16 aus. PortA darf für diesen Test nicht versehentlich mit dem öffentlichen WAN verbunden sein.

Fehlen nach dem Setup Reports oder startet die Appliance im Fail-safe Mode, vergleicht man Zuweisung, Bus und Mindestgrösse der Auxiliary-/Report-Disk sowie CPU, RAM und beide vNICs mit den plattformspezifischen Sophos-Vorgaben. Die erkannte Fail-safe-Ursache sollte vor einer Änderung mit dem Fail-safe-Runbook gesichert werden.

Solange die Firewall noch nicht produktiv routet, ist der sichere Rückweg einfach: VM ausschalten, geänderte Test-Routen oder den testweisen Default Gateway zurücksetzen und die bisherige Firewall unverändert weiterverwenden. Nach der Inbetriebnahme beruht Recovery dagegen auf einem aktuellen SFOS-Backup und einem dokumentierten Neuaufbau der VM, nicht auf einem Hypervisor-Snapshot.

Installation auf eigener Hardware

Die Software Appliance ersetzt das vorhandene Betriebssystem vollständig. Unterstützt werden x86-64, Legacy BIOS, mindestens 4 GB RAM, zwei NICs und 32 GB HDD/SSD; 64 GB werden empfohlen. Der USB-Stick benötigt mindestens 1 GB. Windows oder macOS dient nur zum Schreiben der ISO auf den Stick. Der Zielserver wird danach von USB gestartet und bei der Bestätigung vollständig formatiert und neu partitioniert. Vorher müssen Daten, Bootmodus, NIC-Erkennung und ein unabhängiger Recovery-Weg feststehen.

Betrieb und Recovery planen

Performance und Sizing

Bei Hardware ergibt sich die Leistung aus dem gewählten Modell. Bei virtuellen, Software- und Cloud-Deployments hängt die Leistung stärker von der Plattform ab.

Besonders relevant:

• CPU-Leistung und CPU-Reservation,
• RAM,
• Storage-Latenz,
• virtuelle NICs,
• Hypervisor- oder Cloud-Netzwerkpfad,
• Anzahl Sessions,
• TLS Inspection,
• IPS,
• VPN-Durchsatz,
• Logging und Reporting.

Datenblattwerte sollten deshalb immer im Kontext gelesen werden. Firewall-Durchsatz ohne Security-Inspection ist nicht dasselbe wie Threat Protection, TLS Inspection oder IPsec VPN unter realer Last. Die Unterschiede erklärt Sophos Firewall Leistungsdaten richtig interpretieren.

HA und Recovery

High Availability unterscheidet sich je nach Plattform deutlich.

Bei Hardware ist HA meist einfacher zu verstehen: zwei Appliances, HA-Link, definierte Interfaces, klares Austauschgerät. Bei virtuellen und Cloud-Deployments kommen zusätzliche Fragen dazu:

• Laufen HA-Nodes auf unterschiedlichen Hosts?
• Sind Storage, Netzwerk und Hypervisor wirklich redundant?
• Sind virtuelle MAC-Adressen und vSwitch-Regeln kompatibel?
• Gibt es Abhängigkeiten zu Cloud-Routing oder Load Balancing?
• Funktionieren Backups und Restore auf neuer Instanz?
• Ist der Ausfall eines Hosts oder einer Availability Zone getestet?

Die Grundlagen zu HA-Varianten stehen in Sophos Firewall High Availability (HA) einrichten. Für Recovery ist Sophos Firewall Backup erstellen oder wiederherstellen Pflichtlektüre.

Lizenzierung und Support

Lizenzierung sollte früh geprüft werden, weil Hardware, virtuelle und softwarebasierte Firewalls unterschiedlich behandelt werden. Virtuelle, Software- und Cloud-BYOL-Lizenzen werden seit März 2025 nach CPU-Cores begrenzt; die frühere RAM-Lizenzgrenze entfällt. Das bedeutet nicht, dass beliebig viel RAM schlechtes CPU-, Storage- oder NIC-Sizing kompensiert. Seriennummer, Core-Lizenz, Support und Subscription müssen weiterhin zur Instanz passen.

Für die Base-License-Grundlagen passt Sophos Firewall - Base License. Die Änderung bei virtuellen und Software-Lizenzen, bei der RAM nicht mehr als Lizenzgrenze im Vordergrund steht, ist im Blogpost Sophos Firewall VM & SW - Nur CPU zählt - Kein RAM Limit mehr eingeordnet.

Wichtig ist im Betrieb:

• Lizenz und Supportstatus dokumentieren.
• Seriennummer und Registrierungsstatus sauber erfassen.
• HA-Lizenzierung vor dem Aufbau prüfen.
• Firmware- und Supportberechtigung vor Upgrades prüfen.
• RMA- oder Recovery-Prozess für die gewählte Plattform kennen.

Vor grösseren Upgrades sollte zusätzlich Sophos Firewall vor SFOS 22 Upgrade prüfen herangezogen werden, weil Plattformunterstützung, Speicherplatz, Backup, HA und alte VPN-Konfigurationen upgrade-relevant sein können.

Bei Active-Passive HA auf virtuellen oder Software-Appliances benötigt nur die Primary alle erforderlichen Lizenzen einschliesslich Base Firewall. Bei Active-Active benötigen beide Nodes eine eigene Base Firewall License und dieselben zusätzlich gebuchten Schutzlizenzen; die Ablaufdaten dürfen abweichen. Diese Lizenzfrage gehört vor den Aufbau des Clusters, nicht in die Fehleranalyse nach dem ersten Failover.

Entscheidungsmatrix

• Klassischer Standort mit WAN, LAN und DMZ: Meist eher Hardware. Virtuell nur bei guter Virtualisierungsstrategie.
• Rechenzentrum mit bestehendem Hypervisor-Team: Hardware ist möglich, virtuell ist oft sinnvoll.
• Cloud-Workloads in AWS oder Azure: Eher virtuell beziehungsweise Cloud, nicht klassische Hardware.
• Einfacher Support und RMA wichtig: Eher Hardware. Bei virtuell oder Cloud hängt viel vom Plattformteam ab.
• Viele physische Ports nötig: Eher Hardware. Virtuell nur mit sauberem NIC- und vSwitch-Design.
• Dynamische Skalierung und Infrastructure as Code: Eher virtuell oder Cloud.
• Kleines IT-Team ohne Hypervisor-Spezialwissen: Meist eher Hardware; virtuelle Firewalls nur vorsichtig planen.
• Mandanten- oder Segmentierungsdesign im Datacenter: Hardware ist möglich, virtuell ist oft sinnvoll.

Häufige Fehler

• Virtuelle Firewall auf überbuchtem Host betreiben.
• WAN, LAN und Management auf dem Hypervisor nicht sauber trennen.
• Hardware nur nach Preis statt nach Sizing auswählen.
• Cloud-Firewall deployen, aber Routing-Tabellen nicht vollständig durchdenken.
• HA planen, aber Host-, Storage- oder Cloud-Ausfälle nicht testen.
• Backup erstellen, aber Restore nie üben.
• Lizenz- und Supportstatus erst beim Firmware-Upgrade prüfen.
• Security-Features wie TLS Inspection oder IPS später aktivieren, ohne Performance-Reserve.
• Plattformteam, Netzwerkteam und Firewall-Verantwortliche erst im Störungsfall zusammenbringen.

Checkliste

• Einsatzort klar definiert: Standort, Datacenter oder Cloud.
• Traffic, Bandbreite und Security-Features für das Sizing erfasst.
• Hardware-, virtuelle, Software- oder Cloud-Variante bewusst gewählt.
• Zuständigkeit für Firewall, Hypervisor, Cloud und Netzwerk dokumentiert.
• HA- und Recovery-Design geprüft.
• Backup- und Restore-Prozess getestet oder geplant.
• Lizenz, Support und Registrierung geklärt.
• Monitoring für Firewall und darunterliegende Plattform vorhanden.
• Upgradefähigkeit und Plattformunterstützung geprüft.
• Verantwortliche für Plattform, Netzwerk, Firewall, Backup und Restore benannt.

FAQ