Wireguard MTU limitation on a server / forwarding peer

[Tom Yan]

Hi all,

So I notice that wg-quick (and the Windows client) will use (the MTU
of the default route interface - 80) as the MTU of the tunnel
interface. Although I've read a mail about where the 80 comes from, I
don't exactly know why the MTU of the tunnel interface needs to be
that. I assume that it's for a reason like "to avoid encapsulated
packets from being needed to be fragmented locally".

I also notice that if on a server / forwarding peer, the MTU of the
default route interface is smaller than the usual 1500, say 1460, and
hence the MTU of the tunnel interface is capped at 1380, on its client
peers I pretty much also need to cap the tunnel interface MTU at that
(instead of letting it "falling back" to the usual 1420), seemingly
have something to do with TCP MSS (which might be possible to
workaround/fix with an ip/nftable rule instead I guess).

My biggest doubt is however, whether I should "sync" the tunnel
interface MTU of all peers. Say that on a / the server / forwarding
peer is the usual 1420 by default, but it's known that it will serve /
forward for client peers whose tunnel interface MTU would be as small
as / needs to be capped at, say 1280. Should I set the tunnel
interface MTU on the server / forwarding peer (and hence all of its
other client peers) to 1280? (If it matters, say I don't need
"client-to-client" communication.)

(As you may have guessed, the "trigger" of this question / mail is
that the default MTU used by the Android wireguard client is 1280.
Although it's perhaps fine to bump it to 1420 on many devices, I do
notice that at least on one of my phones the MTU of the cellular
interface is apparently 1400.)

Regards,
Tom