Who Picks the WireGuard MTU: wg-quick, the Kernel or You

WireGuard has no MTU negotiation. It encrypts whatever the interface hands it and sends the result, and if the encapsulated packet exceeds the path, it is dropped or fragmented somewhere you cannot see. Someone has to choose the interface MTU, and that someone is the tool that brought the interface up.

Three candidates exist, and they are easy to confuse.

Three places the value can come from

The value can be set explicitly in the interface configuration, computed by the setup tool from route information, or set by whatever network manager owns the interface. A plain wg invocation does none of these, because wg only manages keys and peers. The MTU lives on the network interface, which is why ip link show wg0 is where you read it.

If you are unsure which one applies, read the MTU first, then find out who started the interface.

Decide by who runs the interface

If wg-quick starts it, an explicit MTU line wins and otherwise it computes a value. If a network manager starts it, that manager's profile decides. If a container runtime or a provider client starts it, read their documentation rather than assuming wg-quick behaviour.

The decision is not which number is best in the abstract. It is which component you can actually configure.

What the default calculation does

wg-quick looks up the route to the peer's endpoint, takes the MTU of that outgoing interface, and subtracts the encapsulation overhead. With an IPv4 outer header that is about 60 bytes; with IPv6 it is about 80. The result is capped so a 1500-byte path yields 1420 rather than a value that only works on one address family. That is a reasonable default, not a measurement of your path.

It cannot know about a later tunnel, a mobile link or a filtered ICMP path.

The cap hides a real question. If your path is genuinely 9000 bytes end to end, 1420 leaves performance on the table, and if the path is 1400, 1420 is already too large. The default is a compromise, and it should be treated as one.

When the path changes under you

A laptop that roams from Ethernet to Wi-Fi to a phone hotspot keeps the interface MTU it started with. The outer path may now be smaller, and nothing renegotiates. Nested tunnels make it worse, because each layer subtracts its own overhead from the same budget. The value that worked at the office is not the value that works at the airport.

A recent handshake proves the keys work. It proves nothing about whether large packets fit.

Test one number at a time

Keep the same application and destination, change one value, and measure. ping -M do -s 1372 tests a 1400-byte packet with the DF bit set, which is the shape of test you want. If small requests work and large ones stall, you have a size problem rather than a routing one.

Change the MTU alone. Adjusting several packet options together tells you nothing about which one mattered.

And do not expect an MTU change to fix a missing return route, a forwarding rule or a DNS failure. Those produce no-traffic symptoms too, and they have their own tests. The wg-quick manual documents the automatic selection.