Sophos Firewall Performance mit iPerf3 richtig testen

iPerf3 misst den TCP- oder UDP-Durchsatz zwischen zwei definierten Endpunkten. Damit lässt sich prüfen, ob eine Strecke zwischen VLANs, über eine Sophos Firewall oder durch einen VPN-Tunnel langsamer ist als erwartet. Ein einzelner hoher oder niedriger Wert beweist jedoch noch kein Firewall-Problem.

Ein belastbarer Test braucht zuerst eine Baseline ohne den verdächtigen Pfad. Danach wird dieselbe Messung über die Firewall wiederholt. Richtung, Dauer, Protokoll, Streams, Firewall-Regel und Security-Profile müssen dokumentiert bleiben, sonst werden Ergebnisse miteinander verglichen, die technisch nicht vergleichbar sind.

⚠️ Lasttest einplanen: iPerf3 kann eine Leitung vollständig auslasten. Produktive Tests gehören in ein Wartungsfenster oder werden bewusst unterhalb der verfügbaren Bandbreite durchgeführt. Den Server nie unnötig aus dem Internet erreichbar lassen.

Was iPerf3 misst

iPerf3 besteht aus einem Server und einem Client. Standardmässig sendet der Client die Testdaten zum Server. Mit -R wird die Richtung umgekehrt. Der Messwert gilt immer nur für genau diese Endpunkte, diesen Pfad und diese Parameter.

Die drei wichtigsten Testarten beantworten unterschiedliche Fragen:

iPerf3 misst keine Anwendungsperformance. SMB, RDP, VoIP oder eine Webanwendung können trotz guter iPerf-Werte langsam sein. Umgekehrt kann ein einzelner TCP-Stream auf einer Strecke mit hoher Latenz unter der verfügbaren Leitungskapazität bleiben, obwohl Firewall und WAN korrekt arbeiten.

Für einen Internettest direkt aus Sicht der Appliance ist Sophos Firewall Internet-Speedtest per SSH der passendere Artikel. iPerf3 ist stärker, wenn zwei kontrollierte Endpunkte und der Pfad dazwischen untersucht werden sollen.

Testpfad und Baseline planen

Vor dem ersten Befehl werden Client, Server und die zu prüfende Strecke festgelegt. Eine sinnvolle Messreihe hat drei Stufen:

1. Endpunkt-Baseline: Client und Server im selben lokalen Netz oder über einen bekannten schnellen Switch testen. Ist dieser Wert bereits schlecht, zuerst Client, Server, NIC, Host-Firewall, Hypervisor oder WLAN untersuchen.
2. Firewall-Pfad: Dieselben Endpunkte über die vorgesehenen VLANs beziehungsweise Zonen und die echte Sophos-Firewall-Regel testen.
3. WAN- oder VPN-Pfad: Erst danach den Test über Provider, SD-WAN, Site-to-Site VPN oder Remote Access wiederholen.

Kabelgebundene Endpunkte sind für eine Firewall-Aussage besser als WLAN-Clients. Auf beiden Systemen sollten Energiesparfunktionen, CPU-Auslastung, virtuelle NICs und paralleler Traffic bekannt sein. Server und Client sollten möglichst dieselbe iPerf3-Hauptversion verwenden; iPerf2 und iPerf3 sind nicht kompatibel.

Firewall-Regel vorbereiten

iPerf3 verwendet standardmässig Port 5201. Für einen TCP-Test wird TCP 5201 benötigt. Bei einem UDP-Test laufen die Testdaten über UDP 5201, die Steuerverbindung bleibt aber TCP. Eine Sophos-Servicegruppe für UDP-Tests muss deshalb TCP und UDP 5201 enthalten.

Die temporäre Regel unter Rules and policies > Firewall rules sollte nur die konkrete Quell-IP, Ziel-IP und den iPerf-Service erlauben. Log firewall traffic einschalten und die Rule ID notieren. Keine breite Any-Regel und keine Internetfreigabe erstellen, nur um den Test schneller zu starten.

Nach dem Speichern im Log viewer prüfen, ob genau diese Regel greift. Bei unklarer Zuordnung hilft Sophos Firewall-Regeln gezielt testen.

iPerf3 installieren und Server absichern

Die offizielle Projektdokumentation und Quellpakete liegen bei ESnet iPerf3. ESnet nennt Ubuntu Linux, FreeBSD und macOS als offiziell unterstützte Plattformen. Windows-Binärpakete stammen in der Praxis häufig von Drittanbietern; eine bekannte Übersicht bietet iPerf.fr.

Auf dem Zielsystem startet der Server so:

iperf3 -s

Sicherer ist es, den Prozess an die Test-IP zu binden und nach einer Client-Verbindung automatisch zu beenden:

iperf3 -s -B 10.10.10.50 -1

-B bindet iPerf3 an die angegebene Adresse. -1 akzeptiert höchstens eine Client-Verbindung und beendet den Server danach. Für jeden weiteren Einzeltest muss der Befehl neu gestartet werden. Soll ein anderer Port verwendet werden, muss er auf beiden Seiten identisch angegeben werden:

iperf3 -s -B 10.10.10.50 -p 5200 -1

Zusätzlich kann die lokale Host-Firewall auf dem Server den Port blockieren. Diese Freigabe ebenfalls auf die Testquelle und die benötigte Dauer begrenzen.

TCP in beiden Richtungen testen

Der erste Test verwendet einen einzelnen TCP-Stream und läuft 30 Sekunden:

iperf3 -c 10.10.10.50 -t 30

Standardmässig sendet der Client zum Server. Danach wird mit denselben Endpunkten die Gegenrichtung geprüft:

iperf3 -c 10.10.10.50 -t 30 -R

Unterscheiden sich beide Richtungen stark, sind asymmetrische WAN-Bandbreite, Routing, SD-WAN, Interface-Fehler, VPN-Parameter oder ein Endpunkt wahrscheinlicher als ein allgemeines Durchsatzlimit.

Erst nach dem Single-Stream-Test folgt bei Bedarf ein Vergleich mit vier parallelen Streams:

iperf3 -c 10.10.10.50 -t 30 -P 4

Wenn -P 4 deutlich schneller ist, kann ein einzelner TCP-Flow durch Latenz, TCP-Fenster oder Endpunktleistung begrenzt sein. Das Ergebnis ist nicht automatisch die Geschwindigkeit, die eine einzelne Anwendung erreicht. --bidir belastet beide Richtungen gleichzeitig und eignet sich eher als gezielter Stresstest als für einen sauberen Richtungsvergleich.

UDP kontrolliert testen

Ein UDP-Test braucht immer eine realistische Zielbandbreite. Ohne -b verwendet iPerf3 standardmässig nur 1 Mbit/s; daraus lässt sich keine 100-Mbit- oder Gigabit-Strecke bewerten.

Beispiel mit 100 Mbit/s:

iperf3 -c 10.10.10.50 -u -b 100M -t 30

Nicht sofort mit der theoretischen Leitungsrate beginnen. Zuerst beispielsweise 60 bis 80 Prozent der erwarteten nutzbaren Bandbreite testen und den Zielwert danach schrittweise erhöhen. Bei einem VPN muss zusätzlich der Protokoll- und Verschlüsselungs-Overhead berücksichtigt werden.

Für UDP sind drei Werte entscheidend:

• Bitrate: tatsächlich erreichte Datenrate.
• Jitter: Schwankung der Laufzeit zwischen den Paketen.
• Lost/Total Datagrams: vom Empfänger erkannter Paketverlust.

Eine absichtlich zu hohe Zielbandbreite erzeugt selbst Paketverlust. Das ist ein Grenztest, aber kein Beweis für eine fehlerhafte Firewall. Die Gegenrichtung wird auch bei UDP mit -R separat geprüft.

Sophos Firewall während des Tests beobachten

Ein iPerf-Ergebnis wird erst aussagekräftig, wenn es zeitlich mit der Firewall korreliert wird. Während des 30-Sekunden-Tests sollten folgende Punkte sichtbar sein:

• Im Log viewer stimmen Firewall Rule ID, Quelle, Ziel, Service und erlaubte Verbindung.
• Im Control center zeigen CPU, Memory, Bandwidth und Sessions, ob die Appliance während des Tests an eine Grenze kommt.
• Unter Diagnostics > System graphs werden in den Interface graphs Bits, Drops, Errors und Collisions auf den beteiligten Interfaces geprüft.
• Unter Diagnostics > Packet capture kann ein enger Filter auf Client, Server und Port 5201 zeigen, ob Pakete verworfen oder durch unerwartete Module verarbeitet werden.

Packet Capture zeigt unter anderem Firewall-Regelnummer sowie Web-, Application- und IPS-Policy-Nummern. Den Capture kurz halten, eng filtern und nach dem Test wieder stoppen. Der Artikel Packet Capture auf Sophos Firewall beschreibt die Auswertung genauer.

Security-Profile isolieren

Wenn die Endpunkt-Baseline gut und nur der Firewall-Pfad langsam ist, wird nicht alles gleichzeitig deaktiviert. Zuerst die tatsächlich greifende Regel und ihre Security-Profile dokumentieren. Danach in einem Wartungsfenster genau eine Variable ändern und denselben Test wiederholen.

Eine diagnostische Regel ohne zusätzliche Prüfung darf nur eng auf Testquelle, Testziel und iPerf-Service begrenzt sein. Nach der Vergleichsmessung wird sie sofort deaktiviert oder entfernt. So lässt sich erkennen, ob IPS, Application Control, Traffic Shaping oder eine andere Policy beteiligt ist, ohne den restlichen Verkehr ungeschützt zu lassen.

Ergebnisse richtig einordnen

Bei TCP sind die Zusammenfassung für sender und receiver sowie die Retransmits wichtig. Viele Retransmits sprechen für Verlust oder eine gestörte Strecke, nicht automatisch für zu wenig Firewall-CPU. Ein guter lokaler Baseline-Wert und ein schlechter Wert über die Firewall grenzen die Suche ein; sie benennen aber noch nicht die Ursache.

Typische Muster:

• Bereits im selben LAN langsam: Endpunkte, NIC-Treiber, virtuelle Plattform, Host-Firewall oder WLAN prüfen.
• Nur über die Firewall langsam: Regel, Security-Profile, Traffic Shaping, Interface-Errors und Systemlast untersuchen.
• Nur über VPN langsam: WAN-Qualität, Latenz, Verschlüsselungsprofil, Tunnelroute sowie MTU und MSS prüfen.
• Nur eine Richtung langsam: Reverse-Test, Interface-Zähler, asymmetrisches Routing und Provider-Upstream vergleichen.
• Single Stream langsam, mehrere Streams schnell: Latenz, TCP-Fenster und Endpunktleistung einordnen, bevor ein Firewall-Limit angenommen wird.
• Nur ein öffentlicher Server langsam: Auslastung, Entfernung oder Peering des fremden Servers kann das Ergebnis begrenzen.

Öffentliche iPerf-Server eignen sich höchstens für einen groben Internetvergleich. Für Firewall-, VPN- oder Standortdiagnosen ist ein eigener kontrollierter Server auf der Gegenseite belastbarer.

Messung dokumentieren und zurückbauen

Damit ein Vorher-nachher-Vergleich später nachvollziehbar bleibt, werden mindestens Datum, Client, Server, Richtung, Befehl, Rule ID, Security-Profile, VPN- oder WAN-Pfad sowie sender-/receiver-Ergebnis festgehalten. Während einer Fehleranalyse immer nur eine Variable zwischen zwei Läufen ändern.

Nach Abschluss:

1. iPerf3-Server beenden.
2. Freigabe in der Host-Firewall entfernen.
3. Temporäre Sophos-Firewall-Regel und Test-Service deaktivieren oder löschen, wenn sie nicht mehr benötigt werden.
4. Geänderte Security-Profile in den vorgesehenen Zustand zurücksetzen.
5. Log Viewer und Interface-Zähler noch einmal auf Drops oder Fehler prüfen.

FAQ