Some websites won't load on VPN: the MTU problem nobody mentions

Some connections fail in a way that feels haunted. The VPN connects fine. Ping works. Small pages load instantly. Then one site hangs forever, an SSH session opens and freezes the moment you run a command that produces output, a file upload stalls at exactly the same point every time, and a git clone gets to 30 percent and stops.

Everything that moves small amounts of data works. Everything that moves large amounts breaks. That specific pattern has one overwhelmingly likely cause, and it is not the VPN provider, the website, or your connection speed. It is MTU.

What MTU is, in one minute

The Maximum Transmission Unit is the largest packet a network link will carry in one piece. Standard Ethernet is 1500 bytes, and most of the internet is built around that number.

The trouble starts when a link along the way carries less:

Link type	Typical MTU
Ethernet	1500
PPPoE (common on DSL)	1492
WireGuard	1420 or lower
OpenVPN	Around 1400
IPsec	1400 or lower depending on options
Various tunnels and mobile networks	1400 down to 1280

Every tunnel wraps your packet in extra headers, so the space left for your actual data shrinks. Stack a VPN on top of PPPoE on top of a mobile connection and the usable size drops well below 1500 while both ends still assume 1500 is fine.

Why it breaks: the black hole

The internet has a mechanism for exactly this situation, and when it works you never notice. A sender marks packets "do not fragment." If a router along the path cannot forward one, it drops the packet and sends back an ICMP message saying "packet too big, the maximum here is 1400." The sender adjusts and everything continues. This is Path MTU Discovery.

It depends entirely on that ICMP message getting back. And an enormous number of firewalls block ICMP wholesale, usually because someone once read that ICMP is a security risk and blocked all of it rather than the specific types worth blocking.

When that message is blocked, here is what happens: the sender transmits a full size packet, a router silently discards it, and no error comes back. The sender waits, assumes the packet was lost, and retransmits the same oversized packet. Which is dropped again. Forever.

That is an MTU black hole, and it explains the symptom perfectly. Small packets fit and sail through. Large packets vanish without a trace. The connection is established and alive, so nothing reports an error. It just hangs.

The symptom list

If several of these are true, stop looking anywhere else:

• Ping works perfectly, because ping packets are tiny.
• Some websites load instantly, others hang forever, and it is always the same ones.
• HTTPS fails more than HTTP, because the certificate exchange during the handshake is large.
• SSH connects and then freezes as soon as a command produces real output.
• File uploads stall at a consistent point instead of failing immediately.
• Everything works until you connect the VPN.
• Email sends short messages fine and hangs on anything with an attachment.
• The same site works on cellular data and fails on Wi-Fi, or the reverse.

The tell that distinguishes MTU from ordinary packet loss is the consistency. Loss is random. MTU problems are deterministic: the same operation fails at the same point every single time, because the packet that cannot fit never fits.

How to find your real path MTU

The test is a binary search. Send a packet of a known size with fragmentation disabled and see whether it arrives. Too big, it disappears. Small enough, you get a reply. Narrow the range until you find the largest size that survives.

Path MTU Discovery does this for you and reports the largest packet the path actually carries, along with whether the path is a black hole (packets vanish silently) or well behaved (you get a proper "too big" response).

1. Test without the VPN first

   Establish a baseline for your plain connection. Most home connections come back at 1500, or 1492 on DSL with PPPoE.

2. Test again with the VPN connected

   Same target. The difference between the two numbers is your tunnel overhead. If the VPN path reports something like 1380 while your interface is configured for 1500, you have found the problem.

3. Test toward the specific host that is failing

   Path MTU is a property of a path, not of your connection. One destination can be fine while another is not, which is exactly why only some sites break.

4. Note whether the path is a black hole

   This is the crucial detail. If oversized packets produce a proper ICMP response, discovery works and the operating system will adapt on its own. If they simply vanish, nothing will adapt and you must set the size manually.

# Automatic discovery toward a specific host
https://netdebug.app/open/mtu?target=example.com&mode=auto&hops=true

# Test one specific packet size by hand
https://netdebug.app/open/mtu?target=example.com&mode=manual&size=1400

Fixing it

Lower the MTU on the interface

The direct fix. Set the tunnel or network interface to the size you measured, minus a little headroom. If your path carries 1400, setting 1380 is sensible. WireGuard clients usually expose an MTU setting directly. OpenVPN has tun-mtu. Most operating systems allow setting it per interface.

Do not go lower than you need. A smaller MTU means more packets for the same data, which means more overhead and slightly lower throughput.

Clamp MSS on the router

This is the better fix when you control the router, because it applies to everything behind it automatically. MSS clamping rewrites the maximum segment size in TCP handshakes so both ends agree on a size that fits, without depending on ICMP getting through. Router firmware calls it "MSS clamping" or "clamp MSS to PMTU." Anything running PPPoE should almost certainly have it on.

Stop blocking ICMP everywhere

If you administer the firewall, allow ICMP type 3 code 4 (fragmentation needed) on IPv4 and ICMPv6 type 2 (packet too big) on IPv6. Path MTU Discovery cannot function without them, and on IPv6 it is not optional: routers do not fragment at all, so blocking that message breaks connectivity in ways that are extremely hard to diagnose.

Blocking all ICMP has been bad advice for twenty years and it is still repeated constantly.

Check whether your VPN provider already handles it

Good VPN clients set a conservative MTU automatically. If yours has an advanced setting for it, try lowering it before assuming the service is at fault. Many "this VPN is broken on my network" reports are one number away from working.

Why this hits VPNs hardest

A VPN adds headers to every packet, which shrinks the usable payload, and it usually terminates behind a firewall that someone configured strictly. That combination is the perfect setup for a black hole: less room than expected, and no error messages to tell anyone about it.

It is also why the problem seems to follow you. The same laptop works at home and fails at the office, or works on cellular and fails on hotel Wi-Fi, because each network has a different path and a different set of firewall rules. Nothing about the laptop changed.

The short version

If small things work and large things hang, deterministically, on the same sites every time, you have an MTU problem rather than a speed or reliability problem. Measure the real path MTU with and without the VPN, note whether oversized packets vanish silently, then either lower the interface MTU to what fits or clamp MSS on the router. And if you run the firewall, stop dropping the ICMP messages that would have told everyone about this in the first place.