MTU Problems Slowing Your VPN? How to Tune It

Some VPN problems announce themselves: the tunnel won't connect, the IP is wrong. MTU problems whisper. Pages half-load, some sites work and others hang, video calls stutter while VPN speed tests look fine. If your tunnel is up but everything feels wrong in a way you can't pin down, VPN MTU problems deserve a look. It's a fifteen-minute fix once you know the symptoms.

The Symptoms That Point to MTU

MTU (Maximum Transmission Unit) is the largest packet size a network path will carry. VPNs shrink the usable MTU because encryption headers eat some of each packet's space. When a packet is too big for a link and can't be fragmented properly, it gets silently dropped. The result is a distinctive pattern of breakage:

• Pages partially load. Text appears, images hang. Small packets (HTML) fit; large packets (images, video chunks) don't.
• Some sites work, others don't. Depends on each site's packet sizes and whether path MTU discovery works through the tunnel. Infuriatingly inconsistent.
• TLS/HTTPS handshakes stall. The handshake involves larger packets; if those get dropped, secure connections hang while plain HTTP might limp along.
• Speed tests look fine but real use is broken. Speed tests use small, well-behaved packets. Real browsing doesn't.
• It started on a specific network. Worked at home, broken on hotel WiFi: the hotel's network has a smaller MTU somewhere in the path (PPPoE links, tunnels, and some cellular networks are classic culprits).

The telltale sign is selective breakage. If everything is slow, it's probably not MTU. If small things work and big things hang, MTU jumps to the top of the suspect list.

Finding Your Optimal MTU With Ping Tests

You find the right MTU empirically: send progressively smaller ping packets through the tunnel until they stop fragmenting. Here's the method:

1. Connect the VPN and get the tunnel working (even if sluggishly).
2. Find a target on the other side of the tunnel. Your home server's tunnel IP, or any reliable external host reached through the tunnel.
3. Ping with the "don't fragment" flag and a large size. On Linux/macOS: ping -D -s 1472 <target>. On Windows: ping -f -l 1472 <target>. The -s/-l value is the payload size; add 28 bytes for IP+ICMP headers to get the full packet size.
4. Read the result. If you get replies, that size fits. If you get "message too long" or timeouts, it's too big.
5. Binary-search downward. Too big at 1472? Try 1400. Works at 1400 but not 1440? Try 1420. Narrow it until you find the largest payload size that consistently gets replies.
6. Add the 28 bytes back to get the path MTU, then subtract a safety margin (8-20 bytes) for the VPN overhead variance. The result is your tunnel MTU.

Example: pings succeed at payload 1400 but fail at 1410. Path MTU ≈ 1428. Set the tunnel MTU to ~1420 and you're safely under.

A few practical notes: run the test through the tunnel (from a device behind the travel router, or from the router itself), because you care about the tunnel path's MTU, not the raw uplink's. Test a couple of different destinations; the limiting link is what matters. And re-test when you change networks: hotel WiFi in Bangkok and your home fiber have different path MTUs.

Applying the Fix on Client and Server

Once you have the number, set it on the tunnel interfaces. Both ends should agree; a mismatch just moves the problem.

On the WireGuard client (travel router or phone), the MTU is a per-interface setting. In the WireGuard config or the router's VPN client UI, set the MTU field to your discovered value (1420 in the example). If the UI doesn't expose MTU, the config file's [Interface] section accepts an MTU = 1420 line.

On the WireGuard server (home), set the same MTU on its tunnel interface. Symmetric settings avoid either side sending packets the other can't handle.

For OpenVPN, the equivalent is the mssfix / tun-mtu directives, or mssfix alone which clamps TCP segment sizes: often the simpler fix for OpenVPN's MTU woes since most breakage is TCP-based.

Also consider MSS clamping on the router. Even with correct MTU, some paths break path MTU discovery (ICMP black holes: the "too big" messages get filtered, so nobody learns the limit). MSS clamping rewrites TCP handshake packets to advertise a smaller segment size, sidestepping discovery entirely. On OpenWrt-based travel routers this is often a one-toggle firewall option, and it's the fix when correct MTU still doesn't resolve the hanging.

Verify the fix by repeating the symptom test: load the pages that hung, run the calls that stuttered. Then leave the setting alone. MTU is a "set and forget per network" value; fiddling without symptoms just creates new ones.

FAQ

Need Help Setting This Up?

MTU gremlins are a classic "everything looks right but nothing works" problem, and they're exactly what our VPN audit is built to hunt down: tunnel config, MTU, MSS, DNS, the lot, checked systematically instead of by guesswork: https://homeipvpn.com.