Jumbo Frames Don't Make a VPN Path Carry 9000-Byte Packets

You enabled 9000-byte frames on the LAN and expected the VPN to get faster. It got slower, or stopped passing large transfers altogether. Jumbo frames are a local link agreement; they do not enlarge the path the tunnel crosses.

The usable budget is set by the smallest boundary on the route, including the encapsulation the tunnel adds.

What jumbo frames actually change

An MTU is a property of one interface. Raising it on a server and its switch means those two can exchange larger frames without fragmentation. It says nothing about the router beyond the switch, the ISP, or the far side of a tunnel. Those devices have their own limits, and a packet that exceeds one of them is dropped or fragmented according to rules you did not set.

Local agreement, global consequences. That is the whole confusion.

The encapsulation tax

A tunnel wraps your packet inside another one. WireGuard over IPv4 UDP adds roughly 60 bytes of overhead; OpenVPN's UDP mode is in the same range, and IPsec varies with mode and algorithms. Those bytes come out of the outer path's budget, not out of nowhere.

So a 1500-byte outer link cannot carry a 1500-byte inner packet once a tunnel header is added.

The arithmetic is worth doing once. On a 1500-byte path, a WireGuard interface wants an MTU around 1420 so the encapsulated packet fits. Set the inner interface to 9000 and every large packet needs fragmentation the tunnel cannot perform, or gets dropped.

Find the smallest link on the path

Walk the route and find the lowest MTU. The LAN is usually 1500 or 9000, the WAN is usually 1500, and a mobile or PPP link can be lower still. Then subtract the tunnel overhead. If the result is smaller than the inner interface's MTU, you have your answer. Path MTU discovery can find this automatically, but only when the ICMP messages it depends on are allowed through.

Filtered ICMP is the classic reason a large transfer hangs while small requests work fine.

Test size dependence without widening the change

Use a representative transfer and preserve the original values so you can put them back. ping -M do -s 1472 tests a 1500-byte packet with the DF bit set; reduce the size until it passes. If only large packets fail, you have a size problem rather than a routing one.

Beware host-side offload when reading captures. Segmentation offload can show frames far larger than what actually crossed the wire, which makes a working path look broken and a broken one look fine.

When a large MTU is the right design

A controlled private network can legitimately run larger frames end to end, provided every device in the path agrees and the tunnel overhead is accounted for. That is a coordinated design with a documented value per link, not one large number typed into a client.

For an ordinary public exit, assume 1500 or less and let the tunnel pick a safe inner MTU. RFC 8201 covers path MTU discovery for the IPv6 case and is a useful reference for how the feedback is supposed to work.