PROTOCOLS
WireGuard MTU Settings Explained for Travel VPNs
Your VPN tunnel connects, the handshake succeeds, but websites load halfway, images break, and some pages never finish. Before you blame the hotel Wi-Fi, check
✓What MTU is and why tunnels shrink✓Symptoms of MTU problems: slow✓Safe values to try (1420, 1380,
Quick Answer
If your WireGuard tunnel connects but websites load halfway and some pages never finish, check the MTU before blaming the hotel WiFi; it is the first thing HomeIPVPN checks when a client reports half-loaded pages. Lower it step by step, 1420, then 1380, then 1280, until symptoms clear.
- What MTU is: The largest packet the path can carry; VPN encryption overhead shrinks the usable size inside the tunnel.
- The fingerprint: Small things work while big things fail, some sites break and others do not, and the tunnel is fine on other networks.
- Safe values: 1420 is the usual default; 1380 clears most travel-network problems; never go below 1280 without a specific reason.
Your VPN tunnel connects, the handshake succeeds, but websites load halfway, images break, and some pages never finish. Before you blame the hotel Wi-Fi, check one overlooked setting: MTU. Getting the WireGuard MTU setting right is one of those small tweaks that fixes a whole class of maddening "almost works" travel VPN problems. Here's what MTU is, why tunnels shrink it, and the safe values to try.
What MTU is and why tunnels shrink it
Every network link has a maximum packet size: the MTU. Standard Ethernet uses 1500 bytes. When your device sends data larger than the path's MTU, the packets must be fragmented (split up) or dropped.
A VPN tunnel wraps each of your packets inside another packet, adding encryption headers. WireGuard adds around 60 bytes of overhead per packet, and the outer IP/UDP headers add more. That overhead eats into the 1500-byte budget, so the usable MTU inside the tunnel is smaller than the MTU outside it. If your WireGuard interface is configured with an MTU of 1500 but the real path only supports 1500 total, every full-sized packet plus VPN overhead exceeds the limit.
Well-behaved networks handle this with fragmentation or ICMP "packet too big" messages that tell the sender to shrink packets (Path MTU Discovery). The problem: many hotel, airport, and mobile networks block those ICMP messages or mishandle fragments. The result is a black hole: large packets vanish silently, small packets pass fine, and everything kind of works.
Symptoms of MTU problems: slow loads, broken sites
MTU issues have a distinctive fingerprint. Look for this pattern:
- Small things work, big things don't. Chat messages and simple pages load; image-heavy pages, file downloads, and video stall or fail partway.
- Some sites break, others don't. Sites serving large responses or using certain TLS configurations fail while minimal sites work fine.
- The tunnel connects fine. Handshake succeeds, small pings through the tunnel reply. It's purely a size-dependent failure.
- It works on some networks but not others. Your tunnel is perfect at home and broken at a specific hotel. The hotel's path has a smaller MTU or blocks the discovery messages.
- VPN speed tests show bizarre results. Tiny-packet tests look okay; real-world browsing crawls.
The classic tell: ping with small packets works through the tunnel, but loading any real website times out. If that sounds familiar, MTU is your prime suspect, not the VPN server, not your keys, not the hotel's speed.
Safe values to try (1420, 1380, 1280) and how to test
WireGuard's default MTU is typically 1420, which already accounts for standard overhead, and it's correct on most networks. When it isn't, step down deliberately:
- Start at 1420 (the usual default). If symptoms appear on a particular network, this is your baseline.
- Drop to 1380. This clears the large majority of travel-network MTU problems. It's the sweet spot many travel setups settle on permanently.
- Drop to 1280. The IPv6 minimum MTU and a safe floor that works almost everywhere. Slightly more overhead per packet, but rock-solid connectivity.
- Don't go below 1280 without a specific reason. You gain nothing and waste more bandwidth on headers.
Where to set it: in the WireGuard client config, add or edit the MTU = line under [Interface]. On GL.iNet travel routers, the WireGuard client settings in the admin panel expose MTU as a field. Change it on the client side (the travel device). That's the end facing the problematic network.
How to test: after each change, reconnect the tunnel and load a previously-broken site. For a more rigorous check, use ping with the "don't fragment" flag and increasing packet sizes through the tunnel to find the actual ceiling. The largest size that replies cleanly tells you your path's real MTU. Set your WireGuard MTU a little below that ceiling.
One more tip: if you travel constantly, just set 1380 on your travel profiles and stop thinking about it. The tiny efficiency cost is invisible in practice, and you'll never waste an evening debugging a hotel network again.
| MTU value | When to use it |
|---|---|
| 1420 | Default, correct on most networks |
| 1380 | First troubleshooting step; good permanent travel value |
| 1280 | Stubborn networks; safe universal floor |
| Below 1280 | Rarely needed, only with a measured reason |
FAQ
What is MTU in simple terms?
Why does my VPN work at home but break at hotels?
Will lowering MTU slow down my VPN?
Should I change MTU on the server or the client?
Can wrong MTU cause the handshake to fail?
Do I need to change MTU for every hotel?
Need help setting this up?
MTU gremlins are the kind of problem that eats an entire evening. If you'd rather have someone who does this daily tune your travel setup, our done-for-you service covers the router config, tunnel settings, and testing. Book at https://homeipvpn.com.
