WireGuard MTU: what to set and why 1420

Leave the WireGuard MTU at 1420 unless a test shows your path cannot carry it. 1420 is the 1500-byte Ethernet MTU minus 80 bytes of tunnel overhead, the worst case across IPv4 and IPv6.

MTU

The MTU (maximum transmission unit): the largest packet, in bytes, that a link or interface carries in one piece. Anything bigger is fragmented or dropped.

What MTU should WireGuard use?

Use 1420 on a normal 1500-byte path, and the path MTU minus 80 on any smaller one. A WireGuard packet is wrapped in a UDP packet and an outer IP header, so the interface must advertise a smaller MTU than the link under it. If it advertises too much, the outer packet no longer fits.

The wg-quick manual says that when MTU is not set, the tool works one out from the endpoint addresses or the system default route, "which is usually a sane choice". That is why most tunnels never need the line. You touch it when something on the path is narrower than Ethernet, or when large transfers stall.

Short version, case by case:

• Ethernet, nothing odd: leave the default.
• PPPoE or another tunnel underneath: subtract the extra header from 1500, then 80.
• Large transfers freeze while pings work: measure the path (below) before changing anything.

Where does 1420 come from?

1420 is 1500 minus 80, and 80 is the biggest the overhead gets. Every encrypted packet carries an outer IP header, an 8-byte UDP header and a 32-byte WireGuard header plus authentication tag. The whitepaper describes the transport message: a type, a receiver index and a counter in front of the encrypted payload, followed by a 16-byte Poly1305 tag. The outer IP header is 20 bytes for IPv4 and 40 for IPv6.

One value serves both families, because the interface MTU is fixed before you know which family the outer packet will use: an endpoint can be reached over IPv4 now and IPv6 after a roam. Picking the IPv6 figure costs 20 bytes per packet on IPv4 and guarantees that nothing is oversized on either. Mind the floor, too. RFC 8201 says IPv6 requires every link to carry at least 1280 bytes, so a tunnel that carries IPv6 cannot go below 1280.

Should the MTU be 1500 or 1492?

Neither: 1500 and 1492 are link sizes, not tunnel sizes. A normal Ethernet link carries 1500. A link run over PPPoE (point-to-point protocol over Ethernet, the login layer many DSL and fibre lines use) carries 1492, because PPPoE spends 8 bytes of every frame on its own header.

The tunnel then needs 80 less than whatever the link carries:

1. Ethernet: 1500 minus 80 gives 1420.
2. PPPoE: 1492 minus 80 gives 1412.

If you leave a tunnel at 1420 on a PPPoE line, a full-size inner packet becomes a 1500-byte outer packet that the 1492 link cannot carry. Whether that is fragmented, dropped or reported depends on the hops after your router, and that is where the trouble starts.

How do you find the working MTU on your path?

Send pings that may not be fragmented, and step the size down until they pass. The DF (don't fragment) bit makes an oversize packet fail instead of splitting, so a failure tells you the size is too big.

1. Pick a host on the far side of the path. For the tunnel, use the peer's tunnel address; for the underlay, use the endpoint.
2. On Linux, run ping -M do -s 1392 <host>. The -s value is payload; the packet is 28 bytes larger (20 IPv4 header, 8 header of ICMP, the control-message protocol that ping uses).
3. If it fails or times out, lower the size and run it again. A binary search converges in a few tries.
4. Note the largest payload that gets replies. Add 28 to get the largest IP packet the path carried: that is the path MTU.
5. Subtract 80 from the underlay path MTU for the interface value. If you tested through the tunnel, the largest passing packet already is the interface value.
6. Retest with a real transfer, not only ping. Ping packets are small enough to hide some failures.

On macOS the DF flag is -D and on Windows it is -f -l <size>; the logic is the same. tracepath reports the discovered path MTU on Linux without you stepping by hand, but only if the "too big" notices reach it, which is the exact thing that fails in a blackhole.

Where do you set the MTU?

Set it on the interface the tunnel owns; the method depends on the platform.

• wg-quick: add MTU = 1412 to the [Interface] section, then bring the interface down and up.
• Plain ip: ip link set mtu 1412 dev wg0. It takes effect at once and does not survive a restart.
• Router: use the router's own tunnel interface setting. For RouterOS, see what the MTU does to a MikroTik tunnel.
• A phone or desktop client: most apps choose the value for you; if a client exposes the setting, it is on the tunnel's own screen.

Lower is safe, if slightly wasteful. Higher is where the risk sits.

What does a path that drops large packets do to a tunnel?

In the lab on 2026-10-29, a tunnel whose path silently dropped large packets kept small ones working and stalled a bulk transfer completely. We wanted to see where the line falls, and what a user would feel.

The line fell between a 1235-byte and a 1236-byte inner packet, where the outer packet crossed the drop size; every larger size failed, up to the full 1420 interface. The sender got no error or notice. The line sits a little under 1239, the 1300 minus 60 an IPv4 reader would expect, because this rig's tunnel carries a few more bytes per packet than plain WireGuard; the 80-byte rule covers that.

With the drop on, a 200-byte request completed at once, and a 5,000,000-byte transfer stalled after 0 bytes and hit our 8-second timeout. The tunnel interface read 1420 before and after, so nothing lowered it on its own in this rig.

The assessor, the part of the app that rates a connection, called the 1300 path Degraded. With the drop moved up to 1461 bytes, ordinary traffic flowed and the passive verdict was Working, but full-size packets were still lost, so a Working verdict does not prove the path carries full-size packets. The "Small packets pass, large ones don't." message was not shown in this rig.

Why does path MTU discovery fail, and what replaces it?

Path MTU discovery (PMTUD) relies on a router sending back a "too big" notice, and a path that drops that notice leaves the sender guessing forever. RFC 1191 defines it for IPv4 with ICMP "fragmentation needed", and RFC 8201 does the same for IPv6 with "Packet Too Big".

When a firewall on the path filters ICMP, the sender never gets the notice. Small packets keep passing, large ones disappear, and nobody is told. That is the blackhole in the lab above. It also explains why a ping can look healthy: ping packets are small.

Two RFCs cover the fix that does not depend on those notices. RFC 4821, packetization-layer PMTUD, has the sender probe with larger packets and use the replies to find the limit. RFC 8899, datagram packetization-layer PMTUD (DPLPMTUD), does the same for datagram transports. Neither needs a router to speak up.

Should you clamp MSS instead of lowering MTU?

Clamp MSS when the problem is TCP and you control the router; lower the MTU when you want every protocol covered. MSS (maximum segment size) is a number each side of a TCP connection announces for the largest chunk it will accept. A router that rewrites it in the handshake makes both ends send segments that fit.

It needs no help from ICMP, so it is the usual router fix. Its limit: it rewrites TCP only. UDP traffic such as DNS over large answers or a game stream is untouched, and so is the tunnel's own UDP if the underlay is narrow. Lowering the interface MTU applies to all of it.

So the order is: measure the path, set the interface MTU to the path MTU minus 80, and add MSS clamping on a router if TCP still stalls.

Does ForestVPN set the MTU for you?

On computers the app may lower its packet size by itself where that is allowed; it never raises it. When it sees the blackhole pattern (the message code is net.mtu_blackhole), it shows "Small packets pass, large ones don't." Switching location does not fix this. The help page for that message explains it. The IPv6, DNS and MTU page covers the rest.

Phones and TV get the diagnosis only and the advice to try a different network.

For running the protocol yourself, WireGuard compared with OpenVPN and the WireGuard comparison page set it against using a service. The longer symptom list, including how the app words each state, is in VPN connected but no internet.