Sophos Firewall: Hardware, virtuell oder Cloud?

Sophos Firewall kann als XGS Hardware 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, unterstützten virtuellen Plattformen, AWS und Azure angeboten, nicht aber auf Software Appliances sowie XG- oder SG-Hardware.

Betriebsmodell auswählen

Kurzentscheidung

• XGS Hardware 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 Hardware 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 Hardware Appliance

Eine XGS Hardware 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.

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

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 die Primary eine Base Firewall License. Bei Active-Active müssen beide Nodes passend und gleich lizenziert sein. 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