Sophos Firewall MTU und MSS bei VPN-Problemen prüfen

Wenn eine VPN-Verbindung aufgebaut ist, aber einzelne Anwendungen trotzdem hängen bleiben, wird oft zuerst an Firewall-Regeln, DNS oder die Gegenstelle gedacht. Das ist richtig, aber nicht vollständig. Bei grossen Paketen, IPsec-Overhead, PPPoE, SD-WAN oder route-based VPNs können auch MTU und MSS die Ursache sein.

Typisch ist ein Fehlerbild, das nicht wie ein klarer Block aussieht: Ping funktioniert, kleine Webseiten laden, aber Dateiübertragungen brechen ab, RDP friert ein, HTTPS-Anmeldungen bleiben stehen oder VoIP wird instabil. Der Artikel ordnet MTU- und MSS-Themen auf Sophos Firewall ein, ohne blind Werte zu ändern oder gefährliche Shell-Workarounds zu bauen.

Für die Grundlagen zu Interfaces, Zonen und XFRM passt zuerst Sophos Firewall Zonen und Interfaces konfigurieren. Wenn ein IPsec-Tunnel gar nicht aufgebaut wird oder keine Security Association installiert ist, ist Sophos Firewall IPsec VPN Troubleshooting der bessere Einstieg.

MTU und MSS kurz erklärt

Die MTU beschreibt, wie gross ein Paket auf einem Interface oder Pfad maximal sein darf. Wenn ein Paket grösser ist als der Pfad erlaubt, muss es fragmentiert werden oder es wird verworfen. Bei VPNs ist das besonders relevant, weil IPsec zusätzliche Header hinzufügt.

Die MSS betrifft TCP und beschreibt, wie gross der Nutzdatenanteil eines TCP-Segments sein soll. Wenn die MSS zu hoch bleibt, obwohl der tatsächliche Pfad durch VPN, PPPoE oder andere Overlays kleiner ist, entstehen typische TCP-Probleme: Retransmits, Stalls, langsame Verbindungen oder Verbindungsabbrüche bei grösseren Datenmengen.

Wichtig: MTU und MSS sind keine Tuning-Werte, die man zufällig kleiner setzt, bis es irgendwie funktioniert. Beide Werte gehören zum Pfad. Vor einer Änderung sollte klar sein, welches Interface, welche Richtung, welches Protokoll und welcher Tunnel betroffen sind.

Wann man MTU oder MSS verdächtigen sollte

MTU- und MSS-Probleme zeigen sich oft nur bei bestimmten Anwendungen oder Paketgrössen.

Typische Hinweise:

VPN-Tunnel ist verbunden, aber grössere Downloads oder Uploads bleiben hängen.
RDP, SMB, HTTPS, Backup, ERP oder Cloud-Anwendungen funktionieren nur teilweise.
Kleine ICMP-Tests funktionieren, grössere Datenübertragungen nicht.
VoIP oder Konferenzanwendungen sind nur über bestimmte VPN- oder SD-WAN-Pfade instabil.
Das Problem betrifft nur PPPoE, ein bestimmtes WAN, eine route-based IPsec-Strecke oder ein XFRM-Interface.
iPerf zeigt viele Retransmits oder stark schwankenden TCP-Durchsatz.
Nach einem Providerwechsel, Firmware-Upgrade, SD-WAN-Umbau oder VPN-Migration tritt plötzlich ein neues Fehlerbild auf.

Solche Symptome beweisen noch kein MTU-Problem. Trotzdem sind sie ein guter Grund, MTU und MSS in die Analyse aufzunehmen.

Nicht mit Regel-, NAT- oder DNS-Problemen verwechseln

MTU/MSS ist meistens nicht der erste Prüfpunkt. Zuerst sollte klar sein, dass der Traffic grundsätzlich den erwarteten Pfad nimmt. Sonst wird an Paketgrössen gedreht, obwohl eigentlich eine Regel, NAT, DNS oder der Rückweg falsch ist.

Beobachtung	Zuerst wahrscheinlicher als MTU/MSS
Im Log Viewer erscheint gar kein Traffic	Logging, Client-Gateway, VLAN, Route oder falscher Testflow
Die falsche Firewall Rule ID greift	Regelreihenfolge, Zone, Source, Destination, Service oder User Matching
NAT Rule ID passt nicht	NAT-Reihenfolge, Original-Felder, MASQ/SNAT/DNAT oder falsche Richtung
Name löst auf eine unerwartete IP auf	DNS, Split DNS, FQDN-Objekt, CDN oder IPv6
Kleine und grosse Tests scheitern gleich	Regel, Routing, NAT, Zielsystem oder Gegenstelle
Nur grosse Transfers hängen	MTU/MSS, Fragmentierung, Path-MTU-Discovery oder VPN-Overhead mitprüfen

Für diese Vorprüfung passen Sophos Firewall Regel greift nicht: Ursachen prüfen, Packet Capture im WebAdmin verwenden und NAT auf Sophos Firewall verstehen. Erst wenn Regel, NAT, Routing und DNS plausibel sind, lohnt sich die MTU-/MSS-Spur wirklich.

Typische Stellen auf Sophos Firewall

Auf Sophos Firewall können mehrere Bereiche relevant sein. Meist ist nicht die ganze Firewall betroffen, sondern ein konkreter Pfad.

Bereich	Warum relevant
WAN-Interface	Provider, PPPoE, VLAN oder Router davor können die nutzbare Paketgrösse reduzieren
XFRM-Interface	Route-based IPsec erzeugt zusätzlichen Overhead und braucht passende Tunnel-MTU
SD-WAN Route	Ein Pfad kann über anderes WAN, MPLS oder VPN laufen als erwartet
Firewall-Regel	Security Features oder Logging helfen beim Eingrenzen, sind aber nicht die MTU selbst
Gegenstelle	Die andere Firewall, Cloud-VPN oder Providerseite muss denselben Pfad sauber bedienen
Wi-Fi-Interface	Seit SFOS 22.0 MR1 nennt Sophos auch MTU/MSS-Anpassungen für Wi-Fi-Interfaces per CLI

Bei route-based IPsec erstellt Sophos Firewall XFRM-Interfaces. XFRM-MTU-Werte werden ausgehend vom physischen Interface und dem maximalen IPsec-Overhead berechnet und können bei Bedarf angepasst werden. Das ist hilfreich, ersetzt aber keine saubere Prüfung des tatsächlichen Pfads.

Zuerst den Pfad beweisen

Vor jeder Änderung sollte man den betroffenen Datenfluss sauber beschreiben. Sonst optimiert man schnell am falschen Interface.

Praktische Fragen:

Welche Source-IP und Destination-IP sind betroffen?
Läuft der Traffic über LAN, VLAN, WAN, XFRM, RED, SD-WAN oder Remote Access VPN?
Ist nur eine Richtung betroffen oder beide?
Betrifft es TCP, UDP oder beides?
Funktionieren kleine Pakete, aber grössere Übertragungen nicht?
Greift wirklich die erwartete Firewall-Regel?
Gibt es NAT, MASQ, TLS Inspection, IPS oder Application Control auf dem Pfad?
Hat die Gegenstelle eine passende Rückroute?

Für die Regel- und Pfadprüfung hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Bei NAT oder MASQ sollte zusätzlich NAT auf Sophos Firewall verstehen geprüft werden.

Diagnose mit Log Viewer, Packet Capture und iPerf

Der Log Viewer zeigt, ob Traffic erlaubt oder verworfen wird. Er beweist aber nicht allein, ob ein Paket zu gross ist. Dafür braucht man zusätzlich Packet Capture, reproduzierbare Tests und eine klare Interpretation.

Log Viewer

Im Log viewer zuerst prüfen:

Modul Firewall oder das betroffene Security-Modul auswählen.
Source-IP, Destination-IP und Service filtern.
Prüfen, welche Firewall-Regel matched.
Sicherstellen, dass keine Drop-Regel, falsche Zone oder falsche NAT-Regel das eigentliche Problem ist.

Wenn gar kein Traffic sichtbar ist, liegt das Problem oft vor der Firewall, beim Client-Gateway, VLAN, Routing oder auf der Gegenstelle.

Packet Capture

Unter Diagnostics > Tools > Packet capture kann man den Test enger eingrenzen. Sinnvoll ist ein Filter auf genau die betroffene Source und Destination. Danach wird ein einzelner Test reproduziert, zum Beispiel ein HTTPS-Aufruf, eine Dateiübertragung oder ein Anwendungsstart.

Wichtig ist die Interpretation:

Beobachtung	Bedeutung
Pakete kommen nicht auf der Firewall an	Client, Gateway, VLAN oder lokales Routing prüfen
Pakete gehen in den Tunnel, Antworten fehlen	Gegenstelle, Rückroute oder Remote-Firewall prüfen
Viele Retransmits bei TCP	Paketverlust, MTU/MSS, WAN-Qualität oder Überlast prüfen
Kleine Tests funktionieren, grosse Übertragungen hängen	MTU/MSS oder Path-MTU-Discovery prüfen

Für die Bedienung des Tools passt Packet Capture Tool im WebAdmin verwenden.

iPerf

iPerf ist hilfreich, wenn man eine Strecke reproduzierbar messen kann. Ein eigener iPerf-Server auf der Gegenseite ist deutlich aussagekräftiger als ein Public-iPerf-Server. Wenn TCP-Durchsatz niedrig ist und viele Retransmits sichtbar werden, sollte MTU/MSS zusammen mit WAN-Qualität, CPU, Gegenstelle und Security-Features geprüft werden.

Der Ablauf steht in Sophos Firewall Troubleshooting mit iPerf und Speedtest.

Werte nur gezielt ändern

Wenn der Verdacht belastbar ist, sollten Änderungen klein, dokumentiert und reversibel bleiben.

Vor einer Änderung:

aktuellen Wert dokumentieren
betroffenes Interface und betroffenen Tunnel notieren
Wartungsfenster oder kontrollierten Testzeitpunkt wählen
nur einen Wert pro Test ändern
Vorher-/Nachher-Test mit derselben Anwendung durchführen
Gegenstelle informieren, wenn ein Site-to-Site-VPN betroffen ist

Bei route-based VPNs sollte zuerst das XFRM-Interface und die zugehörige IPsec-Verbindung geprüft werden. Bei PPPoE oder Provider-Overlays ist oft das WAN-Interface oder der Providerpfad der entscheidende Punkt. Bei SD-WAN muss zusätzlich klar sein, welcher Gateway- oder VPN-Pfad wirklich genutzt wird. Der Artikel SD-WAN Routing für Reply Packets und System Traffic hilft bei der Einordnung von SD-WAN-Pfaden.

⚠️ Keine dauerhaften Shell-Hacks verwenden. Direkte Paketmanipulation per Advanced Shell, nicht dokumentierte Startskripte oder spontane Paketfilter-Regeln sind für produktive Firewalls keine saubere Lösung. Zuerst sollten die unterstützten Sophos-Firewall-Funktionen geprüft werden.

Was man vermeiden sollte

Diese Muster verursachen in der Praxis mehr Schaden als Nutzen:

MSS pauschal für alle Netze extrem niedrig setzen.
MTU-Werte ohne Vorher-/Nachher-Test ändern.
Nur eine Richtung testen und daraus auf den ganzen VPN-Pfad schliessen.
Shell-Workarounds statt WebAdmin- oder dokumentierter Device-Console-Funktionen verwenden.
Die Gegenstelle ignorieren, obwohl der Rückweg oder deren MSS-Clamping beteiligt sein kann.
MTU/MSS als Ursache annehmen, obwohl Firewall-Regel, NAT, Routing oder DNS nicht geprüft wurden.
Debug-Logs oder Packet Captures lange laufen lassen und Speicherplatz füllen.

Wenn bereits lokale Skripte oder Paketmanipulationen existieren, sollte man zuerst Sophos Firewall Skripte ohne Cronjob: Risiken und Alternativen lesen und die Altlast sauber dokumentieren.

Troubleshooting-Tabelle

Symptom	Wahrscheinlicher Bereich	Nächster Check
VPN grün, grosse Transfers hängen	MTU/MSS, Rückweg, Security Feature	Packet Capture und iPerf mit gleichem Pfad
Nur PPPoE-WAN betroffen	Providerpfad oder WAN-MTU	WAN-Interface, Gateway und Providerangaben prüfen
Route-based VPN instabil bei grossen Paketen	XFRM-MTU oder SD-WAN-Pfad	XFRM-Interface, IPsec-Verbindung und Route prüfen
VoIP über VPN nur teilweise stabil	SD-WAN, Rückweg, Paketverlust, MTU	SIP/RTP-Pfad, SD-WAN Route und Capture prüfen
TCP sehr langsam, UDP normal	MSS, Retransmits, TCP-Window, Paketverlust	iPerf TCP/UDP getrennt testen
Kleine Pakete funktionieren, grosse nicht	Path-MTU-Discovery oder Fragmentierung	Paketgrössen bewusst testen und Gegenstelle prüfen

Checkliste

Sofort prüfen:

Betroffene Source, Destination, Service und Richtung dokumentiert.
Firewall-Regel und NAT-Regel im Log Viewer bestätigt.
Packet Capture mit engem Filter durchgeführt.
IPsec-Status und Byte-Zähler geprüft, wenn ein VPN beteiligt ist.
Gegenstelle und Rückweg geprüft.

Wenn MTU/MSS wahrscheinlich ist:

betroffene Interface- oder XFRM-Stelle identifiziert.
aktueller MTU-/MSS-Wert dokumentiert.
nur eine Änderung pro Test geplant.
Testanwendung und Vergleichswert festgelegt.
Änderung mit Gegenstelle abgestimmt, wenn Site-to-Site-VPN betroffen ist.

Nach der Änderung:

gleiche Anwendung erneut testen.
Log Viewer, Packet Capture oder iPerf vergleichen.
neue Werte und Begründung dokumentieren.
Monitoring in den nächsten Tagen prüfen.

FAQ

Ist MTU dasselbe wie MSS?

Nein. MTU betrifft die maximale Paketgrösse auf einem Interface oder Pfad. MSS betrifft die TCP-Nutzdaten pro Segment. Beide hängen zusammen, sind aber nicht dasselbe.

Warum funktioniert Ping, aber HTTPS oder RDP nicht?

Kleine Tests können funktionieren, obwohl grössere TCP-Segmente später Probleme verursachen. Deshalb reicht ein einfacher Ping nicht als Beweis, dass der ganze Pfad gesund ist.

Muss man bei jedem VPN die MTU ändern?

Nein. Viele VPNs funktionieren mit den Standardwerten sauber. Eine Änderung ist erst sinnvoll, wenn der betroffene Pfad und das Fehlerbild dafür sprechen.

Was ist bei XFRM-Interfaces besonders?

XFRM-Interfaces gehören zu route-based IPsec VPNs. Sophos Firewall erstellt sie automatisch im Kontext der IPsec-Verbindung. Bei route-based VPNs entscheiden Routen, Firewall-Regeln und das XFRM-Interface gemeinsam, wohin Traffic fliesst.

Sollte man MSS per Shell erzwingen?

Für den normalen Betrieb nein. Shell-basierte Paketmanipulation ist schwer wartbar und kann nach Updates, Restore oder HA-Failover unerwartet verschwinden oder falsch wirken. Unterstützte Firewall-Funktionen sind vorzuziehen.