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. The usual 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.
Want the number straight away? The WireGuard MTU calculator works it out from your connection type (Ethernet or fiber, PPPoE, 4G/5G, or a tunnel inside another VPN) and writes the [Interface] lines to paste, plus the ping test that confirms the value.
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...
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
pingis 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.
Rather not do the arithmetic by hand? Our free WireGuard MTU calculator takes the largest payload that passed, or your link type, and returns the MTU line plus the apply and test commands for Linux, Windows and macOS.
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.
Using our WireGuard config generator? It does not write an MTU line, so its files start on the 1420 default. Add the line to the client file before you import it; if you scanned its QR code on a phone, edit the tunnel in the WireGuard app and fill in the MTU field instead. The generator is free with no account, up to 250 devices, and its ZIP export holds every client .conf and its QR code as a PNG, handy to set up a whole office or family in one go.
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.
The same table, with IPv4 and IPv6 endpoint values side by side and the ping -M do test, is in our free WireGuard Cheat Sheet (5-page PDF, direct download, no sign-up), so you have it at hand when the tunnel is down and this page is out of reach. The paid WireGuard Self-Hosting Kit (9 USD) adds the 12-cause troubleshooting checklist and the config templates.
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 = 1and theMASQUERADErule on the server.- Server-side
AllowedIPsnot overlapping between peers. - A
PersistentKeepalive = 25on 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 Cloud VPS 4 at €5.50/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. If you would rather have a US host with a 30-day money-back guarantee, Ultahost VPS Basic is 5.52 $ a month on a 24-month term (1 GB RAM, dedicated IPv4, read on 21 October 2026), enough for a WireGuard server for a few devices. Cheapest option: a HostPapa Unmanaged VPS Lite (affiliate link) at 2.95 $ a month on a 3-year term, then the regular rate (1 core, 1 GB RAM, 25 GB NVMe, root SSH access, 30-day money-back guarantee, read on 28 October 2026).
To start from a clean pair of configs on that server, our free WireGuard config generator generates matching server and client files in your browser.
Generate your WireGuard configs here
Type your server address, choose the number of devices, then scan each QR code from the app.
All keys are generated in your browser (Curve25519 / X25519). Nothing is sent to our servers - your config stays 100% private.
Public IPv4 or domain of the machine that will run WireGuard. No server yet? Leave it empty and add it later.
Free, no account: up to 250 clients, each .conf with its QR code, and one ZIP with every file.
Everything the device sends to the internet goes through your server.
Advanced settingsTunnel subnet, DNS, site-to-site LANs. The defaults work for most setups.
Optional. Enter the LAN subnet behind the server and/or behind a client that acts as a site gateway (a router, a Raspberry Pi, a NAS). The generator adds each LAN to the server's AllowedIPs, gives every peer the routes to the other LANs, and writes the forwarding rules on the gateways. Leave a field empty for a normal client.
What you download
wg0.conf
for the server
client1.conf
one per device
QR (sample)
for the phone app
Illustration only: the lines and the QR code are fictional, no real key. Your real files are generated in your browser when you click.
Your VPN hides your IP. It does not hide your browser.
A correctly configured WireGuard tunnel replaces the address a site sees. It changes nothing about what your browser announces on its own: fonts, screen, time zone, graphics stack. That combination is often unique enough to follow you across sessions, tunnel or no tunnel.
Measure your own browser fingerprint, passive, no questions, no account, no email. It tells you how many browsers out of N look like yours, and which attribute makes you stand out.
Going further
- WireGuard handshake did not complete: the full fix list
- What port WireGuard uses and how to open it
- Ready-to-use WireGuard config templates 2026
- Self-host VPN on Contabo: full WireGuard guide 2026
- Split-tunnel VPN with routing tables
- Self-hosted VPN glossary - AllowedIPs, MTU, NAT explained
Sources and references:
- WireGuard whitepaper - Jason A. Donenfeld
- WireGuard quickstart and wg-quick docs
- Arch Wiki - WireGuard (MTU notes)
- RFC 8200 - IPv6 minimum MTU 1280
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. VPNSmith publishes this content for educational purposes.
MTU problems often trace back to the path your host takes, not to your client. Our cheapest-VPS comparison lists the providers and the networks behind them.
Affiliate link
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200 Mbit/s port
Self-host your VPN on your own VPS → ContaboCloud VPS 4 · 5,50 €/mo · Card or PayPal · orders from outside the EU accepted→Price checked 17 Oct 2026, 24-month term


