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
