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

[Roman Mamedov <rm@romanrm.net>]

On Mon, 7 Jun 2021 16:46:17 +0500
Roman Mamedov <rm@romanrm.net> wrote:

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

In case you are not convinced by this case, would you consider at least
allowing fragmentation when WG's in-tunnel MTU is set to >=1500? Because this
is the user effectively saying "yes I know this is not gonna fit in one
packet, I want to rely on WG packets being fragmented", but without the need
for extra knobs.

-- 
With respect,
Roman