What is the optimal MTU for WireGuard?

WireGuard sets its interface MTU to 1420 by default, which fits a standard 1500-byte path: 1500 minus 60 bytes of IPv6 outer header and 8 bytes of UDP leaves 1432, and WireGuard reserves a further margin to land on 1420. That value works on most fibre and cable links. If your underlying link carries less than 1500 bytes — PPPoE DSL (1492), most mobile/5G, or a tunnel inside another tunnel — you must lower it. Do not guess: measure the path with a do-not-fragment ping and subtract WireGuard's 80-byte overhead.

Why does WireGuard connect but no internet or web pages load?

The single most common cause when the handshake completes but traffic stalls is MTU. Small packets (a ping, a DNS lookup, the TCP handshake) fit and succeed, so the tunnel looks alive. Large packets (a full web page, an SSH file transfer, an image) exceed the path MTU, get dropped, and because ICMP 'fragmentation needed' is often filtered, nothing ever tells the sender to shrink. The result is a tunnel that pings fine but hangs on anything big. Lowering the WireGuard MTU fixes it.

How do I find the correct MTU value?

Run a do-not-fragment ping to the server's real address, shrinking the payload until it stops failing: `ping -M do -s 1472 SERVER_IP` (1472 + 28 bytes of ICMP/IP header = 1500). If 1472 fails, drop to 1464, 1400, and so on until a reply comes back. Take the largest payload that succeeds, add 28 to get the path MTU, then subtract 80 for WireGuard's overhead. Example: largest working ping payload 1400 → path MTU 1428 → WireGuard MTU 1348 (round down to a safe 1340).

What value should I use for PPPoE or mobile connections?

PPPoE (most DSL) caps the path at 1492 bytes, so a WireGuard MTU of around 1412 fits, and 1400 is a safe round number. Mobile, 5G and CGNAT links vary and often carry less; 1280 is the IPv6 minimum every path must support and is the bullet-proof fallback when you cannot measure. Set MTU = 1280 on the client interface and the stall disappears, at a small cost in per-packet efficiency.

Should I change MTU on the client or the server?

Change it on the side whose link is constrained — usually the client (your home, mobile or office connection). The WireGuard MTU only affects packets that interface sends, so lowering it on the roadwarrior client is enough in most setups. If the server itself sits behind a smaller-than-1500 uplink, lower it there too. When in doubt, set a conservative MTU on the client first and test before touching the server.

WireGuard MTU: the right value and how to fix the stalled tunnel (2026)

Affiliate disclosure — This post contains Contabo affiliate links. If you grab a VPS through them, we earn a commission at no extra cost to you. Every command and value below is documented from official WireGuard sources and written to be reproducible on your own machine.

Your WireGuard tunnel says it is connected. wg show lists a fresh handshake, ping to the server answers instantly — and yet web pages spin forever, SSH freezes mid-transfer, and large downloads die at a few kilobytes. Nine times out of ten the culprit is MTU: the maximum packet size your tunnel can carry. This guide explains why MTU breaks a tunnel that otherwise looks perfectly healthy, how to measure the right value for your link, and exactly what to set.

If your handshake never completes in the first place, MTU is not your problem yet — start with the full WireGuard handshake fix list and come back here once the tunnel is up but stalling.

What MTU is and why WireGuard cares

MTU (Maximum Transmission Unit) is the largest packet, in bytes, that a network interface will send without fragmenting. On a normal Ethernet or fibre link it is 1500 bytes. WireGuard wraps every one of your packets inside its own UDP packet, and that wrapper costs space:

IPv4 outer header: 20 bytes
IPv6 outer header: 40 bytes
UDP header: 8 bytes
WireGuard data header: 32 bytes

So a WireGuard packet riding over IPv6 needs roughly 80 bytes of overhead. Take it off a 1500-byte path and you are left with about 1420 bytes of room inside the tunnel — which is exactly why WireGuard defaults its interface MTU to 1420. You can confirm the default on any running tunnel:

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

Two orange fiber-optic patch cables with metal ST connectors, the coiled cable labelled in the background

The trouble starts when the path between you and your server carries fewer than 1500 bytes. Then 1420 is too big, your real traffic overflows, and the overflow packets vanish silently.

Why the tunnel pings fine but pages hang

This is the signature symptom, and it confuses everyone the first time:

A ping is tiny — it fits inside any MTU, so it succeeds and convinces you the tunnel works.
A DNS lookup and the TCP three-way handshake are tiny too, so connections start.
The first full-size packet — a web page, an image, a file chunk — exceeds the path MTU and gets dropped.

Normally a router would send back an ICMP "fragmentation needed" message telling the sender to use smaller packets (this is Path MTU Discovery). But ICMP is filtered on a huge share of the internet, so that message never arrives. The sender keeps firing oversized packets into a black hole. That is a PMTU black hole, and it is why a tunnel can look alive and still be useless for real work.

The same logic explains the "connected but no internet" reports: small control traffic flows, large data does not. If you have ruled out IP forwarding and the masquerade rule (covered in the Contabo + WireGuard setup guide), MTU is the next suspect.

Measure the right MTU for your link

Do not copy a number off a forum. Measure your own path with a do-not-fragment ping to the server's real public IP (not its tunnel IP), shrinking the payload until packets get through:

# -M do = don't fragment, -s = payload size
ping -M do -s 1472 SERVER_PUBLIC_IP

The -s 1472 payload plus 28 bytes of ICMP+IP header equals 1500. If that fails with "message too long" or no reply, step down and try again:

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

On Windows the equivalent is ping -f -l 1472 SERVER_PUBLIC_IP; on macOS, ping -D -s 1472 SERVER_PUBLIC_IP.

Take the largest payload that succeeds, then do the arithmetic:

Largest working payload + 28 = your path MTU.
Path MTU − 80 = a safe WireGuard MTU (use 80 for the IPv6 case; IPv4-only paths can use −60, but −80 is the safe universal choice).

Worked example. Suppose -s 1400 is the largest that replies and -s 1408 fails. Path MTU = 1400 + 28 = 1428. WireGuard MTU = 1428 − 80 = 1348 → round down to a tidy 1340.

Set the WireGuard MTU

Add one line to the [Interface] block on the constrained side (usually the client) and restart the tunnel:

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

sudo wg-quick down wg0 && sudo wg-quick up wg0
# or, without a full restart:
sudo ip link set dev wg0 mtu 1340

Re-test immediately: load a heavy page, run a file transfer, or use a do-not-fragment ping through the tunnel to the server's tunnel IP. If big traffic now flows, you have your value. If you are building configs from scratch, the ready-to-use config templates include the MTU line in the right place for each platform.

Sensible values by link type

When you cannot measure — or want a safe starting point — these documented baselines cover most real-world links:

Link type	Path MTU	WireGuard MTU
Standard Ethernet / fibre / cable	1500	1420 (default)
PPPoE DSL	1492	1400–1412
Most mobile / 5G / CGNAT	varies, often <1400	1280
Tunnel inside another VPN/tunnel	reduced twice	1280
IPv6 guaranteed minimum (bullet-proof)	1280	1280

1280 is the value every IPv6-capable path is required to carry, so it is the safe fallback when nothing else works: you lose a little efficiency but the stall is gone. Always prefer a measured value when you can get one — 1280 leaves performance on the table on a clean 1500-byte path.

When MTU is not the answer

Lowering MTU is the fix when small packets work and large ones don't. If nothing flows after the handshake, the problem is elsewhere — check, in order:

net.ipv4.ip_forward = 1 and the MASQUERADE rule on the server.
Server-side AllowedIPs not overlapping between peers.
A PersistentKeepalive = 25 on any peer behind NAT.

All three are walked through in the handshake troubleshooting guide. And if you only need certain apps in the tunnel, lowering MTU pairs naturally with a split-tunnel routing setup so the bulk of your traffic skips the tunnel overhead entirely.

A clean link makes MTU predictable

Half of MTU pain comes from a messy path: double NAT, a flaky home router, a tunnel stacked on a tunnel. A VPS with a clean public IPv4 gives you a single, well-behaved hop where the standard 1420 default usually just works. A Contabo VPS S at €4.99/month gives you full root and a public IP with no provider firewall to fight — exactly the conditions where Path MTU Discovery behaves. Follow the step-by-step Contabo + WireGuard setup, and if you are still choosing a host, compare options in the Contabo vs Hetzner vs OVH VPS guide.

Going further

Sources and references:

Published 2026-06-24. Overhead figures are from the WireGuard protocol headers; the measurement method is standard Path MTU Discovery. Your link conditions differ — always confirm with a do-not-fragment ping before fixing a value.

Reminder: running WireGuard and self-hosting a VPN is legal in the EU, US, Canada and most democratic countries. VPNSmith publishes this content for educational purposes.

★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed

Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→