What is a VPN MTU and why does it affect your speed?

When a VPN feels slow, the usual suspects are server distance, encryption overhead, or network congestion. Those are worth investigating, but there is a quieter problem that causes packet loss, stuttering streams, and sluggish browsing without ever appearing in a speed test headline: an incorrectly configured MTU. Fixing it rarely takes more than a few minutes, but first you need to understand what it actually is.

This article explains what MTU means in the context of a VPN, why the wrong value causes performance problems, how to find the right value for your connection, and what you can do about it—whether you are using WireGuard, OpenVPN, or any other protocol.

What MTU means

MTU stands for Maximum Transmission Unit. It is the largest block of data, measured in bytes, that a network interface will send in a single packet. Think of it like the maximum parcel size a courier will accept. If your data is larger than that limit, it must be split into smaller pieces before it is sent.

On most Ethernet and Wi-Fi networks, the standard MTU is 1500 bytes. That figure has been the default for decades and works well on local networks. The problem starts when traffic travels over a VPN tunnel, because the tunnel itself adds overhead.

Why VPN tunnels shrink your usable packet size

A VPN wraps your original packets inside new packets. That wrapping—the tunnel headers, encryption metadata, and protocol-specific overhead—takes up space. So even if your underlying network supports 1500-byte packets, the VPN's encapsulated packets will exceed that limit once the overhead is added.

The amount of overhead depends on the protocol:

• WireGuard adds roughly 60 bytes for IPv4 tunnels (UDP header, WireGuard header, and authentication tag). Over IPv6 the overhead is slightly higher.
• OpenVPN over UDP typically adds 50–80 bytes depending on cipher and compression settings.
• OpenVPN over TCP adds a little more again due to the TCP header itself.

If the VPN interface's MTU is still set to 1500, the resulting encapsulated packet will be larger than 1500 bytes. The router or ISP then has two options: fragment it, or drop it. Both outcomes hurt performance.

Fragmentation: the hidden performance tax

When a packet is too large to pass through a link, it gets fragmented—broken into two or more smaller packets. Each fragment must be transmitted, tracked, and reassembled at the destination. This is not a catastrophic failure; the data still arrives. But it creates measurable overhead:

• Each fragment carries its own header, wasting bandwidth.
• The receiving end must hold fragments in memory while waiting for the rest to arrive.
• If any fragment is lost in transit, the entire original packet must be retransmitted, not just the missing fragment.
• Some firewalls and routers silently drop fragments, causing intermittent connection failures that are maddening to diagnose.

The third point is particularly damaging on lossy links—mobile connections, public Wi-Fi, or satellite—where any packet has a reasonable chance of being dropped. Fragmentation multiplies the impact of packet loss dramatically.

The PMTUD problem: when the fix doesn't fix itself

TCP includes a mechanism called Path MTU Discovery (PMTUD) designed to detect the correct MTU automatically. It works by sending packets with the DF (Don't Fragment) bit set and listening for ICMP