VXLAN over WireGuard MTU/PMTUD behavior: will RouterOS send ICMP to the inner host?

RouterOS General
1

Hi,

I am a user from China, and my English is very poor, so I used a translator. Please understand. I would like to clarify the MTU and PMTUD behavior of RouterOS when using VXLAN over WireGuard.

My setup is roughly:

Text
Host / Bridge
-> VXLAN interface, MTU 1500
-> WireGuard interface, MTU 1420
-> physical WAN
In this case, if an inner host sends a 1500-byte packet through the VXLAN interface, the VXLAN encapsulated packet becomes larger than the WireGuard interface MTU. For example, with VXLAN over IPv4, the encapsulated packet is approximately:

Text
1500 + 50 = 1550 bytes
But the WireGuard interface MTU is only 1420.

My questions are:

When RouterOS tries to send this VXLAN-encapsulated packet through the WireGuard interface and finds that it exceeds the WireGuard MTU, what exactly happens?

Will RouterOS generate an ICMP Fragmentation Needed / Packet Too Big message back to the original inner sender inside the VXLAN/bridge network?

Or will RouterOS only drop the packet at the VXLAN/WireGuard encapsulation stage without notifying the inner sender?

Is RouterOS VXLAN over WireGuard expected to support PMTUD for the inner traffic in this situation, assuming ICMP is not filtered anywhere?

Can I rely on PMTUD to automatically adapt the inner MTU when the physical/WireGuard path MTU changes, or should I always manually set the VXLAN MTU to something like:

Text
WireGuard MTU 1420 - VXLAN over IPv4 overhead 50 = VXLAN MTU 1370
For example:

Text
WireGuard MTU: 1420
VXLAN MTU over IPv4: 1370
VXLAN MTU over IPv6: 1350
I understand that Linux VXLAN bridge behavior may generate ICMP PMTU errors toward the inner sender in some cases, but I could not find a clear statement in the RouterOS documentation about whether RouterOS does the same for VXLAN over WireGuard.

Could MikroTik staff or anyone with confirmed RouterOS behavior clarify this?

Thanks.

2

It's in the documentation, read the section about the dont-fragment parameter:

VXLAN | RouterOS Manual

dont-fragment(auto | disabled | enabled | inherit; Default: auto)

The Don't Fragment (DF) flag controls whether a packet can be broken into smaller packets, called fragments, before being sent over a network. When configuring VXLAN, this setting determines the presence of the DF flag on the outer IPv4 header and can control packet fragmentation if the encapsulated packet exceeds the outgoing interface MTU. This setting has three options:

  • auto - if the device supports VXLAN offloading, the dont-fragment mode will operate as enabled. if VXLAN offloading is not supported, it will use the inherit mode.
  • disabled - the DF flag is not set on the outer IPv4 header, which means that packets can be fragmented if they are too large to be sent over the outgoing interface. This also allows packet fragmentation when VXLAN uses IPv6 underlay. Disables hardware offloading on compatible devices.
  • enabled - the DF flag is always set on the outer IPv4 header, which means that packets will not be fragmented and will be dropped if they exceed the outgoing interface's MTU. This also avoids packet fragmentation when VXLAN uses IPv6 underlay.
  • inherit - The DF flag on the outer IPv4 header is based on the inner IPv4 DF flag. If the inner IPv4 header has the DF flag set, the outer IPv4 header will also have it set. If the packet exceeds the outgoing interface's MTU and DF is set, it will be dropped. If the inner packet is non-IP, the outer IPv4 header will not have the DF flag set and packets can be fragmented. If the inner packet is IPv6, the outer IPv4 header will always set the DF flag and packets cannot be fragmented. Note that when VXLAN uses IPv6 underlay, this setting does not have any effect and is treated the same as disabled.

The setting is available since RouterOS version 7.8.

The behavior depends on what setting you choose for the parameter.