Sophos Firewall Internet-Speedtest per SSH durchführen

Ein Internet-Speedtest im Browser zeigt nicht immer, was die Internetleitung wirklich leisten kann. Browser, Client, WLAN, Proxy, IPS, Webfilter, TLS Inspection, VPN, NAT und Firewall-Regeln können das Ergebnis beeinflussen. Manchmal ist deshalb ein Test direkt auf der Sophos Firewall hilfreich, um die WAN-Anbindung der Firewall von Client- oder Regelproblemen abzugrenzen.

Der Artikel beschreibt einen einfachen Download-Test per SSH auf der Sophos Firewall, die richtige Einordnung des Ergebnisses und die Grenzen gegenüber iPerf, Log Viewer oder Packet Capture. Besonders wichtig ist die Abgrenzung bei mehreren WAN-Anschlüssen: Der Test misst firewall-eigenen Download-Traffic, nicht automatisch denselben Pfad wie ein Client hinter der Firewall.

Welcher Performance-Test passt?

Ein Download direkt auf der Firewall ist nur ein Werkzeug. Je nach Fragestellung ist ein anderer Test aussagekräftiger:

• WAN-Download direkt auf der Firewall prüfen: Dieser Artikel ist der passende Einstieg.
• Durchsatz zwischen zwei definierten Netzen messen: Dafür ist iPerf hinter Sophos Firewall richtig einsetzen aussagekräftiger.
• Datenblattwerte und reale Security-Performance einordnen: Dafür passt Leistungsdaten der Sophos Firewall richtig verstehen.
• Prüfen, welche Firewall-Regel oder Policy greift: Dafür hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.
• Einzelne Pakete, NAT oder Rückweg analysieren: Dafür ist Packet Capture auf Sophos Firewall gezielt nutzen besser.
• VPN ist langsam oder instabil: Dann sollte man MTU und MSS bei Sophos Firewall VPN-Problemen prüfen.
• Traffic-Muster und Volumenspitzen über Interfaces sehen: Dafür passt sFlow Monitoring auf Sophos Firewall konfigurieren.

Diese Trennung verhindert Fehlinterpretationen. Ein schneller Firewall-Download beweist nicht, dass ein Clientpfad, eine VPN-Strecke oder eine TLS-Inspection-Regel ebenfalls schnell sein muss.

Was ein Speedtest auf der Firewall beweist

Ein Speedtest direkt auf der Firewall beantwortet eine konkrete Frage: Kann die Firewall selbst über ihren aktuellen Routingpfad eine Datei mit erwartbarer Geschwindigkeit aus dem Internet laden?

Das ist hilfreich, wenn man wissen möchte:

• ob die WAN-Leitung grundsätzlich schnell genug ist
• ob der Provideranschluss ungefähr die erwartete Downloadrate liefert
• ob ein Problem eher vor oder hinter der Firewall liegt
• ob Client, WLAN, Switch, Webfilter, TLS Inspection oder VPN in die Analyse einbezogen werden müssen

Der Test beweist aber nicht automatisch, dass Clients hinter der Firewall dieselbe Geschwindigkeit erreichen müssen. Clienttraffic läuft durch Firewall-Regeln, NAT, Security-Policies und je nach Konfiguration durch IPS, Web Protection, Application Control oder TLS Inspection. Der lokale Download auf der Firewall umgeht Teile dieser Verarbeitung und eignet sich deshalb als Abgrenzung, nicht als vollständiger End-to-End-Test.

Für die Einordnung von Datenblattwerten, Security-Features und realer Performance passt ergänzend Leistungsdaten der Sophos Firewall richtig verstehen.

Mehrere WAN-Anschlüsse und SD-WAN beachten

Bei Firewalls mit mehreren WAN-Links sollte man vor dem Test klären, über welchen Pfad die Firewall selbst ins Internet geht. Der Download wird von der Sophos Firewall erzeugt. Er ist damit systemeigener Traffic und folgt nicht zwingend derselben Entscheidung wie ein Clientflow, der durch eine Firewall-Regel, NAT-Regel oder SD-WAN-Route verarbeitet wird.

Typische Fehlannahmen:

• Mehrere WAN-Gateways: Der Firewall-Download kann über ein anderes Gateway laufen als der betroffene Clienttraffic.
• SD-WAN-Routing für Clients: Client-SD-WAN-Regeln beweisen nicht automatisch den Pfad für firewall-eigenen Traffic.
• Failover oder Backup-WAN aktiv: Der Test misst eventuell gerade den Ausweichpfad.
• Policy-based Routing oder spezielles NAT: Ein Clientpfad kann anders behandelt werden als der lokale Firewall-Download.

Bei solchen Setups sollte man das Ergebnis immer mit Uhrzeit, aktivem WAN-Link und beobachtetem Gateway dokumentieren. Wenn systemeigener Traffic, Antwortpakete oder SD-WAN-Entscheidungen unklar sind, passt ergänzend Sophos Firewall SD-WAN Routing, Reply Packet und System Traffic verstehen.

Voraussetzungen

Vor dem Test sollten diese Punkte erfüllt sein:

• SSH oder Advanced Shell Zugriff ist bewusst erlaubt, am besten nur aus einem vertrauenswürdigen Admin-Netz.
• Die Firewall hat Internetzugriff und DNS funktioniert.
• Es gibt ein Wartungsfenster oder mindestens einen unkritischen Zeitpunkt.
• Es ist klar, über welches WAN-Interface die Firewall den Download ausführt.
• Genügend freier Speicherplatz für die Testdatei ist vorhanden.
• Die Testdatei wird nach dem Test wieder gelöscht.

Für den sicheren SSH-Zugriff passt Sophos Firewall per SSH verbinden. SSH wird in SFOS unter Administration > Device access über die Local service ACL oder gezielter über eine Local service ACL exception rule freigegeben. SSH sollte nicht breit aus WAN- oder WLAN-Zonen erlaubt werden und nach Troubleshooting-Aufgaben wieder auf das notwendige Minimum begrenzt sein. Inaktive SSH-Sitzungen werden von Sophos Firewall nach 15 Minuten geschlossen.

⚠️ Ein Download-Test erzeugt echten Traffic und kann die Leitung kurzfristig auslasten. Auf produktiven Firewalls sollte man solche Tests nicht während kritischer Arbeitszeiten oder parallel zu Backup-, VoIP- oder Wartungsfenstern ausführen.

Vor dem Download DNS und Routing prüfen

Bevor man eine grosse Testdatei lädt, sollte man kurz prüfen, ob Namensauflösung und Erreichbarkeit grundsätzlich funktionieren. Sonst verwechselt man schnell DNS-, Routing- oder Providerprobleme mit einem Speedtest-Ergebnis.

Im CLI-Hauptmenü zuerst 4 Device Console öffnen und einfache Checks ausführen:

dnslookup www.avanet.io
ping www.avanet.io
traceroute www.avanet.io

dnslookup prüft die Namensauflösung, ping liefert einen schnellen Erreichbarkeitstest und traceroute zeigt den groben Pfad zum Ziel. Sophos unterstützt in der Device Console bei ping zusätzliche Parameter wie interface oder sourceip. Das ist bei mehreren WAN-Anschlüssen hilfreich, wenn man eine bestimmte Quelle oder ein bestimmtes Interface prüfen möchte.

Wenn DNS bereits fehlschlägt, ist der anschliessende curl-Test nicht aussagekräftig. Dann zuerst DNS, Default Route, WAN-Gateway, SD-WAN-Entscheidung oder Providerverfügbarkeit prüfen.

Speedtest per SSH durchführen

Auf der Sophos Firewall per SSH als admin anmelden. Im CLI-Hauptmenü 5 Device Management auswählen und anschliessend 3 Advanced Shell öffnen. Die Advanced Shell ist eine Linux-Shell mit tiefem Zugriff auf Systemkomponenten. Für diesen Artikel wird sie nur verwendet, um eine Datei nach /tmp zu laden und danach wieder zu löschen.

Danach die Testdatei in ein temporäres Verzeichnis laden, damit sie nicht versehentlich in einem unpassenden Arbeitsverzeichnis liegen bleibt.

cd /tmp
curl -L -o 1GB.bin https://www.avanet.io/1GB.bin

Der Testserver steht in der Schweiz und ist für eine grobe Leitungsmessung gedacht. Für kleinere Tests kann statt 1GB.bin auch 100MB.bin verwendet werden:

cd /tmp
curl -L -o 100MB.bin https://www.avanet.io/100MB.bin

Wenn DNS nicht funktioniert, schlägt der Test bereits bei der Namensauflösung fehl. Dann sollte nicht die Leitungsgeschwindigkeit analysiert werden, sondern zuerst DNS, Routing und WAN-Verfügbarkeit.

Bei Firewalls mit mehreren WAN-Links sollte der Test nicht isoliert betrachtet werden. Parallel sollte man im WebAdmin prüfen, welcher WAN-Link aktiv ist und ob gerade ein Failover, eine SD-WAN-Änderung oder eine Providerstörung vorliegt.

Testdatei wieder löschen

Nach dem Test sollte die Datei wieder entfernt werden:

rm /tmp/1GB.bin

Bei einem Test mit der kleineren Datei:

rm /tmp/100MB.bin

Wenn der Test abgebrochen wurde, trotzdem prüfen, ob eine teilweise heruntergeladene Datei vorhanden ist:

ls -lh /tmp/*GB.bin

Grosse Testdateien sollten nicht auf der Firewall liegen bleiben. Gerade bei kleinen Appliances oder bereits gefüllten Partitionen kann unnötiger Speicherverbrauch später zu schwer nachvollziehbaren Problemen führen.

Speedtest auswerten

Während und nach dem Download zeigt curl unter anderem die durchschnittliche Downloadrate. Im Beispiel liegt der Wert bei rund 107 MB/s.

Wichtig ist die Einheit:

• MB/s bedeutet Megabyte pro Sekunde.
• Mbit/s oder Mbps bedeutet Megabit pro Sekunde.
• 1 Byte entspricht 8 Bit.

Als grobe Umrechnung gilt:

MB/s x 8 = Mbit/s

107 MB/s entsprechen also ungefähr 856 Mbit/s. Overhead, TCP-Verhalten, Gegenstelle, Routing und Auslastung können den Wert beeinflussen. Deshalb sollte man nicht eine einzelne Messung als endgültigen Beweis verwenden.

Sinnvoll sind mehrere Tests zu unterschiedlichen Tageszeiten. Wenn die Werte stark schwanken, sollte man Provider, WAN-Link, SD-WAN-Routing, Interface-Fehler und Auslastung prüfen.

Für Support oder interne Dokumentation sollte man nicht nur die Zahl notieren. Ein kurzer Messdatensatz hilft später deutlich:

• Zeitpunkt: zum Beispiel 2026-06-21 10:15.
• Firewall und Firmware: zum Beispiel XGS 2100, SFOS 22.0 MR1.
• Testdatei: zum Beispiel 1GB.bin.
• Gemessene Rate: zum Beispiel 107 MB/s, ungefähr 856 Mbit/s.
• Aktiver WAN-Link: zum Beispiel WAN1 Fiber.
• Auffälligkeiten: zum Beispiel paralleles Backup, Failover, hohe CPU oder aktiver Packet Capture.

Wenn mehrere Messungen verglichen werden, sollten Testdatei, Ziel, Uhrzeit und WAN-Pfad möglichst gleich bleiben. Sonst vergleicht man schnell Tageszeit, Providerpfad oder Gegenstelle statt die eigentliche Firewall-Performance.

Mit Client-Tests vergleichen

Der nächste Schritt ist der Vergleich mit einem Client hinter der Firewall. Dadurch lässt sich eingrenzen, wo Performance verloren geht.

• Download direkt auf der Firewall ist schnell: Die WAN-Anbindung der Firewall ist wahrscheinlich nicht der Hauptengpass.
• Download direkt auf der Firewall ist langsam: Provider, WAN-Link, Routing, DNS oder Firewall-Uplink prüfen.
• Firewall schnell, Client langsam: Client, WLAN, Switch, Firewall-Regel, NAT, Security-Policy oder TLS Inspection prüfen.
• Nur einzelne Anwendungen langsam: Webfilter, Application Control, DNS, Proxy oder Zielserver prüfen.
• Nur VPN langsam: VPN-Protokoll, MTU/MSS, Routing, Firewall-Regeln und Clientnetz prüfen.

Für gezielte Streckentests ist iPerf oft besser als ein öffentlicher Download. Mit iPerf kann man definieren, wo Server und Client stehen, ob TCP oder UDP getestet wird und welche Bandbreite erwartet wird.

Typische Fehlinterpretationen

Firewall-Speedtest ist schnell, Benutzer melden trotzdem langsames Internet

Dann ist die WAN-Leitung nicht automatisch unschuldig, aber der Fokus verschiebt sich. Man sollte Clientnetz, WLAN, Switchport, DNS, Firewall-Regel, NAT, IPS, Web Protection, Application Control und TLS Inspection prüfen. Besonders TLS Inspection oder aggressive Security-Profile können Clienttraffic deutlich anders behandeln als einen Download direkt auf der Firewall.

Browser-Speedtest ist langsam, Firewall-Speedtest ist schnell

Das spricht häufig für ein Problem hinter der Firewall oder im Clientpfad. Trotzdem sollte man mehrere Browser, einen kabelgebundenen Client und ein zweites Ziel testen, bevor man eine feste Ursache annimmt.

Firewall-Speedtest ist langsam

Dann zuerst WAN-Status, Link-Speed, Duplex, SD-WAN-Routing, DNS, Providerstörung und Auslastung prüfen. Bei mehreren WAN-Anschlüssen sollte klar sein, über welches Gateway der Download läuft.

Nur Upload ist langsam

Der hier beschriebene curl-Download testet primär Downloadrichtung. Für Upload- oder bidirektionale Tests ist iPerf oder ein anderer definierter Testaufbau besser geeignet.

Troubleshooting nach dem Test

Wenn nach dem Speedtest unklar bleibt, wo das Problem liegt, sollte man strukturiert weitermachen:

1. Device Console prüfen: dnslookup, ping und traceroute nutzen, bevor man Downloadwerte interpretiert.
2. Log Viewer prüfen: Welche Firewall-Regel trifft der Clienttraffic?
3. Policy Test verwenden: Erwartete Source, Destination, Service und Benutzer prüfen.
4. Packet Capture starten: Sieht man Pakete, Antwortpakete und NAT?
5. Interface-Status prüfen: Link-Speed, Errors, Drops und Auslastung bewerten.
6. Security-Features prüfen: IPS, Webfilter, TLS Inspection, Application Control.
7. Gegenprobe mit iPerf durchführen: Strecke, TCP/UDP und Richtung gezielt testen.

Für Regel- und Paketflussanalysen passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Für die tieferen Logdateien hilft Sophos Firewall Troubleshooting: Services und Logs.

Checkliste

Vor dem Test

• SSH oder Advanced Shell Zugriff bewusst erlaubt.
• Device Access oder Local Service ACL exception rule für SSH sauber begrenzt.
• DNS und Erreichbarkeit über Device Console geprüft.
• Testzeitpunkt gewählt.
• WAN-Pfad bekannt.
• Genügend Speicherplatz vorhanden.
• Ziel der Messung definiert: WAN-Test, Clientvergleich oder VPN-Abgrenzung.

Während des Tests

• Testdatei nach /tmp herunterladen.
• Downloadrate und Einheit notieren.
• Bei Fehlern DNS, Routing oder Erreichbarkeit nicht mit Speed verwechseln.
• Keine parallelen grossen Änderungen an Firewall-Regeln oder SD-WAN durchführen.

Nach dem Test

• Testdatei löschen.
• Ergebnis in Mbit/s umrechnen.
• Mit Client- oder iPerf-Test vergleichen.
• Bei Abweichungen Log Viewer, Policy Test und Packet Capture nutzen.
• Ergebnis mit Uhrzeit, WAN-Link und Testziel dokumentieren.

FAQ