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 > Packet capture zuerst Configure öffnen und einen engen BPF-Filter setzen, zum Beispiel host 192.0.2.10 and host 198.51.100.20 and port 443. Danach Trace On aktivieren, genau einen HTTPS-Aufruf, Transfer oder Anwendungsstart reproduzieren und mit Trace Off stoppen:

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.
Wiederholte TCP-Pakete oder fehlende Antworten können auf Paketverlust, MTU/MSS, WAN-Qualität oder Überlast hinweisen. Für eine belastbare Retransmission-Analyse braucht es eine PCAP-Datei und Wireshark.
Funktionieren kleine Tests, grosse Transfers aber nicht, Path-MTU-Discovery und Fragmentierung prüfen.

Die Bedienung erklärt Packet Capture im WebAdmin verwenden. Der WebAdmin-Buffer ist auf 2048 KB begrenzt und stoppt ohne Wrap capture buffer once full automatisch, sobald er voll ist. Captures und aktivierte Debug-Logs deshalb nur so lange wie nötig laufen lassen.

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.

Seit SFOS 22.0 berechnet Sophos Firewall 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. Prüfe vor dem Rollout mit der Vorbereitung für das Sophos Firewall Firmware Update den installierten Build, den unterstützten Upgradepfad und aktuelle buildspezifische Hinweise.

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

Die angezeigten MTU- und MSS-Werte vor dem Test genau dokumentieren; diese Werte werden für einen Rollback benötigt.

⚠️ 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.

Für physische und Wi-Fi-Interfaces dokumentiert Sophos diese Änderungssyntax. Sie ist nicht als Methode zum Ändern eines XFRM-Interfaces dokumentiert; XFRM deshalb im WebAdmin bearbeiten:

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.

Wurde für Port2 zuvor MSS 1460 dokumentiert, kann man in einem Wartungsfenster zunächst nur MSS auf den berechneten Testwert ändern:

set network mtu-mss Port2 mss 1452

Direkt danach mit show mtu-mss Port2 kontrollieren und denselben DF- und Anwendungstest wiederholen. Verschlechtert sich der Traffic oder bleibt die Verbesserung aus, wird in diesem Beispiel der gesicherte Ausgangswert wiederhergestellt:

set network mtu-mss Port2 mss 1460

War vor dem Test ein anderer MSS-Wert aktiv, muss genau dieser Wert statt 1460 eingesetzt und danach erneut mit show mtu-mss Port2 geprüft werden.

Alternativ setzt default 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.