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.

Die physische Sophos-Hardwarepalette deckt unterschiedliche Anforderungen ab, von Heimanwendern über kleine Unternehmen bis zu grossen Unternehmen. Welche XGS Appliance passt, hängt von Traffic, Schutzfunktionen, Ports und HA-Anforderungen ab. Lassen Sie die Auswahl bei Bedarf vom Sophos-Vertrieb oder einem Partner anhand dieser Anforderungen prüfen. Die Eignung für ein Heimnetz bedeutet nicht automatisch, dass die kostenlose Home-Lizenz auf der gewählten Hardware verwendet werden darf.

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.

Sie stellt SFOS-Sicherheitsfunktionen der Hardware-Appliances in virtualisierter Form bereit, einschliesslich identitätsbasierter Sicherheit. Damit wird die Benutzeridentität in die Sicherheitsentscheidung einbezogen, nicht nur die Netzwerkadresse. Organisationen und Managed Security Service Provider (MSSPs) können so den Netzwerkschutz für virtuelle Rechenzentren oder Büros auf einer virtuellen Firewall bündeln. Der tatsächlich nutzbare Funktionsumfang hängt von Lizenz und unterstützter Plattform ab; daraus folgt weder identische Hardwarebeschleunigung noch gleicher Durchsatz wie bei einer XGS Appliance.

Virtuelle und Cloud-Bereitstellungen mit SFOS können über Sophos Endpoint Security Heartbeat auch den Gesundheitszustand verwalteter Endpoints in Zugriffsentscheidungen einbeziehen. Dafür sind passende Endpoint- und Firewall-Lizenzberechtigungen, die Registrierung in derselben korrekten Organisation und eine ausdrücklich konfigurierte Reaktion erforderlich. Identitätsbasierte Sicherheit ist kein gleichwertiger Mechanismus für den Endpoint-Gesundheitszustand; die Registrierung allein belegt weder eine Isolation noch die Sperrung aller Verkehrswege. Voraussetzungen, Reaktionspfade und Wirkungskontrollen erklärt die Anleitung zu Security Heartbeat und Synchronized Security.

Sophos bietet auch eine zentrale Verwaltung der Sophos-Firewall-Geräte an. Der Plattformüberblick für SFOS 22 nennt dafür Sophos Fusion (previously Sophos Central), der für SFOS 23 Sophos Central. Diese unterschiedlichen Bezeichnungen belegen keine Einführung der zentralen Verwaltung mit SFOS 23. Prüfen Sie bei der Planung den in Ihrem Verwaltungsportal verwendeten Dienst und die Voraussetzungen für die Einbindung der Firewall; zentrale Logauswertung allein ist noch keine zentrale Geräteverwaltung.

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.

SFOS bietet auf geeigneter physischer Hardware Firewall-Regeln und Richtlinien, Funktionen zur Reaktion auf Bedrohungen sowie statisches, SD-WAN- und dynamisches Routing. Der nutzbare Umfang hängt von den jeweiligen Lizenzen und der Dimensionierung der Plattform ab. Herstellernamen wie Dell oder HP sind Beispiele, keine geprüfte Kompatibilitätsliste für einzelne Modelle.

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.

Abweichende Storage-Angaben: Die Plattformübersichten für SFOS 22 und 23 nennen für eigene Hardware 10 GB als Minimum. Die spezifischen SFOS-22-Installationsanforderungen für die Software Appliance nennen dagegen mindestens 32 GB und empfehlen 64 GB. Für die Installation folgt diese Anleitung bewusst der konkreteren, konservativen Vorgabe: mindestens 32 GB, empfohlen 64 GB. Planen Sie nicht mit 10 GB und prüfen Sie vor der Installation zusätzlich die Anforderungen der gewählten SFOS-Version. Der Dokumentationswiderspruch ist damit offengelegt, nicht durch einen Gerätetest aufgelöst.

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 oder Software Appliance installieren

Laden Sie das Image direkt von der Sophos-Seite Firewall Installers herunter. Wählen Sie unter Virtual Installers das passende OVF-Paket für Citrix oder VMware, das VHD-Paket für Hyper-V oder das QCOW2-Paket für KVM, Proxmox oder Nutanix. Für eigene Hardware verwenden Sie stattdessen die ISO unter Software Installers.

Prüfen Sie vor dem Import, dass Sie die oben verlinkte Downloadseite über HTTPS aufgerufen, das Paket ohne Drittanbieter-Mirror bezogen und das Archiv vollständig und fehlerfrei entpackt haben. Halten Sie bei einem OVF-Paket Manifest, OVF und beide VMDK-Dateien zusammen. Meldet der Import eine Manifest- oder Prüfsummenabweichung, brechen Sie ab und laden Sie das Paket erneut direkt bei Sophos herunter. Für eine interne Dateiübertragung können Sie unmittelbar nach dem Download zusätzlich einen SHA-256-Wert erfassen und auf dem Zielsystem erneut vergleichen. Das erkennt Übertragungsfehler, ersetzt aber keine Herstellersignatur.

Vor dem Import gelten die Mindestwerte 1 vCPU, 4 GB RAM, zwei vNICs, eine 32 GB grosse Primärdisk und eine 80 GB grosse Report-Disk. Unzureichende Ressourcen lösen den Fail-safe-Modus aus. Prüfen Sie vor Änderungen der Zuweisung den erworbenen CPU-/Ressourcenlizenzumfang; diese Mindestwerte sind keine Dimensionierung für den Produktivbetrieb. Vergrössern Sie die Report-Disk, wenn zusätzliche CPU-/RAM-Ressourcen ein höheres Logvolumen ermöglichen. Hypervisor-Snapshots und Backupwerkzeuge des Plattformherstellers sind keine unterstützten Firewall-Backups; verwenden Sie die SFOS-Backupfunktion.

Die folgenden Abläufe beschreiben die übernommenen Installationsverfahren. Sie sind kein Nachweis für Labor-, Geräte-, Lizenzwirkungs- oder Rollbacktests mit Ihrer konkreten Plattform-/SFOS-Kombination. Prüfen Sie zuerst die aktuelle Unterstützung für Plattform, Betriebssystem, Verwaltungswerkzeug und Image. Validieren Sie die Installation auf einer neuen, isolierten VM, bevor Sie produktiven Traffic darüber routen. Lassen Sie die bestehende Firewall und die produktiven Routen bis zur Abnahme unverändert.

Die Plattformübersichten für SFOS 22 und 23 nennen für die Citrix-Familie zusätzlich XCP-ng-Center als Verwaltungswerkzeug-Alternative zu XenCenter und für VMware auch VMware Workstation als Alternative zum hier beschriebenen ESXi/vSphere-Pfad. Diese dort aufgeführten Optionen sind keine Bestätigung aktueller Unterstützung und keine pauschale Freigabe aller XCP-ng-Versionen. Vor der Wahl einer der Alternativen muss die Unterstützung für die genaue Host-, Plattform- und Verwaltungswerkzeugversion bestätigt sein. Bleibt sie unklar, bricht man die Bereitstellung ab und verwendet einen nachweislich unterstützten Weg. Die folgenden XenCenter- und ESXi/vSphere-Schritte sind keine Installationsanleitung für diese Alternativen; insbesondere darf man den ESXi-Ablauf nicht als Workstation-Rezept übernehmen.

Citrix Hypervisor und XenCenter

Voraussetzungen: Citrix Hypervisor ist auf einem erreichbaren Host installiert, XenCenter auf dem Verwaltungsgerät. Prüfen Sie die unterstützten Host-, Betriebssystem- und Werkzeugversionen. Speichern Sie das entpackte Citrix-OVF-Paket so, dass XenCenter auf alle enthaltenen Dateien zugreifen kann.

1. Klicken Sie in XenCenter mit der rechten Maustaste auf die vorgesehene Ressource und wählen Sie Import > Browse. Wählen Sie die OVF-Datei und klicken Sie auf Open, dann auf Next.
2. Wählen Sie unter Import VM(s) to das Ziel oder geben Sie einen Home Server an. Klicken Sie auf Next und wählen Sie das Storage Repository für beide Disks.
3. Ordnen Sie die Netzwerkschnittstellen gezielt zu: PortA gehört in das isolierte Admin-/LAN-Netz, der WAN-seitige Adapter in das separat vorgesehene WAN-/Testnetz. Machen Sie WebAdmin mit Werkseinstellungen nicht aus dem Internet erreichbar.
4. Verify manifest content ist im Importassistenten optional. Bewahren Sie das Manifest auf und untersuchen Sie jede Abweichung, statt sie zu umgehen. Klicken Sie auf Next. Lassen Sie unter OS Fixup Settings die Option Don’t use Operating System Fixup ausgewählt.
5. Prüfen Sie die Zusammenfassung und klicken Sie auf Finish. Bestätigen Sie den erfolgreichen Import, beide Disks und die vorgesehenen Zuordnungen beider NICs, bevor Sie diese neue VM per Rechtsklick mit Start starten. Öffnen Sie die Konsole und folgen Sie dem gemeinsamen Verfahren für den Erstzugriff weiter unten.

VMware ESXi und vSphere Client

Voraussetzungen: Auf dem Server läuft eine aktuell unterstützte ESXi-Version, und der Administrator verfügt über eine funktionierende, über das Netzwerk erreichbare Verwaltungssitzung im vSphere Client. Entpacken Sie das VMware-Paket auf dem Verwaltungsgerät. Alte Angaben zur virtuellen Hardwareversion belegen keine aktuelle Unterstützung für ESXi 4 oder 5.

Wählen Sie die OVF-Vorlage gezielt aus:

• sf_virtual und sf_virtual_vm7: ältere Hardwareversion 7, PCNet32 (Vlance), virtuelle Linkangabe 10 Mbps, Halbduplex, fest eingestellt.
• sf_virtual_vm8: Hardwareversion 8, E1000E, 1000 Mbps, Vollduplex, Auto-Negotiation On.
• sf_virtual_vm8_paravirtual: Hardwareversion 8, VMXNET 3, 10000 Mbps, Vollduplex, Auto-Negotiation Off. Verwenden Sie E1000E als dokumentierte Ausweichoption, wenn der VMXNET-3-Treiber in Ihrer Umgebung nicht funktioniert.
• sf_virtual_virtualbox ist keine VMware-Vorlage. Die genannten Linkangaben beschreiben virtuelle Adaptereigenschaften und sind keine Garantien für den Firewall-Durchsatz.

1. Klicken Sie im vSphere Client mit der rechten Maustaste auf den Bereitstellungsort und wählen Sie Deploy OVF Template > Local file > Choose files. Wählen Sie die gewünschte OVF-Datei zusammen mit sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk und sf_virtual.mf. Klicken Sie auf Open > Next.
2. Geben Sie Name und Speicherort an, wählen Sie die Compute-Ressource und prüfen Sie die Details. Gehen Sie jeweils mit Next weiter.
3. Wählen Sie Datastore und virtuelles Diskformat. Thick Provision Lazy Zeroed reserviert den Speicher bei der Erstellung und setzt Blöcke beim ersten Schreiben auf null. Thick Provision Eager Zeroed reserviert den Speicher und setzt ihn bereits bei der Erstellung auf null; dies kann länger dauern. Thin Provision weist Speicher nach Bedarf zu und spart dadurch Platz; überwachen Sie die tatsächlich verfügbare Datastore-Kapazität. Weder diese Formatbeschreibungen noch das Verfahren belegen eine Sophos-Unterstützung für Fault Tolerance oder eine allgemeingültige Einschränkung für Diskkonvertierungen.
4. Ordnen Sie beide Quellnetze gezielt zu; PortA muss im isolierten Adminnetz liegen. Prüfen Sie die gesamte Konfiguration und klicken Sie auf Finish. Warten Sie auf die erfolgreiche Bereitstellung und prüfen Sie die Grössen beider Disks sowie die Zuordnung und Verbindung der NICs.
5. Wählen Sie Actions > Power > Power on, öffnen Sie die Konsole und folgen Sie dem gemeinsamen Verfahren für den Erstzugriff.

Hyper-V Manager

Voraussetzungen: ein unterstützter Hyper-V-Host sowie Hyper-V Manager auf einem Verwaltungsgerät mit Netzwerkzugriff auf diesen Host. Entpacken Sie das Hyper-V-Paket und legen Sie beide VHD-Dateien in einem für den Host zugänglichen Speicher ab. Ein Pfad, der nur auf dem PC des Administrators sichtbar ist, reicht für einen entfernten Host nicht aus.

1. Öffnen Sie Action > Connect to Server, danach Action > New > Virtual Machine. Wählen Sie im Assistenten Name und Speicherort, Generation 1 und unter Startup memory mindestens 4096 MB.
2. Wählen Sie für den ersten Adapter den isolierten virtuellen Adminswitch. Wählen Sie Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Prüfen Sie die Angaben und klicken Sie auf Finish; starten Sie die VM noch nicht.
3. Klicken Sie mit der rechten Maustaste auf die neue VM, öffnen Sie Settings und wählen Sie unter Hardware die Optionen Network Adapter > Add. Ordnen Sie diesen zweiten Adapter dem separat geplanten Netz zu und klicken Sie auf Apply.
4. Wählen Sie SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, wählen Sie AUXILIARY-DISK.vhd und klicken Sie auf Open > OK. Prüfen Sie die primäre Bootdisk, die zusätzliche SCSI-Disk, beide Switchzuordnungen und die Diskgrössen.
5. Wählen Sie per Rechtsklick auf die VM Connect und starten Sie sie über die Konsole. Folgen Sie dem gemeinsamen Verfahren für den Erstzugriff.

KVM und Virtual Machine Manager

Voraussetzungen: ein x86-Linux-Host mit aktuellem Kernel und aktivierter Intel-VT- oder AMD-V-Unterstützung sowie ein installierter, zugänglicher Virtual Machine Manager oder geeignete unterstützte KVM-Verwaltungswerkzeuge. Führen Sie diese ausschliesslich lesenden Prüfungen auf dem Linux-Host aus, nicht in der SFOS-Konsole:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Erwartet werden passende vmx-Flags bei Intel oder svm-Flags bei AMD, nicht zwingend beide. Liefert die relevante Prüfung keine Treffer, brechen Sie ab und prüfen Sie CPU-Fähigkeiten, Virtualisierungseinstellungen in der Firmware und bei einem verschachtelten Host die Bereitstellung dieser Funktionen. Sichtbare Flags allein belegen weder die Aktivierung in der Firmware noch eine funktionierende KVM-Umgebung. #!sh in älteren Anleitungen ist eine Formatierungsmarkierung, kein Befehlspräfix.

1. Entpacken Sie das KVM-Archiv. Öffnen Sie File > New Virtual Machine > Import existing disk image > Browse, wählen Sie PRIMARY-DISK.qcow2 mit Choose volume und klicken Sie auf Forward.
2. Setzen Sie Memory (RAM) auf mindestens 4096 MB und CPU auf mindestens 1, jeweils innerhalb des Lizenzumfangs und passend zur Dimensionierung. Wählen Sie Customize configuration before install > Finish. Geben Sie einen Namen ein und klicken Sie auf Apply.
3. Wählen Sie als Network source der ersten NIC das isolierte Adminnetz. Das übernommene Beispiel verwendet Device model > Hypervisor default. Prüfen Sie, ob der dadurch gewählte Adapter unterstützt wird, und klicken Sie auf Apply. Wählen Sie keine unsegmentierte gemeinsame WAN-/LAN-Bridge.
4. Wählen Sie die primäre Disk, die anfangs als IDE Disk 1 angezeigt wird, und danach Advanced options > Disk bus > VirtIO > Apply.
5. Wählen Sie Add Hardware > Network, das separat geplante Netz und Device model > virtio > Finish.
6. Wählen Sie Add Hardware > Storage > Select or create custom storage > Manage. Wählen Sie AUXILIARY-DISK.qcow2 mit Choose volume, setzen Sie Disk bus > VirtIO und klicken Sie auf Finish.
7. Prüfen Sie beide Disks, Buszuordnungen, Grössen und NIC-Zuordnungen, bevor Sie Begin Installation wählen. Wählen Sie die Firewall und öffnen Sie ihre Konsole mit Open. Folgen Sie dem gemeinsamen Verfahren für den Erstzugriff.

Proxmox VE: Verfahren für Directory-Storage

Dieses pfadbasierte Verfahren gilt für geeigneten Directory-Storage, nicht für beliebige LVM-, ZFS- oder Ceph-Backends. Prüfen Sie zuerst /etc/pve/storage.cfg, um die tatsächliche Storage-ID, den Backendtyp und den Pfad zu bestimmen. Kann Ihr Backend diese QCOW2-Dateipfade nicht verwenden, brechen Sie ab und beschaffen Sie das passende unterstützte Importverfahren. Übernehmen Sie keine Directory-Beispiele in ein anderes Backend.

1. Wählen Sie den Server und Create VM. Geben Sie Name an, wählen Sie Do not use any media, legen Sie zur Umgebung passende Einstellungen für System, Hard Disk und CPU fest und setzen Sie Memory (MB) auf mindestens 4096. Die Standardwerte für Machine, SCSI Controller und Cache sind beispielabhängig und keine allgemeingültigen Vorgaben.
2. Wählen Sie die isolierte Admin-Bridge. Lassen Sie Start after created deaktiviert, prüfen Sie die Angaben und klicken Sie auf Finish. Notieren Sie die VMID und bestätigen Sie, dass es sich um die neue, noch ungenutzte Test-VM handelt.
3. Öffnen Sie >_ Shell auf dem Host mit den erforderlichen Berechtigungen. Lassen Sie nur diese neue VM ausgeschaltet, sichern Sie eine Kopie von /etc/pve/qemu-server/<vmid>.conf und dokumentieren Sie ihre vorhandene Diskzuordnung. Löschen oder ersetzen Sie niemals eine produktive Disk. /var/lib/vz/images/108/ ist lediglich ein Beispielverzeichnis für VMID 108; verwenden Sie den Pfad Ihres bestätigten Storage und Ihrer VMID.
4. Übertragen Sie das tatsächlich heruntergeladene KVM-Archiv in dieses Verzeichnis und entpacken Sie es, beispielsweise mit unzip ACTUAL_DOWNLOADED_ARCHIVE.zip, nachdem Sie den Platzhalter durch den tatsächlichen Dateinamen ersetzt haben. Erwartet werden PRIMARY-DISK.qcow2 und AUXILIARY-DISK.qcow2. Ein historischer Build-Dateiname ist keine Anweisung für den aktuellen Download.
5. Öffnen Sie /etc/pve/qemu-server/<vmid>.conf in einem Texteditor. Ersetzen Sie ausschliesslich bei dieser ausgeschalteten, entbehrlichen Test-VM die anfängliche scsi0-Zuordnung und ergänzen Sie die Zuordnung der zusätzlichen Disk. Die übernommene Beispielsyntax lautet:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Ersetzen Sie vmdisk durch die bestätigte Directory-Storage-ID und <vmid> durch die tatsächliche VMID. Diese Platzhalter sind keine wörtlich verwendbaren Werte. Die size-Angaben vergrössern kein zu kleines Image. Prüfen Sie, dass die tatsächlichen Images die Mindestgrössen erfüllen und keine vorhandene scsi1-Zuordnung überschrieben wird.

6. Prüfen Sie unter Hardware beide Diskslots, die Grössen und die primäre Bootdisk. Fügen Sie mit Add > Network device die zweite NIC auf der gezielt gewählten separaten Bridge hinzu. Lassen Sie unter Options den QEMU Guest Agent deaktiviert. Prüfen Sie die Zuordnungen erneut, bevor Sie Start wählen und die Konsole öffnen.
7. Ist die Änderung fehlerhaft, lassen Sie die neue VM ausgeschaltet und stellen Sie ihre gesicherte Konfiguration wieder her, nachdem Sie VMID und Storage-Identität erneut geprüft haben. Löschen Sie beim Zurücksetzen nicht die ursprüngliche Diskdatei. Diese lokale Rücknahme ist ein Verfahren vor der Produktivsetzung, keine getestete Wiederherstellung im Produktivbetrieb. Folgen Sie dem gemeinsamen Erstzugriff erst, wenn die korrigierten Hardwareprüfungen erfolgreich sind.

Nutanix Prism Central

Voraussetzungen: AOS 6.5.x oder eine neuere LTS-Version, die dazugehörige AHV-Version, ein kompatibles Prism Central (PC) und ein bei PC registrierter AHV-Cluster. Die Plattformanleitung nennt die neueste GA (LTS)-Version der Partner-VA: GA bedeutet General Availability, LTS bedeutet Long-Term Support. Prüfen Sie die tatsächlich unterstützte Version der Partner-Appliance und die Plattformkombination; eine SFOS-23-Hilfeseite allein bestimmt nicht die neueste GA-Version. Bestätigen Sie die lizenzierten CPU-Ressourcen, mindestens 4 GB RAM, zwei NICs und Disks mit 32 GB/80 GB.

1. Entpacken Sie auf dem Verwaltungsgerät PRIMARY-DISK.qcow2 und AUXILIARY-DISK.qcow2 aus Virtual Installers: Firewall OS for KVM.
2. Öffnen Sie in PC Virtual Infrastructure > Images > Add Image > Add File. Fügen Sie jede Datei mit Image Type > Disk hinzu. Klicken Sie auf Next, wählen Sie Placement Method und Select Clusters für das Ziel und klicken Sie auf Save. Aktualisieren Sie die Ansicht nach dem Upload und prüfen Sie, ob beide Images verfügbar sind.
3. Öffnen Sie Infrastructure > VMs > Create VM. Legen Sie unter General Configuration Name und Zeitzone fest, unter Compute Details die lizenzierte CPU-Zuweisung und ausreichend RAM. Entfernen Sie unter Disks das standardmässige CD-ROM-Laufwerk ausschliesslich bei dieser neuen VM.
4. Wählen Sie Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Wiederholen Sie den Vorgang für AUXILIARY-DISK.qcow2 als Logdisk; auch das übernommene Beispiel für diese zusätzliche Disk verwendet SCSI. Übertragen Sie die KVM-Anweisungen für den VirtIO-Bus nicht auf dieses Verfahren.
5. Wählen Sie unter Network Adapters (NIC) > Add New NIC > VLAN Name das isolierte Admin-VLAN und klicken Sie auf Add. Wiederholen Sie den Vorgang für das separat vorgesehene zweite Netz. Die DHCP-Konnektivitätsoption der Ausgangsanleitung ist optional; planen Sie anschliessend stabile Schnittstellenadressen. Die Auswahl eines VLANs ist selbst keine IP-Adresse.
6. Wählen Sie unter VM Host Affinity > Set Affinity einen freigegebenen Host und klicken Sie auf Save. Speichern Sie anschliessend die VM. Erwarten Sie eine Erfolgsmeldung und prüfen Sie vor dem Einschalten beide Disks, Buszuordnungen, Grössen und NIC-Zuordnungen.
7. Schalten Sie die neue VM ein und wählen Sie Launch console. Folgen Sie dem gemeinsamen Verfahren für den Erstzugriff.

Erstzugriff, Validierung und sichere Rücknahme

Prüfen Sie vor dem ersten Einschalten die Zuordnung von PortA und PortB zu Management-, LAN- und WAN-Netzen. Vertauschte Zuordnungen können WebAdmin direkt aus dem Internet erreichbar machen. Ausschliesslich in der isolierten Erstinstallationsumgebung gilt das dokumentierte werkseitige Administratorkonto mit Passwort admin / admin; die Konsole fordert das Administratorpasswort admin an. Öffnen Sie https://172.16.16.16:4444 vom isolierten Adminclient aus, beispielsweise mit der Adresse 172.16.16.2/24. Lesen und akzeptieren Sie die Sophos End User Terms of Use und klicken Sie für Registrierung und Grundeinrichtung auf Start setup. Ersetzen Sie die werkseitigen Zugangsdaten während der Einrichtung, bevor Sie die Firewall für andere Netze zugänglich machen. Folgen Sie danach der Anleitung zur Ersteinrichtung.

Ändern Sie das Standardpasswort nicht vor dem Assistenten in der CLI: Danach startet der Assistent nicht mehr. Ist dies bereits geschehen, führen Sie die Grundeinrichtung manuell durch. Setzen Sie keine konfigurierte Firewall nur deshalb zurück, um den Assistenten wieder verfügbar zu machen. Ein Zurücksetzen auf Werkseinstellungen zerstört die Konfiguration und kommt nur als bewusste Option für eine geschützte, entbehrliche neue VM ohne aufzubewahrende Konfiguration infrage.

Prüfen Sie vor der produktiven Umschaltung Lizenz und Seriennummer, den normalen Start in der Konsole, beide Disks und das Reporting, Schnittstellen und Zonen, das unterstützte SFOS-Backup sowie einen negativen WebAdmin-Zugriffstest aus einem nicht berechtigten Netz. Dies sind Prüfungen, die der Betreiber durchführen muss, keine hier als getestet behaupteten Ergebnisse.

Ist WebAdmin nicht erreichbar, installieren Sie nicht sofort neu. Prüfen Sie, ob der Client direkt im Netz von PortA liegt, die vNIC verbunden ist und die Portgruppe beziehungsweise Bridge tatsächlich dem isolierten Adminnetz zugeordnet ist. Bestätigen Sie in der Konsole den vollständigen Start und schliessen Sie einen Adresskonflikt mit 172.16.16.16 aus. PortA darf nicht im öffentlichen WAN liegen. Bei fehlenden Reports oder Fail-safe-Modus müssen Report-Disk-Zuordnung, Bus und Grösse, CPU/RAM und beide vNICs geprüft werden. Dokumentieren Sie die erkannte Ursache vor Ressourcenänderungen mit dem Fail-safe-Runbook.

Wenn Sie die neue Bereitstellung vor der Produktivsetzung zurücknehmen möchten und noch kein produktiver Traffic über die neue VM geroutet wird, schalten Sie sie aus, setzen Test-Routen und temporäre Gateways zurück und verwenden die unveränderte bestehende Firewall weiter. Diese Schritte gelten nur für die Rücknahme, nicht für eine erfolgreich validierte Produktivsetzung. Nach der Produktivsetzung erfordert die Wiederherstellung ein aktuelles SFOS-Backup und einen dokumentierten Neuaufbau, keinen Hypervisor-Snapshot. Verwenden Sie das Verfahren für Backup und Wiederherstellung.

Software Appliance auf eigener Hardware

Das Zielsystem benötigt x86-64, Legacy BIOS, mindestens 4 GB RAM, zwei NICs und eine HDD/SSD mit 32 GB (64 GB empfohlen). Der USB-Stick benötigt mindestens 1 GB. Windows/macOS ist das Betriebssystem des Arbeitsplatzrechners zum Schreiben des Installationsmediums, kein neben SFOS erhaltenes Betriebssystem. Verwenden Sie den Download Software Installers: Firewall OS Software ISO for Intel Hardware, entpacken Sie das Archiv und prüfen Sie die SW-ISO sowie die Übertragungsintegrität wie oben beschrieben. Verwenden Sie weder ein HW-/XGS-Image noch ein virtuelles Diskpaket.

⚠️ Das Schreiben des Mediums löscht das gesamte ausgewählte USB-Gerät. Die anschliessende Installation formatiert und partitioniert den Zieldatenträger des Servers neu und löscht dessen bisheriges Betriebssystem sowie sämtliche Daten. Identifizieren Sie vor beiden Vorgängen das genaue Gerät anhand von Kapazität und Geräteidentität, sichern Sie Daten extern und prüfen Sie einen unabhängigen Wiederherstellungsweg. Brechen Sie ab, wenn das Ziel nicht eindeutig ist. Nach der Installation gibt es keine automatische Rücknahme; die Wiederherstellung erfordert separat gesicherte Medien und Daten des ursprünglichen Systems oder ein kompatibles SFOS-Backup mit dessen Passwort und zugehörigem SSMK.

Windows: Win32 Disk Imager

1. Stecken Sie den USB-Stick ein und identifizieren Sie in der Windows-Datenträgerverwaltung Laufwerksbuchstaben, Kapazität und Geräteidentität. Trennen Sie nach Möglichkeit andere Wechseldatenträger. Beschaffen und starten Sie Win32 Disk Imager auf dem Arbeitsplatzrechner.
2. Die Dateiauswahl filtert normalerweise nach IMG-Dateien. Ändern Sie den Filter auf *.* und wählen Sie die entpackte Sophos-SW-Datei mit der Endung .ISO.
3. Wählen Sie das bestätigte USB-Ziel, keinen Systemdatenträger oder Datenträger mit Nutzdaten. Vergleichen Sie die ausgewählte Datei und das Laufwerk erneut mit der dokumentierten Identität. Klicken Sie dann auf Write und bestätigen Sie die Löschwarnung. Warten Sie auf den erfolgreichen Abschluss und werfen Sie den USB-Stick sicher aus. Das Kopieren der ISO als normale Datei erstellt kein bootfähiges Medium.

macOS: Alternative mit integrierten Werkzeugen

1. Identifizieren Sie im Festplattendienstprogramm den externen USB-Stick anhand von Kapazität und Geräteidentität. Ältere Anleitungen zeigen Partitions > Volume scheme: 1 partition > Format: Free Space > Apply. Diese Bedienelemente sind versionsabhängig und möglicherweise in Ihrer macOS-Version nicht vorhanden. Erfinden Sie keine gleichwertige Bedienfolge und formatieren Sie keinen anderen Datenträger, um die alte Oberfläche nachzubilden. Das Verfahren zum Schreiben von Medien in der Reimage-Anleitung ist eine Alternative; verwenden Sie hier die SW-ISO statt des dortigen Hardware-Images.
2. Wechseln Sie im Terminal in das ISO-Verzeichnis. Ersetzen Sie SOPHOS_ISO vor der Ausführung durch den tatsächlichen Namen der heruntergeladenen Datei:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Erwartet wird die konvertierte Datei sf.img.dmg. Führen Sie diskutil list aus, identifizieren Sie erneut den gesamten externen USB-Datenträger und hängen Sie dessen Volumes vor dem direkten Schreiben aus; verwenden Sie im Festplattendienstprogramm Unmount, nicht Auswerfen. Brechen Sie ab, wenn Sie das vorgesehene Gerät nicht eindeutig identifizieren oder aushängen können.
4. Die folgende Zeile ist eine Vorlage, kein direkt ausführbarer Befehl zum Einfügen. Ersetzen Sie PATH_TO_USB durch den bestätigten Pfad des gesamten Geräts, niemals durch eine Partition oder eine angenommene Datenträgernummer. Der Befehl löscht das gesamte Gerät:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Verwenden Sie sudo nur, wenn die Geräteberechtigungen dies erfordern, und prüfen Sie vorher erneut das Ziel. Für den Raw-Gerätepfad wird dem bestätigten Gerätenamen ein r hinzugefügt: Aus /dev/diskN wird /dev/rdiskN. N ist ein Platzhalter, keine zu übernehmende Datenträgernummer. Raw-Zugriff kann schneller sein, macht den Vorgang aber nicht sicherer. Warten Sie auf die Rückkehr der Eingabeaufforderung und den erfolgreichen Abschluss. Schreiben Sie mit sync noch ausstehende Daten und werfen Sie den USB-Stick sicher aus, bevor Sie ihn entfernen. Brechen Sie bei Fehlern ab, statt von einem nicht verifiziert geschriebenen Medium zu installieren.

Physischen Server installieren und prüfen

1. Planen Sie ein Wartungsfenster, erhalten Sie den bisherigen Firewall-Pfad und externe Backups und prüfen Sie Legacy BIOS, USB-Boot sowie den genauen Installationsdatenträger. Trennen Sie nach Möglichkeit andere Datenträger mit Nutzdaten. Schliessen Sie einen lokalen Monitor und eine Tastatur sowie bei Bedarf eine geeignete serielle Konsole an.
2. Starten Sie vom vorbereiteten USB-Stick. Prüfen Sie vor der Eingabe von y und dem Drücken der Eingabetaste bei der Installationsbestätigung erneut die Server- und Datenträgeridentität. Bestätigen Sie, dass das bisherige Betriebssystem und alle Daten verloren gehen dürfen. Ist das Installationsziel unklar, brechen Sie ab. Folgen Sie den Anweisungen bis zum Abschluss, entfernen Sie den USB-Stick und starten Sie neu. Der erste Start kann einige Minuten dauern. Wenden Sie XGS-LED-Anweisungen nicht auf diesen allgemeinen Server an.
3. Prüfen Sie die erkannten NICs und identifizieren Sie die Managementschnittstelle, bevor Sie den isolierten Adminclient mit 172.16.16.2/24 anschliessen. Bestätigen Sie den normalen Start und verwenden Sie https://172.16.16.16:4444, die Terms of Use und Start setup wie oben beschrieben. Sichern Sie die Zugangsdaten ab, schliessen Sie Registrierung und Lizenzierung ab und speichern Sie vor der Umschaltung ein externes SFOS-Backup.
4. Startet der USB-Stick nicht, prüfen Sie, ob das Image auf das Medium geschrieben statt nur als Datei kopiert wurde, ob es sich um das richtige SW-Image handelt und ob Legacy BIOS sowie USB-Boot korrekt gewählt sind. Bei fehlenden NICs oder Fail-safe-Modus dokumentieren Sie die Konsolenursache und prüfen vor einer Neuinstallation Mindestanforderungen und Treiberkompatibilität. Ist WebAdmin nicht erreichbar, prüfen Sie die Identität der Management-NIC, den Link, die Clientadresse, den vollständigen Start und mögliche Adresskonflikte. Verbinden Sie das werkseitige Management niemals als Abkürzung mit dem öffentlichen WAN. Nutzen Sie für die nächste Entscheidung die interne Fail-safe-Anleitung, die Anleitung zur Ersteinrichtung und die Anleitung für Backup und Wiederherstellung.

Diese dokumentarische Anleitung behauptet nicht, dass dafür ein USB-Schreibvorgang, ein destruktiver Installationsschritt, eine Bereitstellung auf einem physischen Gerät oder eine Wiederherstellung durchgeführt wurde.

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

Die Lizenzierung muss vor der Bereitstellung oder vor Ressourcenänderungen geprüft werden. Ältere plattformspezifische Installationsanleitungen begrenzen sowohl vCPU als auch vRAM auf den erworbenen Lizenzumfang. Unser interner Beitrag beschreibt für kommerzielle virtuelle, Software- und Cloud-BYOL-Lizenzen eine Änderung zum 1. März 2025 hin zur Lizenzierung nach CPU-Cores ohne die frühere RAM-Obergrenze. Diese Beschreibung belegt nicht, dass für jede SKU, jeden älteren Lizenzanspruch oder jede Home-Lizenz dieselben Bedingungen gelten. Bestätigen Sie vor der Ressourcenzuweisung die erworbene SKU und den Core-Lizenzumfang, die Seriennummer, Subscription und Support sowie den tatsächlichen Lizenzstatus der Instanz im Lizenzportal. Ist der Lizenzumfang unklar, brechen Sie ab und klären Sie ihn mit dem Lizenzanbieter. Übertragen Sie die kommerzielle Änderung nicht auf Home-Lizenzen und leiten Sie aus diesem Artikel keine unbegrenzten Ressourcen ab. Das Installationsminimum von 4 GB und die Dimensionierung von RAM, Storage und NICs für den Produktivbetrieb bleiben technische Anforderungen, unabhängig von einer gegebenenfalls geltenden Lizenzobergrenze.

Die Grundlagen erläutert Sophos Firewall: Base License. Die beschriebene kommerzielle Änderung ist im Beitrag Sophos Firewall VM und Software: CPU-Core-Lizenzierung ohne bisherige RAM-Obergrenze 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

• Eine virtuelle Firewall läuft auf einem überbuchten Host.
• WAN, LAN und Management sind auf dem Hypervisor nicht sauber getrennt.
• Die Hardwareauswahl richtet sich nur nach dem Preis statt nach der erforderlichen Kapazität und Leistung.
• Eine Cloud-Firewall wird bereitgestellt, obwohl das Routingdesign noch unvollständig ist.
• HA wird geplant, ohne Host-, Storage- oder Cloud-Ausfälle zu testen.
• Backups werden erstellt, aber die Wiederherstellung wird nie geübt.
• Lizenz- und Supportstatus werden erst beim Firmware-Upgrade geprüft.
• TLS Inspection oder IPS werden ohne ausreichende Leistungsreserven zusätzlich aktiviert.
• Plattform-, Netzwerk- und Firewall-Verantwortliche werden erst nach einer Störung gemeinsam einbezogen.

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