On Mon, 7 Jun 2021 13:27:10 +0200 "Jason A. Donenfeld" <ja...@zx2c4.com> wrote:
> Can you walk me through your use case a bit more, so I can wrap my mind > around the requirements? > > ingress --plain--> wireguard --wireguard[plain]--> vxlan > --vxlan[wireguard[plain]]--> egress Not sure I understand your scheme correctly. In any case, the path of a packet would be... On peer 1: * plain Ethernet -> wrapped into VXLAN -> encrypted into WireGuard On peer 2: * decrypted from WireGuard -> unwrapped from VXLAN -> plain Ethernet > So my question is, why can't you set wireguard's MTU to 80 bytes less > than vxlan's MTU? What's preventing that or making it infeasible? To transparently bridge two Ethernet LANs, a VXLAN interface needs to join an L2 bridge. All interfaces that are members of a bridge must have the same MTU. As such, br0 members on both sides: eth0 (MTU 1500) vx0 (MTU 1500) VXLAN transports full L2 frames encapsulating them into UDP. To fit the full 1500-byte packet and accounting for VXLAN and related IP overheads, the resulting packet size is 1574 bytes. So this same host that just generated the 1574-byte encapsulated VXLAN packet with something it received via its eth0 port, now needs to send it further to its WG peer(s). For this to succeed, the in-tunnel WG MTU needs to be 1574 or more, not 1412 or 1420, as VXLAN itself can't be fragmented[1]; or even if it could, that would mean a much worse overhead ratio than currently. [1] https://datatracker.ietf.org/doc/html/rfc7348#section-4.3 -- With respect, Roman