potentially disallowing IP fragmentation on wg packets, and handling routing loops better

[Roman Mamedov]

On Mon, 7 Jun 2021 13:27:10 +0200
"Jason A. Donenfeld" <Jason at 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