WireGuard MTU: Tunnel Up, Pages Hang? Find Yours in 1 Ping

Handshake OK but sites stall? WireGuard's default MTU 1420 is too big on PPPoE and mobile. One do-not-fragment ping finds your value, plus a free calculator.

By Eric GerardFounder · VPNSmith - Self-host VPN & GDPR VPS specialist

Updated 10 min read10 min

Affiliate links: we may earn a commission, at no extra cost to you. Method

Generate my configRead the guide

fig. 01 / self-host-vpnencrypted tunnelUDP 51820DEVICE10.8.0.2SERVER10.8.0.1INTERNETNATAllowedIPs = 0.0.0.0/0, ::/0ListenPort = 51820 (server)
fig. 01 / self-host-vpn

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.

fig. 01 / self-host-vpnencrypted tunnelUDP 51820DEVICE10.8.0.2SERVER10.8.0.1INTERNETNATAllowedIPs = 0.0.0.0/0, ::/0ListenPort = 51820 (server)
fig. 01 / self-host-vpn

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...

Network patch panel with rows of red Ethernet patch cables connected
Network patch panel with rows of red Ethernet patch cables connected

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.

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:

  1. Largest working payload + 28 = your path MTU.
  2. 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.

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

Link typePath MTUWireGuard MTU
Standard Ethernet / fibre / cable15001420 (default)
PPPoE DSL14921400-1412
Most mobile / 5G / CGNATvaries, often <14001280
Tunnel inside another VPN/tunnelreduced twice1280
IPv6 guaranteed minimum (bullet-proof)12801280

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 = 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.

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

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. 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

Price checked 17 Oct 2026, 24-month term

Frequently asked questions

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 40 bytes of outer IPv6 header, 8 bytes of UDP and 32 bytes of WireGuard framing (a 16-byte data header plus the 16-byte authentication tag) leaves exactly 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.