Um es erstmal einfach zu sagen, die WireGuard Default MTU Size ist 1420. Generell ist das auch ein Wert der in 95% der Einsatzfälle funktionieren wird. Allerdings gibt es einiges zu beachten wenn die Umgebung ein wenig komplexer ist und über mehrere Hops geht. Aber wie lässt sich die MTU korrekt berechnen? Schwierige Frage, denn jeder muss das für sich selber beantworten. Aber lest nun selber.
Default WireGuard MTU 1420 Bytes
Empfehlung WireGuard MTU 1412 Bytes
WireGuard fähiger Reise Router oder auch als günstiger Edge Router zu gebrauchen.
Technische Infos zur MTU Zusammensetzung
Erstmal ist zu beachten über was für eine Internetleitung geht die Verbindung? DSL, vDSL oder Kabelinternet? Deswegen hier die erste Grundlage.
DSL & vDSL maximale MTU 1492
Kabel Internet maximale MTU 1500
Das sind die Vorgaben unser deutschen Provider. Also größere Pakete können ohnehin nicht angenommen werden vom ISP.
Jetzt liste ich euch die Header-Größen auf welche Wireguard bzw. das VPN benötigt.
IPv4 VPN – 20 Bytes
IPv6 VPN – 40 Bytes
UDP – 8 Bytes
WireGuard – 32 Bytes
Mit diesen Infos könnt Ihr nun eure passende MTU Size berechnen. Ich mache für euch mal ein normales Beispiel und ein unnormales Beispiel.
Beispiel 1
Ausgangslage ist eine Kabel Anbindung mit 1500 maximaler MTU welche mit IPv4 Verbindung ausgestattet ist.
1500 – 20 Bytes (IPv4) – 8 Bytes (UDP) – 32 Bytes (WG) = 1440 Bytes
Somit wäre für den Datenbereich 1440 Bytes übrig und der Defaultwert 1420 würde sehr gut passen.
Beispiel 2
Ausgangslage ist eine DSL Anbindung mit 1492maximaler MTU welche mit IPv6 Verbindung ausgestattet ist.
1492 – 40 Bytes (IPv6) – 8 Bytes (UDP) – 32 Bytes (WG) = 1412 Bytes
Somit wäre für den Datenbereich 1412 Bytes übrig und der Defaultwert 1420 würde nicht passen.
Im Beispiel 2 würden jetzt die Datenpakete getrennt werden und somit Fragmentiert. Das verbraucht Leistung und die Verbindung wird deutlich langsamer. Doch wenn man IPv6 einsetzt wird es schon sehr knapp.
Weitere Informationen und Tipps
Wenn IPv6 im Spiel ist erfordern einige Router eine minimale Größe der MTU von 1280 Bytes. Also wenn Ihr IPv6 im Einsatz habt, bitte nicht unter 1280 Bytes gehen.
Wenn Ihr in einer komplexen Umgebung Arbeitet mit mehreren NATs und/oder Routern kann es sein das euren Pakete noch mehr Header hinzugefügt werden. Dann wird die Berechnung natürlich noch kompliziert. WireShark kann euch aber hier gut helfen um zu sehen ob die Pakete noch zerteilt werden.
Startet doch einfach mal bei einer MTU Size von 1300 und arbeitet euch nach und nach an die 1420 heran. Viele berichten das für Sie 1380 Bytes sich als ideal ausgezeichnet hat.
Mit Tracepath könnt Ihr den pmtu überprüfen und überprüfen wie eure Pakete übermittelt werden.
root@srv:~# tracepath 192.168.10.7 1?: [LOCALHOST] pmtu 1500 1: pfsense.schroederdennis.de 0.429ms 1: pfsense.schroederdennis.de 0.325ms 2: pfsense.schroederdennis.de 0.321ms pmtu 1420 2: 10.255.0.2 22.116ms 3: 192.168.10.7 26.128ms reached Resume: pmtu 1420 hops 3 back 3
Quellen: https://keremerkan.net/posts/wireguard-mtu-fixes/ https://wiki.freifunk-franken.de/w/MTU
7. Januar 2022 um 23:17 Uhr
WireGuard sucht doch automatisch die richtige MTU was in der Praxis für funktionierte. Warum manuell festlegen?
8. Januar 2022 um 00:10 Uhr
Das wäre mir allerdings neu das WireGuard die MTU selbst suchst. 1420 ist der Default Wert. Hast du Quellen wo das stehen soll?
16. Januar 2022 um 22:53 Uhr
Sorry du hast recht. Ich nutze bei mir immer 1420 und als ich die Konfiguration entfernt hatte, wurde immer noch 1420 genutzt. Daher dachte ich, dass es automatisch gesetzt wurde. Aber es ist der default :-/
20. Januar 2023 um 16:03 Uhr
Wenn ich im WireGuard-Client einen Hostname als Endpoint angebe (z.B. den myFritz-Namen des Geräts), dann versucht WireGuard nur Verbindungen zur IPv4, die im Hostnamen eingetragen ist.
Dumm nur, da mein Server wegen Carrier-grade NAT darüber nicht erreichbar ist. Trage ich die IPv6-IP ein, klappt alles wunderbar.
Ich hatte gelesen, dass die Entscheidung ob IPv4 oder IPv6 mit dem MTU-Wert beeinflusst werden könnte. Ich hatte aber keinen Erfolg und auch AVM ist nicht bekannt, dass WireGuard IPv4 präferiert.
Habt ihr auch solche Beobachtungen gemacht?
1. Februar 2023 um 22:58 Uhr
Ja, ist leider so.
Aber wenn Du MyFRITZ als DynDNS nutzt, wird eine IPv4 CGN nicht mehr im DNS eingetragen. Damit findet der Client nur noch einen AAAA Record für IPv6 und gut ist.
Wer den AVM eigenen DynDNS nicht nutzen möchte, muss halt zusehen, dass im Name Server kein A Record gesetzt wird.
13. Februar 2024 um 15:54 Uhr
Danke für den Artikel 🙂
MTU von 1380 hat mein Problem gelöst.