What MTU should a WireGuard tunnel use, and why do some sites hang over it?

Take the smallest MTU on the path between the two WireGuard endpoints and subtract 80 if the endpoint is reached over IPv6, or 60 if over IPv4 only. On a 1500-byte Ethernet, fibre or cable uplink that gives 1420, the default everyone sees. Set it on both ends, not only the client, and use 1280 if you cannot measure.

If the tunnel connects and pings but some sites or TLS handshakes hang forever, the MTU is too big for the path.

Where 1420 comes from#

wg-quick's set_mtu_up takes the MTU of the route to each peer endpoint, or of the default route if no endpoint is known, and runs ip link set mtu $(( mtu - 80 )). The manual calls this "usually a sane choice"; an MTU = line overrides it.

The 80 is the IPv6 worst case, which Tailscale's source spells out field by field:

So both circulating answers, "1420 is always right" and "PPPoE needs 1412", are wrong half the time. Over an IPv4 endpoint, 1420 plus 60 is 1480, which fits a 1492-byte PPPoE link. Over IPv6, 1420 plus 80 is 1500, 8 bytes too many. 1412 is right for IPv6 and wastes 20 bytes per packet on IPv4.

The automatic value also sees only the first hop, unless the kernel has already learned a path MTU for that route: a machine on a LAN behind a PPPoE router has a 1500-byte route and gets 1420. A hub whose peers have no Endpoint line, like an wg-easy server, uses the default route and gets 1420 whatever uplink each client is on. In our lab the client on a 1492-byte link came up at 1412 and its server at 1420.

The value per uplink#

The last column is what wg-quick picks on a computer behind the router, which sees a 1500-byte route whatever the uplink.

The PPPoE figure is RFC 2516's: the PPP MTU "MUST NOT be greater than 1492". DS-Lite carries IPv4 inside IPv6, 40 bytes more, and RFC 6333 makes the home router fragment rather than drop what no longer fits, so an oversized tunnel over DS-Lite IPv4 still works, as fragments. A server on DS-Lite has no public IPv4 address of its own and is reached over IPv6 anyway.

The LTE row is the soft one. 3GPP TS 23.060 says a link MTU of 1358 is small enough in most network deployments, derived from GTP inside IPsec over a 1500-byte transport network. What a carrier actually sets varies, so test on mobile above all. If the path really is 1358, only an IPv4 endpoint carries a 1280-byte inner packet in one piece.

Why ping works and TLS hangs#

We built the failure in network namespaces on kernel 5.4 with its WireGuard module and wireguard-tools v1.0.20250521: a client behind a 1492-byte link standing in for PPPoE, a server, and an HTTPS server behind it with a 4096-bit RSA certificate. Each run fetched a 3-byte and a 200 KB file with an 8-second timeout.

A default ping is 84 bytes. The first full-size packet in an HTTPS connection carries the server's certificate, which is why the 3-byte file failed exactly like the 200 KB one.

IPv4 and IPv6 differ because WireGuard's socket.c sends outer IPv4 packets with the don't-fragment flag cleared, so a router splits an oversized packet instead of dropping it. IPv6 routers never fragment; the sender has to receive a Packet Too Big and shrink. An oversized tunnel therefore works until something on the path drops IPv4 fragments or filters ICMPv6.

Lowering only the client did not fix it#

With the client at 1412 and the server left at 1420, the IPv6 path still hung. tcpdump on the router showed 1,452-byte UDP payloads coming from the server: 1420 bytes of inner packet plus WireGuard's 32.

The cause is in the kernel's send.c. WireGuard pads every packet to a multiple of 16 bytes, capped at the sending interface's MTU. The client's MTU limited the server's TCP segments to 1412-byte packets, the server's 1420 MTU let padding round them up to 1420, and 1420 does not fit. With the client at 1408, a multiple of 16, the same setup worked.

So on a hub, lower the server's interface MTU to the smallest value any client needs, as well as the client's own, or give clients on bad links a multiple of 16.

Testing your own path#

From the client, with the tunnel down, find the biggest packet that reaches the server with fragmentation forbidden. -s is the payload; add 28 for IPv4 or 48 for IPv6.

# IPv4 endpoint: 1464 + 28 = 1492 bytes
ping -M do -c 3 -s 1464 vpn.example.com
# IPv6 endpoint: 1444 + 48 = 1492 bytes
ping -6 -M do -c 3 -s 1444 vpn.example.com

Raise -s until replies stop. On our 1492-byte link, 1464 worked and 1465 failed locally with ping: sendmsg: Message too large. When the small link is further away the error may never come back, so the limit is the largest size that still gets replies. The -M do flag is iputils ping; BusyBox ping, as in Alpine-based Docker Engine images, rejects it.

Subtract 60 or 80 from that packet size, set the MTU on both ends, and check inside the tunnel with the MTU minus 28:

ping -M do -c 3 -s 1384 10.8.0.1   # for MTU 1412

This works even when ICMP is filtered, because a too-large tunnel packet just gets no reply. In our broken setup at 1420, -s 1380 replied and -s 1381 did not: padding again, 1409 bytes rounded up to the cap.

Where wg-easy v15 keeps the MTU#

Not in an environment variable: neither the optional configuration page nor the unattended setup variables list one. In the v15.5.0 source the value lives in the database, seeded at 1420 for the interface and for new clients, in three places in the web UI:

• Admin Panel, Interface, MTU: "MTU WireGuard will use", the server's wg0.
• Admin Panel, Config, MTU: "MTU clients will use (only for new clients)".
• Each client's edit page, MTU: the value written into that client's config.

wg-easy writes the MTU = line explicitly, so wg-quick's calculation never runs. Changing the Config default leaves existing clients at 1420: edit each one, then import the new config or rescan the QR code on the device. Saving the Interface page runs wg syncconf on the stripped config, and wg-quick strip removes MTU, so in the source the running interface keeps its old value until Restart Interface, which disconnects every client. We read that in the code and did not test it; ip link show wg0 inside the container shows what is in force.

When the fix is MSS clamping instead#

The same symptom can appear with a correct tunnel MTU, when a router puts a whole LAN through WireGuard, as in a site-to-site setup. Machines on that LAN announce a 1460-byte TCP segment size, websites send 1500-byte packets that do not fit the 1420 tunnel, and the far end of the tunnel has to send an ICMP "fragmentation needed" back to the website.

With that ICMP dropped at the web server, the first HTTPS connection from the LAN machine stalled at the handshake in each of our three runs; later ones sometimes got through, so a site that loads on the second try proves nothing. Clamping the MSS on the client router fixed it from the first connection:

iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Clamping does nothing when the encrypted packets themselves are too big for the uplink. A device running the WireGuard client itself, such as a phone, already announces a segment size that fits.

When this answer stops applying#

• UDP inside the tunnel. TCP is the only traffic the segment size limits. Large UDP packets still depend on the MTU being right.
• Other WireGuard implementations. The padding and don't-fragment behaviour above is the Linux kernel module's. wireguard-go, which Tailscale's client and therefore Headscale networks run on, was not tested.
• Router operating systems. OpenWrt, OPNsense and MikroTik have their own MTU fields and were not tested. The arithmetic is the same.
• We did not test real PPPoE, DS-Lite or LTE links, only links set to their sizes, or wg-easy itself.

What to do next#

Run both ping tests from the device on its worst connection, usually a phone on mobile data, set the result on the server's interface and on that client, and use 1280 for anything you cannot measure. Headscale vs wg-easy covers what else differs between a WireGuard hub and a mesh, and Remote access without port forwarding whether you can reach the endpoint at all behind CGNAT or DS-Lite. If the tunnel's subnet collides with a Docker network, Docker subnet clashes and address pools fixes that, and DNS for self-hosters makes names resolve on both sides of the tunnel.