potentially disallowing IP fragmentation on wg packets, and handling routing loops better
rm at romanrm.net
Mon Jun 7 11:46:17 UTC 2021
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; or even if it
could, that would mean a much worse overhead ratio than currently.
More information about the WireGuard