Sophos Firewall Leistungsdaten richtig interpretieren

Die Leistungsdaten einer Sophos Firewall sind wichtig für das Sizing, werden aber oft falsch gelesen. Der höchste Firewall-Durchsatz im Datenblatt ist nicht automatisch die Leistung, die ein Standort mit IPS, Web Protection, TLS Inspection, VPN, NAT, Reporting und vielen gleichzeitigen Benutzern erreicht.

Für die Auswahl eines Modells sollte man deshalb nicht nur auf eine einzelne Gbit/s-Zahl schauen. Entscheidend ist, welche Schutzfunktionen aktiv sind, welcher Traffic durch die Firewall fliesst und welche Reserven die Umgebung im Alltag braucht. Der Sophos Firewall Sizing Guide erklärt die Modellwahl; dieser Artikel erklärt, wie man die zugrunde liegenden Performance-Metriken einordnet.

Kurzregel für das Sizing

Für die Praxis ist meist nicht der reine Firewall-Durchsatz der beste Startwert.

• Nur Routing und einfache Firewall-Regeln: Firewall-Durchsatz und IMIX beachten.
• Normales Unternehmensnetz mit IPS und Application Control: NGFW- oder Threat-Protection-Werte stärker gewichten.
• Viele HTTPS-Verbindungen mit Entschlüsselung: TLS-Inspection-Leistung und CPU-Reserve einplanen.
• Viele VPN-Verbindungen: IPsec- oder Remote-Access-Anforderungen separat betrachten.
• Virtuelle Firewall: Hypervisor, CPU, RAM, Storage und virtuelle Netzwerkkarten genauso ernst nehmen wie die Sophos Lizenz.

Wenn unklar ist, ob Hardware oder virtuelle Appliance besser passt, hilft Sophos Firewall - Hardware oder virtuelle Appliance? als Entscheidungshilfe.

Warum Datenblattwerte nicht eins zu eins reichen

Performance-Werte werden unter definierten Laborbedingungen ermittelt. Das ist sinnvoll, weil Modelle so vergleichbar werden. Eine produktive Umgebung verhält sich aber anders:

• Paketgrössen sind gemischt.
• Benutzer erzeugen parallele Sessions.
• Security-Profile prüfen Traffic unterschiedlich tief.
• HTTPS-Traffic benötigt bei TLS Inspection deutlich mehr Ressourcen.
• VPN, SD-WAN, NAT, Logging und Reporting laufen parallel.
• WLAN, Switches, Clients, Server und Provider beeinflussen die gefühlte Performance.

Ein Datenblattwert ist deshalb ein Vergleichswert, kein Versprechen für jeden einzelnen Flow. Für ein solides Sizing sollte man mit Reserven planen und die späteren Betriebsfunktionen nicht erst nach dem Kauf berücksichtigen.

Die wichtigsten Metriken

• Firewall-Durchsatz: Hilft beim Vergleich bei einfachem Layer-3/Layer-4-Verkehr. Häufige Fehlinterpretation: Der Wert wird als realer Internetdurchsatz mit allen Security-Funktionen gelesen.
• Firewall IMIX: Ist eine realistischere Mischung verschiedener Paketgrössen. Diese Metrik wird oft ignoriert, obwohl echte Netze selten nur grosse Pakete haben.
• IPS-Durchsatz: Beschreibt Verkehr mit Intrusion Prevention. Der Wert wird unterschätzt, wenn IPS später für viele Regeln aktiv ist.
• NGFW-Durchsatz: Beschreibt Firewall-Leistung mit zusätzlichen Next-Generation-Funktionen wie IPS und Application Control. Er sollte nicht mit reinem Firewall-Durchsatz verwechselt werden.
• Threat Protection: Ist ein stärkerer Näherungswert für aktivierte Schutzfunktionen. Wichtig: Das ist eine Vergleichsmetrik, kein fester Mindestwert für jede Umgebung.
• TLS Inspection: Betrifft HTTPS-Entschlüsselung und Prüfung. Diese Leistung wird im Sizing oft vergessen, obwohl sie sehr ressourcenintensiv sein kann.
• IPsec VPN: Betrifft Standortvernetzung und verschlüsselte Tunnel. Hier zählen nicht nur Internetleitung, sondern auch Gegenstelle, Paketgrössen und CPU.
• Sessions und Connections per second: Relevant bei vielen Benutzern, Webtraffic, Serverpublishing und kurzen Verbindungen. Dieser Wert wird selten geprüft, kann aber bei vielen Clients oder veröffentlichten Diensten wichtig sein.

Firewall-Durchsatz und IMIX

Der reine Firewall-Durchsatz beschreibt eine vergleichsweise einfache Verarbeitung von Traffic. Dieser Wert ist nützlich, wenn eine Firewall vor allem routet, NAT macht und klassische Firewall-Regeln verarbeitet.

IMIX ist näher an echter Netzwerklast, weil unterschiedliche Paketgrössen gemischt werden. Das ist wichtig, weil kleine Pakete eine Firewall anders belasten als grosse Downloads. In Unternehmensnetzen gibt es selten nur einen sauberen grossen Datenstrom. Webzugriffe, DNS, VoIP, Cloud-Anwendungen, Updates und Dateiübertragungen erzeugen unterschiedliche Muster.

Für Standorte mit normalem Benutzertraffic ist IMIX deshalb oft aussagekräftiger als der schönste Maximalwert.

IPS, NGFW und Threat Protection

Sobald IPS, Application Control, Web Protection oder Malware-Prüfung aktiv sind, muss die Firewall mehr tun als Pakete weiterleiten. Die Firewall muss Traffic klassifizieren, Muster erkennen, Regeln anwenden und je nach Policy Inhalte prüfen.

Die Begriffe werden häufig vermischt:

• IPS bewertet Traffic anhand von Signaturen und Regeln für bekannte Angriffsmuster.
• NGFW beschreibt Firewall-Leistung mit zusätzlichen Funktionen wie IPS und Application Control.
• Threat Protection ist ein stärkerer Näherungswert für Umgebungen, in denen mehrere Schutzfunktionen gleichzeitig aktiv sind.

Für ein Unternehmen, das die Sophos Firewall tatsächlich als Security Gateway betreibt, sind NGFW- und Threat-Protection-Werte meist relevanter als der reine Firewall-Durchsatz.

TLS Inspection realistisch planen

TLS Inspection ist einer der grössten Performance-Faktoren. Die Firewall entschlüsselt HTTPS-Verbindungen, prüft den Inhalt und verschlüsselt die Verbindung wieder. Das erzeugt CPU-Last und kann je nach Cipher Suite, Zielserver, Client, Ausnahmen und Policy deutlich spürbar sein.

TLS Inspection sollte deshalb nicht nebenbei aktiviert werden. Sinnvoll ist ein schrittweiser Rollout mit Pilotgruppe, Ausnahmen, Monitoring und klarer Fehlersuche. Der Artikel Sophos Firewall TLS Inspection richtig einführen beschreibt den operativen Ablauf.

Auch das CA-Zertifikat muss sauber verteilt werden. Für Clients ist Sophos Firewall CA Zertifikat für HTTPS Scanning installieren der passende Einstieg.

VPN-Leistung getrennt betrachten

VPN-Performance hängt nicht nur vom Firewall-Modell ab. Relevant sind auch Gegenstelle, Internetleitung, Latenz, Paketgrössen, MTU/MSS, Verschlüsselungsparameter, Routing und parallele Tunnel.

Für Site-to-Site-Verbindungen sollte man die geplanten Datenströme realistisch schätzen: Dateiübertragungen, Backups, ERP, VoIP, RDP, Monitoring und Replikation verhalten sich unterschiedlich. Für Remote Access kommen zusätzlich Clientgerät, WLAN, Provider und VPN-Client hinzu.

Wenn eine VPN-Strecke langsam wirkt, sollte man nicht nur den Datenblattwert prüfen. Ein definierter Streckentest mit iPerf ist meistens aussagekräftiger als ein Browser-Speedtest.

Was die reale Performance beeinflusst

In der Praxis wirken mehrere Faktoren gleichzeitig:

• aktive Security-Profile pro Firewall-Regel
• TLS Inspection und Ausnahmen
• IPS-Policy und Signaturumfang
• Web Protection, Application Control und Malware-Prüfung
• NAT, DNAT, Serverpublishing und WAF
• IPsec, SSL VPN, Sophos Connect und Site-to-Site-Tunnel
• Logging, Reporting, Central Reporting und Syslog
• viele kleine Sessions statt weniger grosser Downloads
• Firewall Acceleration, FastPath, IPsec Acceleration und Traffic, der nicht offloaded werden kann
• HA-Betrieb, Firmwarestand und Hotfixes
• virtuelle Ressourcen bei Software- oder Cloud-Appliances

Deshalb sollte man Performance immer im Kontext der konkreten Policy prüfen. Eine Firewall-Regel ohne Security-Profile verhält sich anders als eine Regel mit IPS, Webfilter, Application Control und TLS Inspection.

FastPath und Offloading richtig einordnen

Moderne Sophos Firewalls verarbeiten nicht jeden Datenstrom gleich. Je nach Appliance, Firmware, Regel, Security-Profil und Traffic-Art kann Traffic teilweise beschleunigt oder in einem langsameren Verarbeitungspfad geprüft werden. Wichtige Begriffe dafür sind FastPath, Firewall acceleration, PKI acceleration und IPsec acceleration.

Die erste Einordnung erfolgt weiterhin im SlowPath: Kernel und gegebenenfalls DPI Engine prüfen die Verbindung. Nach abgeschlossenem TCP-Handshake oder je einem Paket pro Richtung kann SFOS einen geeigneten Flow in den FastPath-Connection-Cache übernehmen. FastPath ist damit kein ungeprüfter Bypass; er verarbeitet nur den Zustand, den der Kernel vorgibt. Nicht geeignete Protokolle wie IP-in-IP bleiben im SlowPath.

Für das Sizing ist das wichtig, weil ein schneller Test nicht beweist, dass jeder produktive Datenstrom denselben Pfad nutzt. Sophos führt Firewall und IPsec Acceleration für alle XGS-Appliances auf. Dedizierte PKI Acceleration für die Zertifikatsverarbeitung geprüfter TLS-Flows ist dagegen nur für XGS 4300, 4500, 5500, 6500, 7500 und 8500 dokumentiert. Die Gen.-2-Desktop-Modelle XGS 88/88w, 108/108w, 118/118w und 128/128w verwenden Virtual FastPath im x86-Kernel statt eines dedizierten Xstream Flow Processors.

Bei virtuellen und Software-Appliances ist die Grenze noch enger. Virtual FastPath wird laut SFOS-22-Hilfe nur mit VMware ESXi und den NIC-Treibern igc, e1000, e1000e und vmxnet3 unterstützt. Auf anderen Hypervisoren, in Cloud-Deployments oder mit nicht unterstützten Treibern wird VFP automatisch ausgeschaltet; die Firewall funktioniert weiter, aber ohne diese FastPath-Verbesserung. Für e1000 und e1000e nennt Sophos maximal 3500 Byte MTU, für die übrigen unterstützten Treiber maximal 9000 Byte. Diese Werte sind Plattformgrenzen und keine Aufforderung, Jumbo Frames ohne Ende-zu-Ende-Test zu aktivieren.

PKI Acceleration beschleunigt nicht die gesamte TLS-Verarbeitung. Sie lagert bei durch die DPI Engine geprüften TLS-1.2- und TLS-1.3-Flows nur das erneute Signieren von X.509-Serverzertifikaten mit RSA-Authentisierung bis 4096 Bit aus. Symmetrische Verschlüsselung, Web-Proxy-Traffic und auf der Firewall terminierte SSL-VPN-Verbindungen profitieren davon nicht.

Bestimmte Funktionen oder Traffic-Arten können Offloading einschränken oder verhindern, zum Beispiel:

• SSL VPN
• WAF und Proxy-Verkehr
• QoS und DoS
• Wireless, RED, LAG und PPPoE
• fragmentierter IP-Traffic
• bestimmte Bridge-, HA- oder Virtualisierungs-Szenarien

Bei IPsec lagert der XFRM-Stack ESP-Kapselung, Verschlüsselung, Entkapselung und Entschlüsselung anhand der Phase-2-SA aus. SAs mit 3DES, BlowFish oder MD5, SAs auf virtuellen Interfaces wie VLANs sowie IPsec-Traffic über VLAN- oder Wireless-Interfaces werden nicht offloaded. Der Tunnel kann trotzdem funktionieren, benötigt dann aber mehr Host-CPU.

Security-Policies schliessen Offloading nicht pauschal aus. Eine Regel ohne IPS, Webfilter, Antivirus oder Application Control kann nach dem Handshake oder den ersten Paketen wechseln; mit Application Control erfolgt die Entscheidung laut Sophos nach ungefähr acht Paketen. Bei STARTTLS mit Don’t decrypt sind es etwa 15 Pakete. Die ersten Pakete können deshalb noch im SlowPath sichtbar sein, obwohl der spätere Flow beschleunigt wird.

Praxisregel: Offloading ist kein Sicherheitsziel. Schutzprofile und Inspection werden nicht entfernt, nur um FastPath zu erreichen. Entscheidend sind der benötigte Schutz sowie reproduzierbare Messwerte für Durchsatz, CPU und Anwendung.

Bei HA muss man besonders genau hinschauen. Active-Active-HA unterstützt keine Firewall Acceleration. In Active-Passive-HA nutzen Firewall und IPsec Acceleration nur der primäre Node. Ein Sizing für HA sollte deshalb nicht einfach Standalone-Laborwerte auf beide Nodes hochrechnen.

Auch die Fehlersuche kann Messwerte beeinflussen. Bei Packet Capture oder iftop leitet SFOS den Traffic standardmässig vorübergehend über SlowPath. Bleibt Offloading während der Aufnahme aktiv, kann ein normaler Packet Capture FastPath-Traffic dagegen nicht erfassen. Ein fehlendes Paket im Capture beweist deshalb nicht, dass die Firewall den Flow nicht verarbeitet hat; für eine FastPath-Aufnahme verweist Sophos an Support. Performance-Messungen und Capture-Ergebnisse werden immer mit Zeitpunkt, Testmethode, Firmwarestand, Interface-Typ und aktiver Policy dokumentiert.

Die Beschleunigungen sind auf unterstützten Plattformen standardmässig aktiv. Das Umschalten von Firewall oder PKI Acceleration startet IPS beziehungsweise die DPI Engine neu; das Umschalten von IPsec Acceleration startet alle IPsec-Tunnel neu. Solche Änderungen gehören in ein Wartungsfenster und nicht in einen spontanen Performance-Test. Zuerst wird mit Log Viewer, Packet Capture, IPsec Troubleshooting und einem klaren Testfall geprüft, ob der Verdacht wirklich passt.

PKI Acceleration richtig lesen und steuern

Der konfigurierte und der wirksame Zustand sind nicht dasselbe. Gelesen wird die Einstellung mit:

show ips-settings

Auf unterstützten XGS-Modellen ist PKI Acceleration standardmässig aktiviert. enabled ist nur dann wirksam, wenn auch Firewall Acceleration läuft. Ist PKI Acceleration eingeschaltet, Firewall Acceleration aber ausgeschaltet, meldet SFOS enabled (inactive). Auf nicht unterstützten SFOS-Versionen oder Modellen erscheint sie als disabled; ein CLI-Wechsel kann fehlende Hardware- oder Plattformunterstützung nicht ersetzen.

Die globale Einstellung wird über den IPS-Befehlsbaum geändert:

set ips pki-acceleration disable
set ips pki-acceleration enable

Das Umschalten startet IPS beziehungsweise die DPI Engine neu und gehört deshalb in ein Wartungsfenster. Vorher werden der aktuelle Wert und Firewall-Acceleration-Status festgehalten. Danach folgen erneut show ips-settings, der Status von IPS und DPI sowie ein realer, durch die DPI Engine entschlüsselter TLS-Flow. Nur so lässt sich prüfen, ob Zertifikats-Neusignierung, Latenz, CPU und Anwendung weiterhin stimmen. Bleibt der erwartete Effekt aus, wird der zuvor dokumentierte Wert wiederhergestellt.

IPsec Acceleration kontrolliert prüfen

Der globale Status wird zuerst nur gelesen:

system ipsec-acceleration show

IPsec Acceleration ist standardmässig enabled und lagert geeignete Phase-2-SAs aus dem SlowPath aus. Ein aktivierter globaler Status beweist jedoch nicht, dass eine bestimmte SA offloaded wird. 3DES, BlowFish und MD5 sind ausgeschlossen; auch die weiter oben beschriebenen Interface- und Plattformgrenzen bleiben bestehen.

Ein Wechsel gilt für die gesamte Firewall und startet alle IPsec-Tunnel neu. disable ist deshalb kein Test für einen einzelnen Tunnel. Falls ein klarer Fehlerfall einen A/B-Test rechtfertigt, werden vorher Tunnelstatus, SAs, CPU, Durchsatz und Testtraffic dokumentiert. Im Wartungsfenster stehen diese beiden Gegenrichtungen zur Verfügung:

system ipsec-acceleration disable
system ipsec-acceleration enable

Nach jedem tatsächlich ausgeführten Wechsel folgen erneut show, Tunnelaufbau, Phase-2-SAs, Routing, Firewall-Regeln und echter Traffic in beiden Richtungen. Ohne reproduzierbare Verbesserung wird der ursprüngliche Wert wiederhergestellt. Ein veraltetes Kryptoprofil wird nicht beibehalten, nur damit ein Performancevergleich möglich bleibt.

Firewall Acceleration nur im Wartungsfenster umschalten

Der aktuelle Zustand wird in der Device Console zuerst nur gelesen:

system firewall-acceleration show

Auf unterstützten Plattformen ist Firewall Acceleration standardmässig enable. Jede Änderung verursacht laut Sophos einen Ausfall und startet IPS beziehungsweise die DPI Engine neu. disable ist deshalb kein beiläufiger A/B-Test während des Betriebs. Die Firewall verarbeitet Traffic weiterhin vollständig, aber ohne die Performance-Vorteile von FastPath.

Für eine geplante Änderung stehen diese beiden Befehle zur Verfügung. Sie werden nicht direkt nacheinander als Testblock ausgeführt, weil jeder Wechsel erneut unterbrechen kann:

system firewall-acceleration disable
system firewall-acceleration enable

Nach jedem tatsächlich benötigten Wechsel folgen erneut show, IPS- und DPI-Status, neue Sessions, veröffentlichte Dienste, VPN, Durchsatz, CPU und Log Viewer. Ein angezeigtes disabled wird nicht blind mit enable überschrieben: DoS, Active-Active-HA, ein nicht geladener FastPath sowie eine nicht unterstützte VM-, Hypervisor- oder NIC-Treiber-Kombination können die Beschleunigung ebenfalls verhindern. enable erzwingt auf einer technisch nicht unterstützten Plattform keinen funktionierenden FastPath.

Performance im Betrieb prüfen

Datenblattwerte helfen vor dem Kauf. Im Betrieb braucht man andere Werkzeuge. Wichtig ist dabei die Begriffstrennung: Das Control Center zeigt keine Datenblattperformance, sondern aktuelle Betriebsindikatoren. Die Performance-Kachel basiert auf dem Load Average über CPU-Kerne. Werte über der Anzahl verfügbarer Kerne bedeuten, dass mehr Arbeit anliegt, als das System zu diesem Zeitpunkt abarbeiten kann.

Die Farbe der Kachel folgt festen Sophos-Schwellen: Normal bei einem Load Average unter 2, Warning von 2 bis 5 und Alert über 5 CPU-Kernen. Diese Ampel ist ein schneller Hinweis, aber nicht identisch mit der individuellen Überlastungsgrenze der Appliance. Für die Einordnung werden deshalb Kachelstatus, tatsächliche Core-Anzahl und zeitlicher Verlauf gemeinsam gelesen.

Zusätzlich sind CPU, Memory, Bandwidth, Sessions, Decryption Capacity und Decrypt Sessions relevant. Besonders bei TLS Inspection ist Decryption Capacity hilfreich, weil sie zeigt, wie stark die aktuelle SSL/TLS-Entschlüsselung die verfügbare Entschlüsselungsleistung belegt. Decryption-Details werden nicht als sekundengenaue Live-Messung aktualisiert, sondern typischerweise alle fünf Minuten. Diese Werte sollten immer zusammen mit Policy, Regel, Security-Profil, Uhrzeit und Traffic-Art gelesen werden.

System Graphs als Zeitlinie verwenden

Unter Diagnostics > System graphs lassen sich CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone und einzelne Interfaces für verschiedene Zeiträume vergleichen. Zuerst wählt man den Zeitraum des Vorfalls und danach nur die Graphen, die zur betroffenen Funktion passen.

Ein Peak ist eine Korrelation, noch keine Ursache. CPU, Memory oder Load Average sollten deshalb mit Interface-Traffic, Benutzerzahl, Logs, Policy und dem exakten Testzeitpunkt abgeglichen werden. Der Verlauf hilft besonders dabei, einen kurzen Ausreisser von einer wiederkehrenden oder dauerhaft hohen Last zu unterscheiden; er beweist allein weder eine zu kleine Appliance noch einen bestimmten fehlerhaften Dienst.

Einheiten und Verdichtung richtig lesen

Der CPU-Graph trennt die Auslastung durch Benutzerprozesse, Systemkomponenten und die verbleibende Idle-Zeit. Memory zeigt Used, Free und Total in MB. Der Load Average ist dagegen kein Prozentwert: Die drei Kurven stehen für den Durchschnitt über eine, fünf und fünfzehn Minuten. Er wird deshalb zusammen mit der Anzahl verfügbarer CPU-Kerne gelesen.

Disk Usage zeigt prozentual, wie viel Platz Signaturen, Konfigurationsdateien, Reports und temporäre Daten belegen. Das ist eine funktionale Aufteilung im Graphen und nicht dieselbe Ansicht wie die Partitionen aus df -kh oder der Report-Watermark. Live Users zählt die Benutzer, die im gewählten Zeitraum mit dem Internet verbunden waren, und zeigt zusätzlich Minimum, Maximum und Durchschnitt. Der Wert ist keine Anzahl angelegter Benutzerkonten.

Für die WAN-Zone gibt es getrennte Graphen für Upload und Download, die kombinierte Gesamtrate sowie die Rate pro Gateway. Je nach Ansicht erscheinen aktueller, minimaler, maximaler und durchschnittlicher Wert. Sophos weist auf einen wichtigen Beschriftungsfehler hin: WebAdmin zeigt KBps, die Werte sind jedoch tatsächlich kbit/s. Wer die Anzeige als Kilobyte pro Sekunde liest, liegt um den Faktor acht daneben.

Wichtig bei VLANs: Separate Interface-Graphen gibt es für physische Interfaces, Wireless LAN, WAN-Interfaces und VLAN-Interfaces in der WAN-Zone. VLANs in anderen Zonen werden im Graphen mit dem physischen Parent-Interface zusammengefasst. Ein Peak auf dem Parent-Port lässt sich deshalb nicht ohne weitere Messung einem einzelnen internen VLAN zuordnen.

Die Interface-Graphen zeigen empfangene und gesendete Bits sowie Drops, Fehler und Kollisionen. Die Auflösung wird für längere Zeiträume verdichtet: Heute und gestern basieren auf Fünf-Minuten-Mittelwerten, die Woche auf 15 Minuten, der Monat auf sechs Stunden und das Jahr auf einem Tag. Kurze Peaks können in einer Monats- oder Jahresansicht daher verschwinden; für einen Vorfall wird zuerst der engste passende Zeitraum gewählt.

Praktischer Ablauf:

1. Control Center prüfen: CPU, RAM, Interface-Auslastung und Warnungen beobachten.
2. Log Viewer öffnen: Greift die erwartete Firewall-Regel und ist Logging aktiviert?
3. Policy und Security-Profile kontrollieren: Welche Funktionen wirken auf den betroffenen Traffic?
4. Packet Capture verwenden: Sieht man Pakete, Antwortpakete, NAT und Drops?
5. Streckentest durchführen: Mit iPerf oder einem definierten Download prüfen, welcher Pfad wirklich langsam ist.
6. Offloading-Kontext notieren: Interface-Typ, HA-Modus, VPN-Art, PPPoE, WAF, SSL VPN oder Packet Capture können die Messung beeinflussen.
7. Zeitpunkt notieren: Lastspitzen, Backups, Updates oder Reports können Ergebnisse verfälschen.

Für eine schnelle Abgrenzung der WAN-Leitung hilft Sophos Firewall Internet-Speedtest per SSH durchführen. Für End-to-End-Tests zwischen zwei Systemen ist Sophos Firewall Performance mit iPerf testen besser geeignet. Wenn eine Regel nicht wie erwartet greift, passt Sophos Firewall-Regeln gezielt testen.

Wie Control Center, System graphs, Reports und Admin-Ereignisse in einem kurzen wiederkehrenden Ablauf zusammengeführt werden, zeigt die tägliche Sophos Firewall Admin-Checkliste.

Typische Sizing-Fehler

• Es wird nur der höchste Firewall-Durchsatz verglichen.
• TLS Inspection wird geplant, aber nicht in die Leistungsreserve eingerechnet.
• VPN und Remote Access werden anhand der Benutzerzahl statt anhand der realen Nutzung bewertet.
• Die Internetleitung wird berücksichtigt, interner Ost-West-Traffic aber nicht.
• Virtuelle Firewalls werden auf überlasteten Hosts betrieben.
• Reporting, Logging und Central-Anbindung werden erst nachträglich betrachtet.
• Wachstum, neue Standorte, zusätzliche VLANs oder Serverpublishing fehlen in der Planung.
• Es wird kein Unterschied zwischen Laborwert, Realwert und Benutzererfahrung gemacht.

Praktische Sizing-Checkliste

Vor der Modellwahl sollten diese Punkte geklärt sein:

1. Internetbandbreite heute und geplant in den nächsten Jahren.
2. Anzahl Benutzer, Geräte, Server und Standorte.
3. Anteil von Webtraffic, Cloud-Anwendungen, VoIP, Backups und Dateiübertragungen.
4. Geplante Security-Funktionen pro Traffic-Gruppe.
5. TLS-Inspection-Umfang und notwendige Ausnahmen.
6. Anzahl und Nutzung von IPsec-, SSL-VPN- und Sophos-Connect-Verbindungen.
7. Bedarf für WAF, Mail Protection, RED, WLAN oder Central Reporting.
8. Erwartete Reserven für Updates, Wachstum und Lastspitzen.
9. Betriebsmodell: XGS Hardware, virtuelle Appliance, Cloud oder HA-Cluster.

FAQ