mesh-vpn-wireguard: actually set the mtu from the site.conf on the wireguard interface

[maurerle]

Before, we did only set the MTU on mesh-vpn (the vxlan interface), which has to be smaller than the set value on the wg_mesh (wireguard interface).

On WAN interfaces with an MTU of 1500, the default wireguard MTU of 1420 is optimal (as wireguard takes 80 Bytes).
Though it would be better for PPPoE interfaces (which typically have a MTU of 1496) to use a MTU of 1416 or less (1406 being a typical value, currently used by FFMUC, FFH and FFAC).

The documentation mentions an optimal wireguard MTU of 1376.
This would then also work on WAN-interfaces with an MTU of 1436 on IPv4 respective 1462 for IPv6).

This PR changes the behavior for mesh-vpn-wireguard to set the correct MTU from the site.conf.

Curiously, this did never lead to any known problems in one of the stated communities, and was found when debugging a fragmentation problem.

Eventually, one should also set the MTU on the wireguard gateway/supernode to something less than 1420..?

[neocturne]

We discussed this issue today, and found that the MTU in site.conf should always be applied to mesh-vpn, as it already is for all VPN providers; changing this would make the VPN handling less consistent. The MTU of the Wireguard interface should be active_vpn.mtu() + 70 to account for the VXLAN overhead.

Unfortunately, the documentation is wrong and adds the 70 bytes at a different point than what Gluon does, but this must be fixed in the docs, not in the code.

[maurerle]

Thanks for taking care of this! @blocktrron

[blocktrron]

@maurerle Can you provide a short explanation for the release notes of an upcoming release?

[maurerle]

I'd suggest something like this:
* Fixed setting MTU on vxlan interface correctly when using mesh-vpn-wireguard-vxlan (https://github.com/freifunk-gluon/gluon/pull/3258)

[neocturne]

As the MTU was previously not set at all for wireguard, I don't think the 70 need to be mentioned anywhere.

We still need to fix the MTU doc page though.

[blocktrron]

Ah, thanks for the explanation, I misread the previous comments.