I have decided to use 1376 MTU for my wireguard connection as I'm seeing less latency and more bandwidth this way. My Windows PC is set with this command:
netsh interface ipv4 set subinterface Ethernet mtu=1376 store=persistent
OpenWRT router's wireguard interface (on Interfaces page) is set the same value. Seems to be working fine but I wonder if any defragmenting is going on (see my comment below for details).
My original question is if I should tweak the MTU values on the devices page (where you see lan0, lan1, wan0, eth0, br0 devices). Currently they remain as their defaults, most of them being 1500 while one of them being 1504.
It is fulltime and I would like the router not to fragment any packets if possible. In the best possible scenario, the router would receive the packets from the PC and encrypt them (with WG server's key) without having to fragment/defragment before encryption.
I faintly remember reading somewhere when wireguard is encrypting packets it adds 4 bytes of data to them (as a header). So fragmenting/defragmenting might be happening on the router to make space for the new 4 bytes of header - only if it tries to send out 1376 bytes of packets (it would have to reduce the original packets by 4 bytes). Wondering if it's better to set PC's MTU to 4 bytes less because of that.
You cannot make the MTU larger than the actual PHY's maximum (most Ethernet-based ISPs, this is 1500) - so 1504 is invalid on the ISP unless they explicitly instruct otherwise
MTU refers to the Ethernet frame, not the packet/datagram - so you're mixing terms (in another thread when you mention MSS Clamping - though they're loosely related)
If you're literally running Wireguard on LAN to just to encrypt LAN, then your Ethernet's MTU could be raised slightly but you still have a 1500 on WAN restriction on that interface too.
(It really gets futile to play with the MTUs. Also, it doesn't hurt to leave MSS Clamping on.)