Sophos Firewall Internet-Speedtest per SSH durchführen

Ein Download direkt aus der Advanced Shell beantwortet eine klar begrenzte Frage: Welche Downloadrate erreicht die Sophos Firewall selbst über ihren aktuellen WAN-Pfad? Damit lässt sich eine langsame Internetleitung von Problemen im Clientnetz, WLAN, VPN oder in einer Security-Policy abgrenzen.

Der Test ist kein vollständiger End-to-End-Test. Firewall-eigener Traffic durchläuft nicht denselben Weg wie ein Client hinter der Firewall. Für eine kontrollierte Messung zwischen zwei Endpunkten ist iPerf hinter Sophos Firewall besser geeignet; Datenblattwerte und den Einfluss aktivierter Security-Funktionen erklärt der Artikel zu den Sophos-Firewall-Leistungsdaten.

Vor dem Speedtest

Der Test benötigt SSH-Zugriff, funktionierendes DNS und einen unkritischen Zeitpunkt. Für einen kurzen Check steht eine 100-MB-Datei bereit; auf schnellen Leitungen liefert die 1-GB-Datei meist den stabileren Durchschnittswert. Beide Downloads können die Leitung kurzfristig vollständig auslasten und sollten deshalb nicht während Backups, VoIP-Spitzen, Failover-Tests oder anderer Wartungsarbeiten gestartet werden.

SSH wird unter Administration > Device access über die Local service ACL oder gezielter über eine Local service ACL exception rule freigegeben. Der Zugriff sollte nur aus einem vertrauenswürdigen Adminnetz erlaubt sein und nach der Arbeit wieder auf das notwendige Minimum begrenzt werden. Die Anmeldung ist unter Sophos Firewall per SSH verbinden beschrieben. Inaktive SSH-Sitzungen beendet Sophos Firewall nach 15 Minuten.

⚠️ Nicht starten, wenn aktiver WAN-Pfad oder betriebliche Auswirkungen unklar sind. Bei unerwartet hoher CPU-Last, Störungen oder falschem Gateway den Download mit Ctrl+C abbrechen. Der unten verwendete Ausgabepfad /dev/null legt keine Testdatei auf der Firewall ab.

WAN-Pfad bei mehreren Anschlüssen prüfen

Der Download ist systemgenerierter Traffic. Eine SD-WAN-Route für Clients bestimmt daher nicht automatisch seinen Weg. In 4 Device Console zeigt dieser lesende Befehl, ob passende SD-WAN-Routen auch für systemgenerierten Traffic greifen können:

show routing sd-wan-policy-route system-generate-traffic

Ist die Option aktiviert, kann eine passende SD-WAN-Route den Downloadpfad beeinflussen. Ist sie deaktiviert, verwendet die Firewall ihre normalen Routing- und WAN-Entscheidungen. Der Befehl beweist noch nicht, welches Gateway der einzelne Download tatsächlich nimmt. Zusätzlich sollte man unter Network > WAN link manager die aktiven Gateways und unter Routing > SD-WAN routes den Status und passende Routen prüfen.

Auch ein ping mit interface oder sourceip ist nur ein Hinweis für diesen ICMP-Test; der spätere HTTPS-Download kann trotzdem anders geroutet werden. Die Zusammenhänge erklärt SD-WAN Routing, Reply Packet und System Traffic. Für den Speedtest sollte keine Routing-Option eigens umgestellt werden.

Internet-Speedtest per SSH durchführen

1. Shell und Downloadwerkzeug prüfen

Nach der SSH-Anmeldung als admin im CLI-Hauptmenü 5 Device Management > 3 Advanced Shell öffnen. Sophos dokumentiert diesen Shell-Zugang, nicht aber curl als zugesicherte SFOS-Schnittstelle. Deshalb zuerst ohne Download prüfen, ob das Werkzeug in der installierten Firmware vorhanden ist:

curl --version

Erscheinen Version und unterstützte Protokolle, kann man fortfahren. Meldet die Shell curl: not found oder einen Optionsfehler, den Ablauf nicht durch Paketinstallation oder Änderungen am Firewall-Dateisystem reparieren. Stattdessen einen Clienttest oder den verlinkten iPerf-Ablauf verwenden und bei Bedarf Sophos Support einbeziehen.

DNS und HTTPS werden vom eigentlichen curl-Aufruf geprüft. Ein HTTP-Fehler führt durch --fail zu einem von null verschiedenen Rückgabestatus; die Fortschrittsanzeige allein ist dann kein gültiges Messergebnis.

2. Download ohne Testdatei messen

Die Advanced Shell ist eine Linux-Shell mit tiefem Systemzugriff. Der folgende Befehl lädt die Daten, verwirft sie aber über /dev/null. So beeinflusst das Schreiben einer grossen Datei das Ergebnis nicht und es ist kein Speicher-Cleanup nötig.

Für einen kurzen Test die 100-MB-Datei herunterladen:

curl --location --fail --output /dev/null \
  --write-out '\nHTTP %{http_code} | %{size_download} bytes | %{speed_download} bytes/s\n' \
  https://www.avanet.io/100MB.bin

Auf schnellen Leitungen kann man im selben Befehl ausschliesslich die URL durch https://www.avanet.io/1GB.bin ersetzen. --location folgt Weiterleitungen, --fail wertet HTTP-Fehler als Fehler, und --output /dev/null verhindert eine lokale Datei. Zum Veröffentlichungszeitpunkt liefern die Endpunkte 104857600 Bytes für 100 MB beziehungsweise 1048576000 Bytes für 1 GB.

Die Datei wird über Avanet und Cloudflare ausgeliefert. Testziel, Cachezustand, Peering, Routing und CPU-Last können das Ergebnis beeinflussen. Der Wert ist deshalb eine praktische Vergleichsmessung und keine garantierte Provider- oder Firewall-Leistung.

3. Rückgabewert und Datenmenge kontrollieren

Nur ein ohne curl-Fehlermeldung abgeschlossener Lauf mit HTTP 200 und einer size_download, die dem oben genannten Wert entspricht, wird ausgewertet. Ein kleinerer Wert bedeutet einen Abbruch; HTTP 000 weist typischerweise auf DNS-, Verbindungs- oder TLS-Probleme hin. Bei anderen HTTP-Codes ist das Testziel zu diesem Zeitpunkt nicht verwendbar. In allen Fällen wird keine Testdatei angelegt; als Cleanup genügt es, die Advanced Shell mit exit zu verlassen und eine nur für diesen Test erstellte SSH-ACL-Ausnahme wieder zu entfernen.

Ergebnis richtig auswerten

speed_download gibt die durchschnittliche Downloadrate in Bytes pro Sekunde aus. Für Mbit/s wird der Wert mit acht multipliziert und durch eine Million geteilt. Die normale Fortschrittsanzeige zeigt zusätzlich Average Speed; im vorhandenen Screenshot steht dort 107M.

Das M in dieser Fortschrittsanzeige ist 1024-basiert und entspricht MiB/s. Internetanschlüsse werden dagegen in dezimalen Mbit/s angegeben. Für das Beispiel gilt:

107 x 1048576 x 8 / 1000000 = 897.6 Mbit/s

107M entsprechen somit ungefähr 898 Mbit/s, nicht 856 Mbit/s. Overhead, TCP-Verhalten, Gegenstelle, Routing und momentane Auslastung verhindern in der Praxis meist eine exakte Übereinstimmung mit dem Tarifwert.

Ein einzelner Lauf ist keine belastbare Diagnose. Mehrere Messungen sollten möglichst mit demselben Ziel, demselben WAN-Pfad und vergleichbaren Rahmenbedingungen erfolgen. Für Support oder interne Dokumentation ist dieser Messdatensatz sinnvoll:

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

Was das Ergebnis bedeutet

Der Firewall-Download ist eine Abgrenzung, kein abschliessender Beweis. Die Kombination mit einem Clienttest zeigt, wo man als Nächstes suchen sollte:

• Firewall schnell, Client langsam: Client, WLAN, Switchport, DNS, Firewall-Regel, NAT, IPS, Web Protection, Application Control und TLS Inspection prüfen. Dabei helfen Log Viewer, Policy Test und Packet Capture sowie bei Bedarf ein gezielter Packet Capture.
• Firewall und Client langsam: WAN-Status, Link-Speed, Duplex, Interface-Errors und -Drops, aktives Gateway, Providerstörung, CPU-Last und ein zweites Testziel vergleichen.
• Nur einzelne Anwendungen langsam: DNS, Web Protection, Application Control, Proxy, TLS Inspection und Gegenstelle vergleichen.
• Nur VPN langsam: VPN-Protokoll, Routing sowie MTU und MSS prüfen.
• Nur Upload langsam: Dieser curl-Ablauf misst ausschliesslich den Download. Für Upload oder beide Richtungen ist ein kontrollierter iPerf-Test geeigneter.
• Werte schwanken über längere Zeit: Vergleichbare Messungen wiederholen und den Interface-Traffic bei Bedarf mit sFlow Monitoring beobachten.

Bleibt die Ursache unklar, werden zuerst der betroffene Clientflow und die tatsächlich getroffene Regel geprüft. Für tiefergehende Analysen zeigt Sophos Firewall Troubleshooting: Services und Logs, welche Logdatei zum jeweiligen Dienst gehört.

FAQ