WireGuard MTU: der richtige Wert und wie man den hängenden Tunnel repariert (2026)

Affiliate-Hinweis — Dieser Beitrag enthält Contabo-Affiliate-Links. Wenn du über sie einen VPS holst, erhalten wir eine Provision ohne Mehrkosten für dich. Jeder Befehl und Wert unten ist aus offiziellen WireGuard-Quellen dokumentiert und so geschrieben, dass er auf deiner eigenen Maschine reproduzierbar ist.

Dein WireGuard-Tunnel meldet „verbunden". wg show zeigt einen frischen Handshake, der ping zum Server antwortet sofort — und doch drehen sich Webseiten endlos, SSH friert mitten in der Übertragung ein, und große Downloads sterben nach wenigen Kilobyte. Neun von zehn Mal ist der Schuldige die MTU: die maximale Paketgröße, die dein Tunnel transportieren kann. Diese Anleitung erklärt, warum die MTU einen ansonsten kerngesund wirkenden Tunnel zerbricht, wie du den richtigen Wert für deinen Anschluss misst und was genau du einstellst.

Wenn dein Handshake von vornherein nie zustande kommt, ist die MTU noch nicht dein Problem — beginne mit der vollständigen WireGuard-Handshake-Fehlerliste und kehre hierher zurück, sobald der Tunnel steht, aber stockt.

Was MTU ist und warum WireGuard das interessiert

MTU (Maximum Transmission Unit) ist das größte Paket in Byte, das eine Schnittstelle ohne Fragmentierung sendet. Auf einem normalen Ethernet- oder Glasfaseranschluss sind das 1500 Byte. WireGuard hüllt jedes deiner Pakete in sein eigenes UDP-Paket, und diese Hülle kostet Platz:

• Äußerer IPv4-Header: 20 Byte
• Äußerer IPv6-Header: 40 Byte
• UDP-Header: 8 Byte
• WireGuard-Datenheader: 32 Byte

Ein WireGuard-Paket über IPv6 braucht also rund 80 Byte Overhead. Zieh sie von einem 1500-Byte-Pfad ab, und es bleiben etwa 1420 Byte im Tunnel — genau deshalb setzt WireGuard seine Schnittstelle standardmäßig auf 1420. Bestätige den Standardwert auf jedem laufenden Tunnel:

ip link show wg0
# ... mtu 1420 ...

Der Ärger beginnt, wenn der Pfad zwischen dir und deinem Server weniger als 1500 Byte trägt. Dann ist 1420 zu groß, dein echter Verkehr läuft über, und die überzähligen Pakete verschwinden stillschweigend.

Warum der Tunnel auf Ping antwortet, aber Seiten hängen

Das ist das charakteristische Symptom, und es verwirrt jeden beim ersten Mal:

• Ein ping ist winzig — er passt in jede MTU, also gelingt er und überzeugt dich, dass der Tunnel funktioniert.
• Eine DNS-Anfrage und der TCP-Drei-Wege-Handshake sind ebenfalls winzig, also starten Verbindungen.
• Das erste volle Paket — eine Webseite, ein Bild, ein Dateistück — überschreitet die Pfad-MTU und wird verworfen.

Normalerweise würde ein Router eine ICMP-Nachricht „Fragmentierung nötig" zurücksenden, die dem Sender sagt, kleinere Pakete zu verwenden (das ist die Pfad-MTU-Erkennung, PMTUD). Aber ICMP ist auf einem riesigen Teil des Internets gefiltert, also kommt diese Nachricht nie an. Der Sender feuert weiter überdimensionierte Pakete in ein schwarzes Loch. Das ist ein PMTU-Blackhole, und deshalb kann ein Tunnel lebendig wirken und trotzdem für echte Arbeit unbrauchbar sein.

Dieselbe Logik erklärt die „verbunden, aber kein Internet"-Berichte: kleiner Steuerverkehr fließt, große Daten nicht. Hast du IP-Weiterleitung und die Masquerade-Regel ausgeschlossen (behandelt in der Contabo + WireGuard-Einrichtungsanleitung), ist die MTU der nächste Verdächtige.

Miss die richtige MTU für deinen Anschluss

Kopiere keine Zahl aus einem Forum. Miss deinen eigenen Pfad mit einem Ping ohne Fragmentierung an die echte öffentliche IP des Servers (nicht seine Tunnel-IP) und verkleinere die Nutzlast, bis die Pakete durchkommen:

# -M do = nicht fragmentieren, -s = Nutzlastgröße
ping -M do -s 1472 SERVER_OEFFENTLICHE_IP

Die Nutzlast -s 1472 plus 28 Byte ICMP+IP-Header ergibt 1500. Schlägt das mit „message too long" oder ohne Antwort fehl, geh herunter und versuch es erneut:

ping -M do -s 1464 SERVER_OEFFENTLICHE_IP
ping -M do -s 1400 SERVER_OEFFENTLICHE_IP
ping -M do -s 1372 SERVER_OEFFENTLICHE_IP

Unter Windows lautet das Äquivalent ping -f -l 1472 SERVER_OEFFENTLICHE_IP; unter macOS ping -D -s 1472 SERVER_OEFFENTLICHE_IP.

Nimm die größte Nutzlast, die durchkommt, und rechne:

1. Größte durchkommende Nutzlast + 28 = deine Pfad-MTU.
2. Pfad-MTU − 80 = eine sichere WireGuard-MTU (nimm 80 für den IPv6-Fall; reine IPv4-Pfade können −60 nehmen, aber −80 ist die sichere universelle Wahl).

Durchgerechnetes Beispiel. Angenommen, -s 1400 ist das größte, das antwortet, und -s 1408 schlägt fehl. Pfad-MTU = 1400 + 28 = 1428. WireGuard-MTU = 1428 − 80 = 1348 → auf saubere 1340 abrunden.

Setze die WireGuard-MTU

Füge eine Zeile zum [Interface]-Block auf der begrenzten Seite (meist der Client) hinzu und starte den Tunnel neu:

[Interface]
PrivateKey = ...
Address = 10.66.66.2/32
MTU = 1340

sudo wg-quick down wg0 && sudo wg-quick up wg0
# oder, ohne kompletten Neustart:
sudo ip link set dev wg0 mtu 1340

Teste sofort erneut: lade eine schwere Seite, starte eine Dateiübertragung oder mach einen Ping ohne Fragmentierung durch den Tunnel an die Tunnel-IP des Servers. Fließt großer Verkehr jetzt, hast du deinen Wert. Baust du Konfigurationen von Grund auf, enthalten die gebrauchsfertigen Konfigurationsvorlagen die MTU-Zeile an der richtigen Stelle für jede Plattform.

Sinnvolle Werte nach Anschlusstyp

Wenn du nicht messen kannst — oder einen sicheren Ausgangspunkt willst — decken diese dokumentierten Richtwerte die meisten realen Anschlüsse ab:

1280 ist der Wert, den jeder IPv6-fähige Pfad tragen muss, also der sichere Rückfall, wenn nichts anderes klappt: du verlierst etwas Effizienz, aber das Hängen ist weg. Bevorzuge immer einen gemessenen Wert, wenn du einen bekommst — 1280 lässt Leistung liegen auf einem sauberen 1500-Byte-Pfad.

Wann die MTU nicht die Antwort ist

Die MTU zu senken ist die Lösung, wenn kleine Pakete durchkommen und große nicht. Fließt gar nichts nach dem Handshake, liegt das Problem woanders — prüfe der Reihe nach:

• net.ipv4.ip_forward = 1 und die MASQUERADE-Regel auf dem Server.
• Server-seitige AllowedIPs ohne Überschneidung zwischen Peers.
• Ein PersistentKeepalive = 25 auf jedem Peer hinter NAT.

Alle drei werden in der Handshake-Fehlerbehebungsanleitung durchgegangen. Und wenn du nur bestimmte Apps im Tunnel brauchst, passt das Senken der MTU natürlich zu einer Split-Tunnel-Routing-Einrichtung, damit der Großteil deines Verkehrs den Tunnel-Overhead ganz umgeht.

Ein sauberer Anschluss macht die MTU vorhersehbar

Die Hälfte des MTU-Ärgers kommt von einem unordentlichen Pfad: Double-NAT, ein wackliger Heimrouter, ein Tunnel auf einem Tunnel. Ein VPS mit sauberer öffentlicher IPv4 gibt dir einen einzigen, wohlerzogenen Hop, wo der Standardwert 1420 meist einfach funktioniert. Ein Contabo VPS S für 4,99 €/Monat gibt dir vollen Root und eine öffentliche IP ohne Anbieter-Firewall zum Bekämpfen — genau die Bedingungen, unter denen die Pfad-MTU-Erkennung sich gut verhält. Folge der Schritt-für-Schritt-Einrichtung Contabo + WireGuard, und wenn du noch einen Anbieter wählst, vergleiche die Optionen im Contabo vs Hetzner vs OVH-Leitfaden.

Weiterführendes

• WireGuard-Handshake kommt nicht zustande: die vollständige Fehlerliste
• Welchen Port WireGuard nutzt und wie man ihn öffnet
• Gebrauchsfertige WireGuard-Konfigurationsvorlagen 2026
• Selbstgehostetes VPN auf Contabo: vollständige WireGuard-Anleitung 2026
• Split-Tunnel-VPN mit Routing-Tabellen
• Glossar für selbstgehostete VPNs — AllowedIPs, MTU, NAT erklärt

Quellen und Referenzen:

• WireGuard-Whitepaper — Jason A. Donenfeld
• WireGuard-Quickstart und wg-quick-Doku
• Arch Wiki — WireGuard (MTU-Hinweise)
• RFC 8200 — IPv6-Mindest-MTU 1280

Veröffentlicht am 2026-06-24. Die Overhead-Zahlen stammen aus den WireGuard-Protokollheadern; die Messmethode ist die Standard-Pfad-MTU-Erkennung. Deine Anschlussbedingungen unterscheiden sich — bestätige immer mit einem Ping ohne Fragmentierung, bevor du einen Wert festlegst.

Hinweis: WireGuard zu betreiben und ein VPN selbst zu hosten ist in der EU, den USA, Kanada und den meisten demokratischen Ländern legal. VPNSmith veröffentlicht diese Inhalte zu Bildungszwecken.