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

Ein typisches MTU-/MSS-Problem sieht nicht wie ein klarer Block aus: Der VPN-Tunnel ist verbunden und Ping funktioniert, aber Downloads brechen ab, RDP friert ein oder HTTPS-Anmeldungen bleiben stehen. Ursache kann der kleinere nutzbare Pfad durch IPsec, PPPoE, XFRM oder SD-WAN sein.

Wenn der Tunnel gar nicht aufbaut oder keine Security Association vorhanden ist, zuerst Sophos Firewall IPsec VPN Troubleshooting verwenden. Für Interface-Typen und XFRM hilft Sophos Firewall Zonen und Interfaces konfigurieren.

Schnelldiagnose: MTU- oder MSS-Problem nachweisen

Im Log Viewer die erwartete Firewall Rule ID und, falls NAT am Pfad beteiligt ist, die NAT Rule ID bestätigen. Fehlt der Traffic ganz oder greifen falsche Regeln, zuerst Routing, Zone, NAT oder DNS korrigieren.
Source, Destination, Service, Richtung, TCP/UDP und den tatsächlichen Pfad über LAN, VLAN, WAN, XFRM, RED, SD-WAN oder Remote Access VPN notieren.
Aktuelle MTU und MSS am betroffenen Interface anzeigen und dokumentieren.
Einen DF-Test, ein eng gefiltertes Packet Capture und denselben echten Anwendungstest durchführen.
Nur bei einem reproduzierbaren Unterschied zwischen kleinen und grossen Paketen einen Wert ändern. Danach exakt denselben Test wiederholen.

Die allgemeine Regelprüfung beschreibt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Bei abweichender NAT Rule ID hilft NAT auf Sophos Firewall verstehen.

Paketgrösse mit DF-Bit testen

Bei IPv4 kommen zur ICMP-Payload 20 Byte IP- und 8 Byte ICMP-Header hinzu. Eine Payload von 1472 entspricht somit einem Paket von ungefähr 1500 Byte.

Windows:

ping -f -l 1472 <ziel-ip>

macOS:

ping -D -s 1472 <ziel-ip>

Linux:

ping -M do -s 1472 <ziel-ip>

Schlägt 1472 fehl, die Payload schrittweise auf 1464, 1452, 1412 oder kleiner reduzieren. Die funktionierende und die fehlschlagende Grösse dokumentieren. ICMP-Filter, Provider, Cloud-Gateways oder die Gegenstelle können das Resultat verfälschen; der DF-Test ersetzt deshalb weder Packet Capture noch Anwendungstest.

MTU, MSS und den betroffenen Pfad einordnen

Die MTU ist die maximale Paketgrösse eines Interfaces oder Pfads. Grössere Pakete werden fragmentiert oder verworfen. Die MSS begrenzt den TCP-Nutzdatenanteil pro Segment. Bleibt sie trotz VPN- oder Provider-Overhead zu hoch, entstehen Retransmits, Stalls und Abbrüche bei grösseren Datenmengen.

MTU und MSS sind keine allgemeinen Tuning-Werte. Relevant ist der konkrete Pfad:

WAN, PPPoE oder VLAN: Provider, Router oder zusätzlicher Header reduzieren die nutzbare Paketgrösse.
XFRM: Route-based IPsec erzeugt Overhead; Routen, Regeln und XFRM-Interface bestimmen gemeinsam den Pfad.
SD-WAN: Ein Flow kann ein anderes WAN, MPLS oder VPN verwenden als erwartet. Die Pfadauswahl erklärt SD-WAN Routing für Reply Packets und System Traffic.
Gegenstelle: Rückroute, Remote-Firewall, Cloud-VPN und MSS-Clamping müssen zur getesteten Richtung passen.
Wi-Fi: Seit SFOS 22.0 MR1 lassen sich MTU und MSS bestehender Wi-Fi-Interfaces mit den dokumentierten CLI-Befehlen ändern.

Verdächtig sind grosse Downloads oder Uploads, RDP, SMB, HTTPS, Backups, ERP, Cloud- und Konferenzanwendungen oder VoIP, die nur über einen bestimmten VPN- oder SD-WAN-Pfad ausfallen. Auch viele iPerf-Retransmits, stark schwankender TCP-Durchsatz oder ein Fehler direkt nach Providerwechsel, Firmware-Upgrade, SD-WAN-Umbau oder VPN-Migration passen dazu. Scheitern kleine und grosse Tests gleich, sind Regel, NAT, Routing, DNS, Zielsystem oder Rückweg wahrscheinlicher.

Datenfluss mit Log Viewer, Packet Capture und iPerf prüfen

Regel, NAT und DNS ausschliessen

Kein Traffic im Log Viewer: Client-Gateway, VLAN, Route, Logging und Testflow prüfen.
Falsche Firewall Rule ID: Reihenfolge, Zone, Source, Destination, Service und User Matching prüfen. Weitere Ursachen zeigt Sophos Firewall Regel greift nicht.
Falsche NAT Rule ID: Reihenfolge, Original-Felder, MASQ, SNAT, DNAT und Richtung prüfen.
Unerwartete Ziel-IP: DNS, Split DNS, FQDN-Objekt, CDN und IPv6 prüfen.

Ist ein VPN beteiligt, zusätzlich Tunnelstatus und Byte-Zähler kontrollieren. TLS Inspection, IPS und Application Control dokumentieren, damit Vorher-/Nachher-Tests wirklich denselben Pfad und dieselben Security Features vergleichen.

Packet Capture auswerten

Unter Diagnostics > Tools > Packet capture auf die betroffene Source und Destination filtern und genau einen HTTPS-Aufruf, Transfer oder Anwendungsstart reproduzieren:

Kommen Pakete nicht an, liegt der Fehler meist bei Client, Gateway, VLAN oder lokalem Routing.
Gehen Pakete in den Tunnel und Antworten fehlen, Gegenstelle und Rückroute prüfen.
Viele TCP-Retransmits sprechen für Paketverlust, MTU/MSS, WAN-Qualität oder Überlast.
Funktionieren kleine Tests, grosse Transfers aber nicht, Path-MTU-Discovery und Fragmentierung prüfen.

Die Bedienung erklärt Packet Capture im WebAdmin verwenden. Captures und aktivierte Debug-Logs nur so lange wie nötig laufen lassen, damit sie nicht unnötig Speicher belegen.

iPerf mit einem Anwendungstest vergleichen

Ein dedizierter iPerf-Server auf der Gegenseite ist aussagekräftiger als ein öffentlicher Server. TCP und UDP getrennt testen und niedrigen TCP-Durchsatz oder Retransmits zusammen mit WAN-Qualität, CPU, Gegenstelle und Security Features bewerten. Den vollständigen Ablauf zeigt Sophos Firewall Troubleshooting mit iPerf und Speedtest.

MTU und MSS anzeigen oder ändern

WebAdmin und XFRM

Unter Network > Interfaces das betroffene Interface bearbeiten und Advanced settings > Interface settings öffnen. Dort stehen MTU und Override MSS. XFRM-Interfaces erscheinen unter ihrem physischen Listening Interface.

Sophos Firewall berechnet die XFRM-MTU standardmässig aus der MTU des Listening Interface und dem maximalen IPsec-Overhead. Wird die XFRM-MTU manuell geändert, muss sie mindestens 113 Byte kleiner als die MTU des Listening Interface sein. Bei 1400 Byte am Listening Interface sind für XFRM höchstens 1287 Byte zulässig. Diese Reserve verhindert Paketverluste beim FastPath-Offload, wenn SSL/TLS-Entschlüsselung auf IPsec-Traffic angewendet wird.

Werte in der Device Console prüfen

Per SSH anmelden, im Hauptmenü 4. Device Console wählen und die Interface-ID einsetzen:

show mtu-mss Port2

Für physische Interfaces dokumentiert Sophos diese Änderungssyntax:

set network mtu-mss <PortID> mtu <number|default> mss <number|default>

Rechenbeispiel: Beträgt die nachgewiesene IPv4-Pfad-MTU 1492 Byte, ergibt sich ohne zusätzliche Optionen eine TCP-MSS von 1452 Byte (1492 - 20 - 20). Das ist weder ein allgemeiner SFOS-Standardwert noch eine pauschale Empfehlung für das physische PPPoE-Interface.

⚠️ Eine Änderung wirkt auf laufenden Traffic und kann die SSH- oder WebAdmin-Verbindung unterbrechen. Sie sollte nicht über die einzige Managementverbindung am betroffenen Interface erfolgen. Eine lokale oder Out-of-Band-Rückfallmöglichkeit muss vorhanden sein. Port2 ist nur ein Beispiel und muss durch die tatsächlich geprüfte Interface-ID ersetzt werden.

Vorher die angezeigten Werte sichern. default setzt die von Sophos dokumentierten Produktdefaults MTU 1500 und MSS 1460:

set network mtu-mss Port2 mtu default mss default

Das ist nur dann ein Rollback, wenn diese Werte vor der Änderung aktiv waren. Andernfalls die mit show mtu-mss dokumentierten Ausgangswerte explizit wiederherstellen.

Änderung abnehmen

betroffenes Interface, Tunnel und Ausgangswerte dokumentieren;
Wartungsfenster oder kontrollierten Testzeitpunkt wählen;
nur eine Änderung pro Test durchführen;
Gegenstelle bei Site-to-Site-VPN informieren;
nach Änderung und Rollback mit show mtu-mss Port2 prüfen, ob die erwarteten Werte aktiv sind;
denselben DF-, Capture-, iPerf- und Anwendungstest wiederholen;
neue Werte, Begründung und Resultat dokumentieren;
Monitoring in den folgenden Tagen prüfen.

⚠️ Keine dauerhaften Advanced-Shell-Hacks, Startskripte oder spontanen Paketfilter-Regeln verwenden. Sie sind schwer wartbar und können nach Update, Restore oder HA-Failover falsch wirken oder verschwinden. Wenn solche Altlasten vorhanden sind, hilft Sophos Firewall Skripte ohne Cronjob: Risiken und Alternativen.

MSS nicht pauschal für alle Netze stark reduzieren, nie nur eine Richtung testen und die Gegenstelle nicht ignorieren. Wenn ein kontrollierter Test keine Verbesserung zeigt, den dokumentierten Ausgangswert wiederherstellen.

Troubleshooting nach Symptom

VPN grün, grosse Transfers hängen: MTU/MSS, Rückweg oder Security Feature mit Packet Capture und iPerf auf demselben Pfad prüfen.
Nur PPPoE-WAN betroffen: WAN-Interface, Gateway, Providerangaben und nutzbare Paketgrösse prüfen.
Route-based VPN bei grossen Paketen instabil: XFRM-Interface, IPsec-Verbindung, Route und 113-Byte-Regel prüfen.
VoIP über VPN instabil: SIP-/RTP-Pfad, SD-WAN Route, Rückweg, Paketverlust und Capture prüfen.
TCP sehr langsam, UDP normal: MSS, Retransmits, TCP-Window und Paketverlust mit getrennten iPerf-Tests prüfen.
Kleine Pakete funktionieren, grosse nicht: DF-Test dokumentieren und Path-MTU-Discovery, Fragmentierung sowie Gegenstelle prüfen.

FAQ

Warum funktioniert Ping, aber HTTPS oder RDP nicht?

Ein normaler Ping verwendet kleine Pakete. Grössere TCP-Segmente können trotzdem fragmentiert oder verworfen werden. Deshalb braucht es DF-Tests mit dokumentierten Grössen und einen echten Anwendungstest.

Muss man bei jedem VPN MTU oder MSS ändern?

Nein. Standardwerte funktionieren in vielen Umgebungen. Eine Änderung ist nur sinnvoll, wenn Pfad, Paketgrössen und reproduzierbare Tests ein MTU-/MSS-Problem belegen.