Sophos Firewall Sizing Guide: XGS Appliance richtig dimensionieren

Beim Sophos Firewall Sizing geht es nicht nur um die Anzahl Benutzer. Eine Firewall kann bei gleicher Benutzerzahl sehr unterschiedlich belastet werden: durch Internet-Bandbreite, TLS Inspection, IPS, VPN, Web Protection, WAF, Reporting, HA, viele VLANs oder viele gleichzeitige Verbindungen.

Ein gutes Sizing sorgt dafür, dass die Sophos Firewall nicht nur am ersten Tag funktioniert, sondern auch mit aktivierten Schutzfunktionen, realistischem Wachstum und sauberem Betrieb noch Reserve hat. Für die Entscheidung zwischen Hardware und Virtual Appliance passt zusätzlich Sophos Firewall - Hardware oder virtuelle Appliance?.

Ziel des Sizings

Das Ziel ist nicht, das kleinste Modell zu finden, das unter idealen Laborbedingungen noch reicht. In der Praxis sollte die Firewall auch dann stabil bleiben, wenn mehrere Dinge gleichzeitig passieren:

• viele Benutzer arbeiten parallel,
• TLS Inspection oder IPS ist aktiv,
• Site-to-Site- oder Remote-Access-VPNs laufen,
• Reporting und Logging erzeugen zusätzliche Last,
• Backups, Updates oder Supportdiagnosen laufen im Hintergrund,
• ein Standort wächst oder bekommt mehr Bandbreite.

Deshalb sollte man immer mit Reserven planen. Eine knapp dimensionierte Firewall erzeugt später Supportaufwand: langsame Internetverbindungen, hohe CPU-Last, Paketverluste, träges WebAdmin, instabile VPN-Verbindungen oder fehlende Reserven für neue Sicherheitsfunktionen.

Die wichtigsten Sizing-Faktoren

Internet-Bandbreite und Traffic-Profil

Die gebuchte Internetleitung ist ein guter Startpunkt, aber nicht die ganze Wahrheit. Wichtig ist, wie viel davon tatsächlich gleichzeitig genutzt wird und welcher Traffic über die Firewall läuft.

Prüfen:

• symmetrische oder asymmetrische Leitung,
• Peak-Traffic zu Geschäftszeiten,
• viele kleine Websessions oder wenige grosse Downloads,
• Cloud-Backups, Microsoft 365, VoIP, Online-Meetings,
• Standortvernetzung über VPN oder SD-WAN,
• interner Traffic zwischen VLANs, der ebenfalls durch die Firewall geführt wird.

Wenn die Firewall auch als internes Routing- und Segmentierungsgerät arbeitet, muss man nicht nur WAN-Durchsatz, sondern auch Ost-West-Traffic einplanen. Die Grundlagen zu Zonen, VLANs und Interface-Design stehen in Sophos Firewall Zonen und Interfaces konfigurieren.

Schutzfunktionen

Je mehr Security-Module aktiv sind, desto stärker muss die Appliance dimensioniert werden. Besonders relevant sind:

• IPS,
• Web Protection,
• Application Control,
• SSL/TLS Inspection,
• Zero-Day Protection,
• WAF,
• Mail Protection,
• Threat Feeds,
• Reporting und Log Viewer.

Datenblattwerte sind nur dann vergleichbar, wenn klar ist, welche Funktion gemessen wurde. Firewall-Durchsatz ohne Security-Inspection ist nicht dasselbe wie Threat-Protection- oder TLS-Inspection-Durchsatz. Für produktive Umgebungen sollte man deshalb nicht nur auf den höchsten Marketingwert schauen, sondern auf die Kennzahl, die zum eigenen Einsatz passt.

Bei TLS Inspection ist zusätzlich wichtig, ob die Organisation den Rollout technisch und organisatorisch sauber betreiben kann. Der praktische Ablauf ist in Sophos Firewall TLS Inspection sauber ausrollen beschrieben.

Benutzer, Geräte und Sessions

Die Benutzerzahl bleibt wichtig, reicht aber nicht aus. Ein Büro mit 50 Benutzern, wenigen Cloud-Diensten und ohne TLS Inspection belastet die Firewall anders als ein Standort mit 50 Benutzern, Terminalservern, vielen SaaS-Anwendungen, VoIP, Gastnetz, IoT, Remote Access und mehreren Serverzonen.

Zusätzlich zählen:

• Anzahl Endgeräte pro Benutzer,
• Gast- und IoT-Netze,
• Server, Drucker, Kameras und Spezialgeräte,
• gleichzeitige Sessions,
• viele kleine DNS- oder Webanfragen,
• Remote-Access-Benutzer,
• automatisierte Systeme wie Backup, Monitoring oder EDR.

In gemischten Umgebungen mit vielen VLANs sollte man eher nach Traffic-Flüssen planen als nur nach Kopfzahl.

VPN, SD-WAN und Standortvernetzung

VPN kann eine Firewall stark belasten, besonders wenn viele Tunnel, hohe Bandbreite oder viele Remote-Access-Benutzer zusammenkommen.

Einplanen:

• Site-to-Site IPsec,
• route-based VPN mit XFRM-Interfaces,
• Remote Access über Sophos Connect oder SSL VPN,
• SD-WAN Policy Routes,
• mehrere WAN-Leitungen,
• Failover-Szenarien,
• MTU/MSS-Themen bei VPN-Strecken.

Bei VPN-Performance sollte man nicht nur den Tunnelstatus betrachten. Entscheidend ist, ob der produktive Traffic mit aktivierten Regeln, NAT, Routing und Security-Inspection stabil läuft. Für Routing- und VPN-Pfade sind IPsec Route auf Sophos Firewall und SD-WAN Routing für Reply Packets und System Traffic passende Vertiefungen.

Logging, Reporting und Speicher

Logging hilft im Betrieb, erzeugt aber ebenfalls Last und Speicherbedarf. Wer viele Firewall-Regeln mit Logging, Webfilter, IPS, Application Control und Central Firewall Reporting nutzt, sollte die Reporting-Anforderungen früh klären.

Prüfen:

• Welche Regeln sollen Logging aktiv haben?
• Wie lange müssen Logs verfügbar sein?
• Wird Sophos Central Firewall Reporting genutzt?
• Gibt es Syslog oder SIEM?
• Müssen Reports regelmässig erstellt werden?
• Werden Logdaten für Troubleshooting oder Compliance benötigt?

Für längere Auswertung ist die Firewall allein oft nicht der richtige Ort. Dann sollte man Sophos Central Firewall Reporting oder einen Syslog-/SIEM-Export einplanen.

Hardware, virtuell oder Cloud?

XGS Appliance

Eine XGS Appliance ist meistens die planbarste Variante für klassische Standorte. Hardware, Ports, Support, Lifecycle und Performance sind als Gesamtpaket definiert.

Vorteile:

• dedizierte Firewall-Hardware,
• klare Port- und Erweiterungsoptionen,
• einfache Support- und RMA-Abwicklung,
• planbare Leistung,
• weniger Abhängigkeit von einem Hypervisor.

Hardware ist besonders sinnvoll, wenn die Firewall am Standort der zentrale Security- und Routing-Punkt ist.

Virtuelle Sophos Firewall

Eine virtuelle Firewall passt gut in Rechenzentren, Cloud-Umgebungen oder virtualisierte Netzwerksegmente. Die Leistung hängt dann stark von CPU, RAM, Storage, Hypervisor, virtuellen Netzwerkkarten und Host-Auslastung ab.

Wichtig:

• CPU-Ressourcen dürfen nicht dauerhaft überbucht sein.
• Virtuelle NICs und Portgruppen müssen sauber getrennt sein.
• Storage-Latenz kann Logging und Reporting beeinflussen.
• Backup und Restore müssen zur Virtualisierungsplattform passen.
• HA- und Failover-Design müssen vorab geplant werden.

Die Lizenzierung und Entscheidung zwischen Hardware und virtueller Appliance sollte separat geprüft werden. Dafür passt Sophos Firewall - Hardware oder virtuelle Appliance?.

Von den Anforderungen zum passenden Modell

Eine feste Zuordnung wie «50 Benutzer = Modell X» wäre irreführend. Die technischen Grenz- und Durchsatzwerte pro Appliance ergeben keine allgemeingültige Benutzerobergrenze. Zwei Standorte mit derselben Kopfzahl können durch TLS Inspection, Paketgrössen, Sessions und Ost-West-Traffic völlig unterschiedliche Modelle benötigen.

Zuerst harte Ausschlusskriterien prüfen

Bevor man Durchsatzwerte vergleicht, müssen die nicht verhandelbaren Anforderungen passen:

• Formfaktor, Geräusch, Stromversorgung und Umgebung,
• Anzahl, Typ und Geschwindigkeit der festen sowie modularen Ports,
• lokale Speicher- und Reporting-Anforderungen,
• benötigte Funktionen, Abonnements und Supportoptionen,
• dokumentierte Höchstwerte für Sessions, neue Verbindungen und VPN-Tunnel,
• Redundanz von Netzteilen, Interfaces und HA-Knoten.

Ein Modell fällt aus, sobald eines dieser Kriterien nicht genügt – auch wenn sein nomineller Firewall-Durchsatz hoch genug wäre. Die Modellmatrix und Detaildaten ändern sich mit der Produktgeneration; für eine Bestellung sollte deshalb immer das aktuelle offizielle Sophos-Datenblatt verwendet werden.

Appliance-Klassen als Formfaktor verstehen

Desktop-Appliances passen häufig zu kleinen Standorten und Filialen. 1U-Modelle bieten typischerweise mehr Portdichte, Erweiterbarkeit und Leistungsreserve für zentrale oder verteilte Standorte. 2U-Modelle sind für sehr hohe Bandbreite, Session-Last, Redundanz und Enterprise-Umgebungen ausgelegt. Diese Klassen beschreiben jedoch keinen belastbaren Benutzerbereich.

Bei den kleinen Modellen zählt zudem der Funktionsumfang: Laut Sophos-XGS-Appliance-Datenblatt unterstützen die XGS 88 und XGS 88w bestimmte Funktionen wie On-box Reporting, Dual AV Scanning, WAF AV Scanning und den E-Mail-MTA nicht; Sophos empfiehlt die XGS 108 beziehungsweise XGS 108w, wenn diese Funktionen benötigt werden. Das ist ein hartes Auswahlkriterium und lässt sich nicht mit zusätzlicher Durchsatzreserve kompensieren.

Kandidaten mit dem Sizing Tool prüfen

Nachdem ungeeignete Modelle ausgeschlossen sind, vergleicht man die verbleibenden Kandidaten mit dem aktuellen Datenblatt und dem Sophos Firewall Sizing Tool. Das Tool steht Partnern über das Sophos Partner Portal zur Verfügung; Sophos bietet ausserdem Sizing-Unterstützung an. Für die Prüfung werden nicht nur Benutzerzahl und WAN-Bandbreite, sondern das dokumentierte Traffic-Profil, alle Schutzfunktionen, VPN, interne Flüsse, HA und Wachstum übergeben. Das Ergebnis ist eine begründete Vorauswahl, keine Garantie für die Produktivleistung.

Reserve, HA und Wachstum

Eine Firewall sollte nicht dauerhaft nahe am Limit laufen. Reserven sind wichtig für:

• Wachstum der Internetleitung,
• neue Standorte oder VLANs,
• spätere Aktivierung von TLS Inspection oder IPS,
• mehr Remote-Access-Benutzer,
• zusätzliche Logging- und Reporting-Anforderungen,
• Firmware-Updates mit neuen Funktionen,
• Störungssituationen und Failover.

Bei HA muss man besonders sauber planen. In einem Active-Passive-Design muss ein einzelner Node die produktive Last alleine tragen können. Active-Active ist kein Freipass für knappes Sizing, weil nicht jede Last beliebig linear verteilt wird. Die wichtigsten Architekturpunkte stehen in Sophos Firewall HA Cluster Varianten verstehen.

Als Faustregel sollte man bei neuen Projekten nicht auf eine Firewall planen, die im Normalbetrieb bereits dauerhaft sehr hohe CPU-, RAM- oder Session-Auslastung zeigt. Der Artikel Sophos Firewall Performance-Metriken richtig einordnen hilft bei der späteren Betriebsprüfung.

Praktischer Sizing-Ablauf

1. Ausgangslage erfassen

Zuerst wird die Umgebung beschrieben:

• Standorte und WAN-Leitungen,
• Benutzer und Geräte,
• VLANs und interne Zonen,
• Server- und DMZ-Dienste,
• VPN- und Remote-Access-Anforderungen,
• aktiv geplante Security-Module,
• Reporting- und Loganforderungen,
• HA- oder Cloud-Anforderungen.

Bei einem Ersatz oder einer Migration sollte man diese Angaben mit Messwerten der bestehenden Firewall ergänzen. Während repräsentativer Spitzenzeiten öffnet man Control center > System, erweitert die Systemansicht und prüft unter CPU & Memory sowie Network insbesondere CPU, Arbeitsspeicher, Bandbreite, Sessions, Decryption capacity und Decrypt sessions. Ein einzelner ruhiger Zeitpunkt ist keine belastbare Ausgangslage; sinnvoll sind mehrere Messungen an typischen Arbeitstagen und während bekannter Lastspitzen.

2. Kritische Lasttreiber markieren

Danach werden die Punkte markiert, die das Modell nach oben treiben können:

• TLS Inspection breit im Einsatz,
• viele IPS-geschützte Verbindungen,
• hoher VPN-Durchsatz,
• viele gleichzeitige Sessions,
• viele Firewall-Regeln mit Logging,
• WAF oder Mail Protection,
• starke Segmentierung mit internem Traffic über die Firewall,
• Wachstum in den nächsten drei bis fünf Jahren.

3. Harte Anforderungen gegen die Modellmatrix prüfen

Nun werden ungeeignete Modelle ausgeschlossen. Dabei prüft man Portzahl und -geschwindigkeit, Erweiterungsmodule, Formfaktor, Strom- und Redundanzanforderungen, lokale Speicherung sowie alle benötigten Funktionen und dokumentierten Höchstwerte. Auch die Lizenz muss die geplanten Schutzfunktionen abdecken. Diese Prüfung erfolgt vor dem Performancevergleich: Fehlende Ports, eine nicht unterstützte Funktion oder ein zu niedriger Session-Grenzwert lassen sich nicht durch einen guten Durchsatzwert ausgleichen.

4. Datenblattwerte richtig lesen

Datenblattwerte sind maximale Durchsatzwerte, die Sophos unter idealen Testbedingungen mit Keysight-Ixia BreakingPoint ermittelt; sie garantieren keine Produktivleistung. Firewall Throughput wird mit HTTP-Traffic und 512-KB-Antwortgrösse gemessen. Firewall IMIX verwendet UDP-Pakete mit 66, 570 und 1518 Byte. Beim IPS-Test sind der Standard-Regelsatz, HTTP-Traffic und eine Objektgrösse von 512 KB vorgegeben. TLS Inspection wird mit aktivem IPS, HTTPS-Sessions und verschiedenen Cipher Suites gemessen. Threat Protection kombiniert Firewall, IPS, Application Control und Malware Prevention mit dem Enterprise Traffic Mix. Reale Werte hängen von Traffic-Profil, Regeln, Verschlüsselung, Paketgrössen und gleichzeitig aktiven Diensten ab.

Entscheidend ist deshalb die Kennzahl, die dem geplanten Betrieb am nächsten kommt:

Wichtige Kennzahlen:

• Firewall Throughput: nur eine grobe Orientierung für einfachen Paketdurchsatz ohne den vollständigen Security-Mix.
• IPS Throughput: relevant für Umgebungen mit aktivem Intrusion Prevention.
• Threat Protection: meist realistischer, wenn mehrere Schutzfunktionen gleichzeitig aktiv sind.
• TLS Inspection: wichtig für Umgebungen mit entschlüsseltem HTTPS-Traffic.
• IPsec VPN Throughput: relevant für Standortvernetzung und VPN-Last.
• Concurrent Connections: wichtig bei vielen Clients, Websessions und Diensten.

Wenn mehrere dieser Punkte gleichzeitig relevant sind, sollte man nicht nur eine einzelne Kennzahl betrachten.

5. Reserve festlegen

Vor der finalen Modellwahl sollte man nicht einfach einen pauschalen Reservewert addieren, sondern drei Szenarien vergleichen:

• Normaler Peak: höchste realistische Last mit allen geplanten Schutzfunktionen.
• Failover-Peak: dieselbe Last auf einem einzelnen HA-Node und bei Ausfall einer WAN-Verbindung.
• Zukünftiger Peak: erwartete Bandbreite, Sessions und zusätzliche Schutzfunktionen in den nächsten drei bis fünf Jahren.

Ein Modell passt erst dann, wenn die relevanten Datenblattwerte, Ports und Lizenzfunktionen alle drei Szenarien mit nachvollziehbarer Reserve abdecken. Bei einem einfachen Einzelstandort kann diese kleiner sein als bei einer zentralen Firewall, einem HA-Cluster oder starkem Wachstum.

6. Im Control Center validieren

Sizing endet nicht mit der Bestellung. Nach der Inbetriebnahme öffnet man zu repräsentativen Spitzenzeiten Control center > System, erweitert die Systemansicht und vergleicht unter CPU & Memory und Network die verfügbaren Zähler mit den Annahmen:

• CPU- und Arbeitsspeicherauslastung,
• WAN-Bandbreite und Session-Zahlen,
• Decryption capacity und Decrypt sessions bei TLS Inspection,

Mit passenden Messungen und Beobachtungen prüft man zusätzlich:

• VPN-Durchsatz,
• WebAdmin-Reaktionszeit,
• Log Viewer und Reporting,
• Paketverluste oder Retransmits,
• Performance nach Aktivierung zusätzlicher Schutzfunktionen.

Nicht ein einzelner Ausschlag ist entscheidend, sondern eine wiederkehrende oder anhaltende Sättigung. In der erweiterten Systemansicht zeigt die Load-Average-Grafik die letzte Woche. Liegt der Load Average über der Anzahl Prozessorkerne, war mehr Arbeit vorhanden, als das System in diesem Zeitraum verarbeiten konnte. Das ist ein konkretes Signal, das Sizing, die aktivierten Funktionen oder auffälligen Traffic genauer zu prüfen.

Für reproduzierbare Messungen kann Sophos Firewall iPerf Speedtest für Troubleshooting verwenden helfen. Für einfache WAN-Geschwindigkeitstests ist Sophos Firewall Internet Speedtest richtig einordnen der passende Einstieg.

7. Abnahmetest und Rückweg vorbereiten

Vor dem Go-live hält man die Sizing-Annahmen und Erfolgskriterien schriftlich fest. Der Abnahmetest verwendet das vollständige produktive Regelwerk und die geplanten Schutzfunktionen. Geprüft werden normale Spitzenlast, VPN- und Inter-VLAN-Pfade sowie bei HA die Last auf einem einzelnen Node. CPU, Load Average, Arbeitsspeicher, Sessions, Decryption capacity, Paketverlust und die Reaktionszeit wichtiger Anwendungen werden gemeinsam bewertet; ein einzelner Internet-Speedtest reicht nicht.

Bei einem Hardwareersatz bleiben ein aktuelles, geprüftes Backup und ein dokumentierter Rückweg zur bisherigen Verkabelung bis zum bestandenen Test verfügbar. Erfüllt das neue System die Kriterien nicht, deaktiviert man nicht pauschal Schutzfunktionen. Zuerst werden der tatsächlich verwendete Regel- und Routingpfad, Link-Aushandlung, aktive Inspection und bei virtuellen Firewalls die Host-Ressourcen geprüft. Lässt sich die Ursache im Wartungsfenster nicht sicher beheben, wechselt man auf den vorbereiteten alten Pfad zurück und klärt mit Sophos oder dem Partner, ob Konfiguration, Plattform oder Modell angepasst werden muss.

Troubleshooting nach dem Go-live

• Durchsatz liegt unter dem Ziel: Linkgeschwindigkeit und Duplex, den tatsächlich treffenden Firewall-Regelpfad sowie aktive IPS-, Web- und TLS-Inspection prüfen. Danach den Messwert mit der passenden Datenblattkennzahl vergleichen, nicht mit dem reinen Firewall-Maximalwert.
• Load Average ist wiederholt höher als die Zahl der CPU-Kerne: Zeitpunkt und Traffic-Fluss über Control Center, Logs und Current activities eingrenzen. Ein kurzer Peak allein beweist kein falsches Sizing; wiederkehrende Sättigung zusammen mit Paketverlust oder trägen Anwendungen muss untersucht werden.
• Decryption capacity ist ausgeschöpft oder Decrypt sessions nähern sich dem dokumentierten Modelllimit: prüfen, welche Regeln entschlüsseln und ob das reale HTTPS-Profil von der Annahme abweicht. Die Beobachtungen sichern und das Modell beziehungsweise den Inspection-Umfang mit Sophos oder dem Partner neu bewerten, statt die Kontrolle ungeprüft abzuschalten.
• Nur die virtuelle Firewall ist langsam: CPU- und RAM-Zuteilung, Reservierungen, Host-Überbuchung, Storage-Latenz und virtuelle NICs mitprüfen.

Häufige Sizing-Fehler

• Nur nach Benutzerzahl dimensionieren.
• Datenblattwerte für Firewall-Durchsatz mit Threat-Protection-Last verwechseln.
• TLS Inspection später aktivieren, ohne Reserve eingeplant zu haben.
• HA planen, aber nicht prüfen, ob ein Node allein genug Leistung hat.
• Inter-VLAN-Traffic ignorieren.
• Reporting und Logging unterschätzen.
• Virtuelle Firewalls auf überbuchten Hosts betreiben.
• Wachstum der Internetleitung nicht berücksichtigen.
• Remote Access und Site-to-Site VPN nur nach Anzahl Tunnel statt nach Durchsatz planen.

Checkliste

• Internet-Bandbreite und echte Peak-Nutzung bekannt.
• Benutzer, Geräte, VLANs und Serverzonen erfasst.
• Geplante Security-Module dokumentiert.
• Ports, Funktionsumfang, Subscriptions und Plattformlimits geprüft.
• TLS Inspection, IPS, VPN, WAF, Mail Protection und Reporting separat bewertet.
• Interner Traffic über die Firewall berücksichtigt.
• HA-Design und Failover-Last geprüft.
• Hardware oder virtuelle Appliance bewusst entschieden.
• Wachstumsreserve für mehrere Jahre eingeplant.
• Nach der Inbetriebnahme Performance-Metriken geprüft.
• Abnahmekriterien, Backup und Rückweg dokumentiert.

FAQ