VPN MTU Problems: Symptoms and Fixes

Few things are more confusing than a VPN that is clearly connected, yet some websites open instantly while others spin forever. Search results load, a chat app works, and then a page with a large image or a file upload simply hangs. You turn the VPN off and everything is fine. You turn it on and the same pages hang again. When that pattern appears, a quiet setting called MTU is one of the first suspects.

This article explains MTU in plain language, shows why a VPN makes the problem more likely, describes the symptoms that point to it, and walks through a test using the ping tool that already exists on your computer. It also covers the fixes worth trying and the ones that only make things worse. You do not need to be a network engineer to follow it, and you will not be asked to change anything you cannot undo.

What MTU is and why VPNs shrink it

Data crosses the internet in packets. Each network link along the path has a maximum packet size it will carry in one piece, called the maximum transmission unit, or MTU. On ordinary Ethernet and Wi-Fi the usual MTU is 1500 bytes. Some connections use less. A line that uses PPPoE, common on certain home fibre and DSL services, typically has an MTU of 1492 because the PPPoE header takes eight bytes. Mobile networks and some tunnels use other values again.

A VPN works by taking each of your packets, encrypting it, and putting the result inside a new packet addressed to the VPN server. That outer wrapper costs space. Depending on the protocol and whether it runs over IPv4 or IPv6, the overhead is commonly somewhere between about 40 and 100 bytes. You can read the general idea in the explainer on what a VPN protocol is, and the WireGuard site publishes the packet layout of that particular design.

The arithmetic is simple. If the link allows 1500 bytes and the wrapper uses 80, the original packet inside the tunnel can only be about 1420 bytes. If your device still produces 1500-byte packets for the tunnel, the wrapped result is too big for the link and has to be split, or it is dropped. Good VPN software sets its own tunnel MTU lower to prevent this. When it does not match the real path, you get the symptoms below.

How packets get lost: the black hole

A packet that is too big for a link can be handled in two ways. It can be fragmented, meaning cut into smaller pieces and rebuilt at the other end. Or, if the sender marked it "do not fragment", the router must discard it and send back a small notice saying it was too big and what size would fit. The sender then retries with smaller packets. That feedback loop is called Path MTU Discovery, and it is described in RFC 1191.

The loop depends on those "too big" notices arriving. Some firewalls, routers and badly configured networks block them. The sender never learns that its large packets are being thrown away, so it keeps retrying them and nothing arrives. Small packets pass without trouble, which is why the connection looks half alive. Engineers call this a black hole. It explains the strange selectivity: the opening handshake and short requests fit, while the first large reply does not.

Symptoms that point to MTU

MTU trouble has a recognisable shape. None of these alone proves it, but several together are a strong sign:

• Some sites work and others hang, often with the page starting to load and then freezing.
• Uploads stall at a certain point, or an email with a large attachment never leaves the outbox, while short emails send fine.
• Video calls connect but the video freezes, or the call starts and then drops, while text chat remains fine.
• Secure shell or remote desktop sessions log in and then freeze when a command prints a lot of output.
• The problem follows the network, not the device. It happens on one home line or one hotel Wi-Fi and disappears on mobile data.
• The VPN connects instantly and shows as connected, so the handshake is fine. This separates it from a handshake failure, where the tunnel never opens.
• Turning the VPN off removes the problem, because without the wrapper the normal 1500-byte packets fit.

Symptoms that do not point to MTU include a slow speed that is steady, a total loss of connection, and one single website being broken while everything else works. For those, start with websites not working with a VPN or a VPN that is connected but has no internet.

Test it yourself with ping

You can find a working packet size with the built-in ping tool. Ping lets you set the size of the data in each packet and forbid fragmentation. The packet on the wire is the data size plus 28 bytes of headers (20 for IP and 8 for ICMP). So to test a path MTU of 1500, you send 1472 bytes of data.

Run the test with the VPN on, against any well-known website name. Use the command for your system.

System	Command (replace SIZE)
Windows	ping -f -l SIZE example.com
macOS	ping -D -s SIZE example.com
Linux	ping -M do -s SIZE example.com

Start with 1472. If you get replies, the path carries a 1500-byte packet and MTU is probably not your problem. If you get a message such as "Packet needs to be fragmented but DF set", or nothing at all, lower SIZE and try again. A sensible sequence is 1472, 1452, 1432, 1412, 1392, 1372. Stop at the largest size that gets replies. Then narrow it down in steps of 10, then of 2, if you want to be precise.

Add 28 to the largest working data size. That total is your path MTU. For example, if 1392 works and 1412 does not, your usable path MTU is somewhere between 1420 and 1440. A value near 1420 with the VPN on is entirely normal. A value far lower, such as 1300, suggests the network has an extra tunnel or a restrictive link in the way.

Two cautions. First, some networks block ping altogether, so a total lack of replies at every size means the test is unusable, not that MTU is zero. Second, ping measures the path to that host. The path to your VPN server may differ, so treat the result as a guide.

Fixes worth trying, in order

Work from the safest and cheapest option to the most involved.

1. Change the connection method or location in the VPN app. Different methods wrap packets differently, and a different server path can avoid the narrow link. This is reversible and takes seconds. The article on WireGuard versus OpenVPN explains why overhead differs.
2. Change the network. Try mobile data or a different Wi-Fi. If the problem vanishes, the original link is the cause, and you can decide whether it is worth pursuing with the network owner.
3. Restart the router and the device. Stale state in a router can keep a wrong value cached for the path.
4. Check the app for an MTU or packet-size setting. If it has one, lower it step by step, using the values from your ping test, and retest the problem pages after each change. If your app does not offer the option, do not look for hidden workarounds. Follow the connection options listed on your My Pass page.
5. If you run the router yourself, you may be able to set a smaller MTU on the internet-facing interface, or enable a feature often called MSS clamping that trims the size announced in new connections. Note the original value before changing it, change one thing at a time, and keep the old value so you can put it back.
6. Update the app. Newer versions sometimes pick better defaults.

What not to do is also worth listing: do not set the MTU to a tiny value "to be safe", do not change the MTU of your main network adapter without writing down the old number, and do not follow a guide that tells you to disable all firewalls.

Typical values for reference

These are common, not guaranteed. They help you judge whether a result from your ping test looks normal.

Link type	Usual MTU	Comment
Ethernet and most Wi-Fi	1500	Standard starting point
PPPoE broadband	1492	Eight bytes taken by the PPPoE header
Typical VPN tunnel inside a 1500 link	about 1380-1440	Depends on protocol and IP version
Tunnel inside a PPPoE link	about 1370-1420	Both reductions add up
Some mobile networks	1400-1500	Varies by carrier

If your result is close to the figure for your link type, MTU is working as expected, and you should look elsewhere for the cause of your problem.

Worked scenarios

The remote worker with half a page. Dana works from home on a fibre line that uses PPPoE. With the VPN on, her company's web tools open but the document editor hangs when saving. Ping with SIZE 1472 fails, 1432 fails, 1412 succeeds. Her path MTU is about 1440. Switching to a different connection method in the app resolved it, which suggests the first method's overhead exceeded the narrow line.

The traveller with a freezing call. Leo joins a hotel Wi-Fi network. Messages send, but video calls freeze after a few seconds. On his phone hotspot the calls are fine. The hotel network is the cause, and since he cannot change it, he uses the hotspot for calls and keeps the hotel Wi-Fi for light browsing.

The student with an upload that never finishes. Mai tries to submit a large file through a university portal. The progress bar sticks at the same point each time. Ping tests show a normal path. MTU is not her problem; the portal was timing out. She learns to test before changing settings, and saves herself a risky router edit.

Common mistakes

• Treating every slow page as an MTU problem. MTU produces stalls and selective failures, not steady slowness. For plain slowness, read why a VPN can be slow.
• Testing with the VPN off. The test must run with the VPN connected, or the numbers are for the wrong path.
• Forgetting the 28-byte headers. The ping data size is not the MTU. Add 28.
• Changing several settings at once. You cannot tell which change helped, and you may leave a harmful one behind.
• Going too low. A very small MTU makes every transfer carry more overhead. Aim for the largest working value, then stop.
• Editing a work or school router. If you do not own the network, report the symptom to the administrator instead.

Limits of this advice

MTU is only one cause of selective web failures. Others include DNS trouble, a site that dislikes the address you are using, a browser extension or an app with its own filter. If the ping test shows a normal path and the symptoms remain, MTU is probably not the cause, and you should move on instead of tuning it further.

Also, results change. A fix that works on one network may not help on the next, and a roaming mobile connection can change its path while you use it. For general ideas on keeping a link steady, see improving VPN connection stability.

Summary

MTU is the largest packet a network link carries in one piece. A VPN wraps each packet in extra data, so the tunnel needs a smaller size, and when the path drops oversized packets some pages and uploads stall while small requests work. Confirm the pattern, test with ping using the do-not-fragment flag and add 28 bytes to find the path size, then try the reversible fixes first: another connection method, another network, a router restart, and only then a small, noted MTU change. If you want a short pass to test a connection method on your own devices, the pricing page lists the options and the download page has the official VPNclient apps.