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.
Kurzentscheidung
| Variante | Passt meistens, wenn |
|---|---|
| XGS Hardware Appliance | ein Standort eine dedizierte, klar supportbare Firewall mit physischen Ports braucht |
| Virtuelle Appliance | eine stabile Virtualisierungsplattform vorhanden ist und Netzwerkzonen sauber virtuell getrennt werden können |
| Software Appliance | eigene Hardware bewusst als Firewall-Plattform betrieben und unterstützt werden soll |
| Cloud Deployment | 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.
| Warnsignal | Warum es kritisch ist |
|---|---|
| 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.
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 unter anderem VMware, Microsoft Hyper-V, KVM, Nutanix Prism und Citrix Hypervisor. Wichtig ist, dass die Plattform, Management-Tools und Netzwerkkonfiguration aktuell und unterstützt sind.
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.
Software Appliance
Eine Software Appliance wird auf eigener 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.
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.
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 können. Bei virtuellen und softwarebasierten Sophos-Firewall-Instanzen ist besonders relevant, wie CPU-Cores, Seriennummer, Support und Subscription geplant werden.
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.
Entscheidungsmatrix
| Frage | Eher Hardware | Eher virtuell oder Cloud |
|---|---|---|
| Klassischer Standort mit WAN, LAN, DMZ | ja | nur bei guter Virtualisierungsstrategie |
| Rechenzentrum mit bestehendem Hypervisor-Team | möglich | oft sinnvoll |
| Cloud-Workloads in AWS oder Azure | nein | ja |
| Einfacher Support und RMA wichtig | ja | abhängig vom Plattformteam |
| Viele physische Ports nötig | ja | nur mit sauberem NIC-/vSwitch-Design |
| Dynamische Skalierung und Infrastruktur-as-Code | eher nein | eher ja |
| Kleines IT-Team ohne Hypervisor-Spezialwissen | meist ja | eher vorsichtig |
| Mandanten- oder Segmentierungsdesign im Datacenter | möglich | 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.