Veröffentlicht von In Zeiten des Coronavirus wird HomeOffice mit VPN endlich immer beliebter und mehr Firmen lernen hoffentlich, dass Menschen auch gut von zuhause arbeiten können. Aber manchmal scheitert das VPN an eigentlich schon gelösten MTU Probleme. Gerade Menschen hinter einem DS Lite Anschluss und / oder Nutzer eines L2TP/IPSec VPN (im schlimmsten Fall eine Kombination aus beiden) bemerken ein seltsames Verhalten. VPN Verbindung steht, der Zugriff auf manche Dienste geht, auf andere nicht. Hier lohnt sich manchmal doch ein Blick auf die MTU.
Als erstes ist es wichtig, eine funktionierende MTU für die VPN Verbindung herauszufinden. Hierbei kann uns "ping" helfen. Ping wird angewiesen, Frames mit einer bestimmten Größe und ohne Aufteilung an ein VPN internes Ziel zu schicken. Ist das Frame zu groß, bekommt ping keine Antwort. Sobald ping eine Antwort erhält, haben wir einen potentiell funktionierenden Wert für die neue MTU gefunden.
Windows
ping heise.de -f -n 1 -l 1492
- -f = Frame nicht fragmentieren
- -n 1 = Nur ein ICMP echo Frame schicken
- -l 1492 = Frame Größe
Ein nicht funktionierender Beispieloutput:
C:\Users\Micha>ping heise.de -f -n 1 -l 1492
Pinging heise.de [193.99.144.80] with 1492 bytes of data:
Packet needs to be fragmented but DF set.
Ping statistics for 193.99.144.80:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
Ein funktionierender Beispieloutput:
C:\Users\Micha>ping heise.de -f -n 1 -l 1432
Pinging heise.de [193.99.144.80] with 1432 bytes of data:
Reply from 193.99.144.80: bytes=1432 time=19ms TTL=246
Ping statistics for 193.99.144.80:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 19ms, Average = 19ms
Nun haben wir einen Wert gefunden, in dem Beispiel 1432, und müssen diesen Wert noch für die VPN Verbindung einstellen. Dafür müssen wir erst mal den Namen der VPN Verbindung herausfinden. Folgendes in einer administrativen CMD eingeben:
C:\Users\Micha>netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
69 25 1500 connected FirmenVPN
30 25 1500 connected Ethernet
1 75 4294967295 connected Loopback Pseudo-Interface 1
25 25 65536 connected Npcap Loopback Adapter
12 35 1364 disconnected Ethernet 6
29 65 1500 disconnected Bluetooth Network Connection 3
Aus dieser Liste wird der Name der VPN Verbindung gesucht. In diesem Beispiel "FirmenVPN". Mit folgendem Befehl wird die MTU für das "FirmenVPN" dauerhaft auf 1432 gesetzt:
netsh interface ipv4 set subinterface "FirmenVPN" mtu=1432 store=persistent
Linux
Da die herangehensweise unter Windows schon ausführlich beschrieben steht, hier nur die Zusammenfassung.
Passende MTU mit ping finden:
~# ping -c 1 heise.de -s 1432
PING heise.de (193.99.144.80) 1432(1460) bytes of data.
1440 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=246 time=15.1 ms
--- heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.123/15.123/15.123/0.000 ms
- -c 1 = Nur ein ICMP echo Frame schicken
- -s = Frame Größe
MTU einstellen
~# sudo ip link set dev FirmenVPN mtu 1432
Es kann sein, dass die MTU nicht gespeichert wird und bei jedem Start der VPN Verbindung neu gesetzt werden muss. Abhilfe kann hier der NetworkManager schaffen. Entweder lässt sich die VPN Verbindung mithilfe eines Dispatcher Scriptes dazu veranlassen, jedesmall die MTU zu setzen oder nmcli erlaubt das setzen einer MTU Größe für diese Verbindung.
Um per nmcli die MTU setzen zu können, müssen wir erst mal herausfinden, wie der Name für die MTU Konfiguration im NetworkManager heißt. Je nach Art der Verbindung, kann der Name ein anderer sein.
nmcli con show vpn-work | grep -i mtu
802-3-ethernet.mtu: auto
MTU anpassen:
nmcli con modify vpn-work 802-3-ethernet.mtu 1432
Sollte es danach immer noch nicht gehen, muss eventuell die TCP MSS angepasst werden. Das geht sehr einfach per iptables. Die folgende Regel passt die TCP MSS automatisch der eingestellten MTU an.
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Und der Befehl um die Regel zu löschen
iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
In einigen Fällen brauchte ich eine Anpassung der MTU und TCP MSS um auch wirklich Zugriff auf alle Dienste zu bekommen. Die TCP MSS Regeln lassen sich am besten per NetworkManger Dispatcher Script anwenden. Der NeworkManager bietet keine eigene Konfigurationsmöglichkeit für die TCP MSS.
Fazit
Man könnte meinen, dass mit PathMTU Discovery Probleme dieser Art der Vergangenheit angehören. Doch leider wird es immer noch nicht durchgehend unterstützt. Ich hoffe dem ein oder anderen hiermit wenigstens ein bisschen helfen zu können.
wpDiscuz