How to Find the Right MTU for a VPN

Some VPN problems feel strange. You connect, the little connected icon is green, a search engine opens, but a particular website spins forever. A messaging app works while a file upload stops at 10 percent. Logins to a bank hang on the last step. When small things work and big things fail, the cause is often not speed, a firewall or the VPN server. It is packet size.

This article is a procedure: how to find the largest packet your connection really accepts, how to convert that number into a sensible MTU for a VPN tunnel, and how to confirm the result. It is deliberately practical. The symptoms and background of the problem are described in the MTU issue, so here the focus is on measuring and choosing.

What MTU means in plain words

MTU stands for maximum transmission unit. It is the largest packet, measured in bytes, that a network link will carry in one piece. The classic value on Ethernet and most home Wi-Fi is 1500 bytes. A packet that fits inside that limit passes. A packet that is too large must be split into fragments, or be dropped.

Every packet has headers: the Internet Protocol header, then a TCP or UDP header, and then your data. The space left for data is smaller than the MTU. When a VPN is involved, your original packet is wrapped inside a new one. The wrapper adds its own headers and some encryption overhead, so the inner packet must be smaller than 1500 to keep the outer packet within 1500.

Think of posting a parcel in a box. The post office accepts boxes up to a fixed size. If you put your parcel inside a bigger protective box, you must start with a smaller parcel or the total will be too big. The VPN is the extra box.

The Internet Protocol design for fragmentation is described in the IP specification, and the usual method to find the largest working size along a path is described in Path MTU Discovery.

Why the wrong value causes odd symptoms

Normally the sender and the network negotiate the size automatically. A router that cannot forward a large packet sends back a small error message saying "too big, use a smaller size", and your device adapts. Problems appear when those error messages are blocked by a firewall or ignored by a device. The sender then keeps sending large packets that vanish silently. This is often called a black hole.

Because small packets still pass, the symptoms look random.

• Web pages that load their first part and then stop.
• Secure sites that hang after connecting because the large handshake packets are lost.
• Email that can be read but not sent with attachments.
• Uploads that start and stall, while downloads are fine.
• Remote desktop or file shares that connect and then freeze.
• Ping, which uses tiny packets, works perfectly.

This pattern is different from a VPN that connects with no internet at all, where nothing loads. In an MTU case, some things load and some do not.

Where the overhead comes from

The exact overhead depends on the VPN technology, on whether it uses IPv4 or IPv6 underneath, and on whether it runs over UDP or TCP. As a general guide, a tunnel adds somewhere between about 40 and 100 bytes per packet. IPv6 headers are larger than IPv4 headers, as described in the IPv6 specification, so a tunnel over IPv6 usually has less room.

Link	Typical outer limit	Rough room left after tunnel overhead
Wired Ethernet or Wi-Fi	1500	about 1400 to 1460
Home broadband over PPPoE	1492	about 1390 to 1450
Mobile network	often 1400 to 1500	about 1300 to 1420
Hotel or office network with extra encapsulation	varies	measure it

The numbers in the last column are only ranges to show the idea. You should measure instead of relying on a table.

Step 1: Measure the largest packet your network accepts

The test uses ping with a "do not fragment" flag. You send packets of increasing size. When a packet is too large, the reply says it needs fragmenting. The biggest payload that passes, plus 28 bytes of headers (20 for IP and 8 for ICMP), is your path MTU.

Test without the VPN first. Choose a stable public address that answers ping.

Windows (Command Prompt):

ping -f -l 1472 ADDRESS

macOS:

ping -D -s 1472 -c 4 ADDRESS

Linux:

ping -M do -s 1472 -c 4 ADDRESS

If you get normal replies, 1472 passes, and 1472 + 28 = 1500 is the MTU. If you get a message such as "Packet needs to be fragmented but DF set" (Windows) or "message too long" (macOS and Linux), reduce the size and try again.

Use a simple search. Start at 1472 and go down by 10 until it passes, then go up by 1 to find the exact edge.

For example, on a PPPoE line you might see:

• 1472 fails
• 1462 fails
• 1464 passes

Then try 1465 and 1466 until you find the largest that passes. Suppose 1464 is the last success. Your path MTU is 1464 + 28 = 1492.

Step 2: Measure with the VPN connected

Now connect the VPN, wait ten seconds, and repeat the same search. Many VPN apps create a virtual adapter with its own, smaller MTU, so a very large test might fail locally even before it leaves your device. That is fine: you are looking for the largest value that passes.

Suppose without the VPN the largest payload was 1472 (MTU 1500), and with the VPN the largest is 1392.

• Path MTU through the tunnel: 1392 + 28 = 1420.
• Overhead the tunnel costs you: 1500 - 1420 = 80 bytes.

That 80 bytes is your measured overhead. It means the tunnel adapter should not send inner packets larger than about 1420, and a value slightly lower leaves a margin.

Step 3: Choose a safe value

Take the measured number and subtract a small margin.

• Measured with VPN: 1420.
• Safety margin: 10 to 20 bytes for variation between networks.
• Candidate MTU: 1400.

Why leave a margin? Your phone moves between Wi-Fi and mobile networks, your laptop joins a hotel network that adds its own overhead, and a path measured today can change tomorrow. A slightly smaller MTU costs very little: a packet of 1400 instead of 1420 is about 1.4 percent smaller, so the efficiency loss is tiny. A packet that is too large costs a lot, because it can stall a whole connection.

A common conservative range for tunnels is 1380 to 1420. If you are on a mobile network or a double-wrapped connection, a lower value such as 1300 to 1350 is sometimes needed. Never choose a value lower than 1280 for IPv6 traffic, since that is the minimum link size IPv6 expects.

Step 4: Apply it carefully (only if you must)

Most readers should stop at the measurement. Many apps pick a good value automatically, and an incorrect manual MTU can create new problems.

If your VPN app has an MTU option, it is normally in an advanced or connection section. Keep the default unless you have a symptom. If you do change it, follow these rules.

1. Change one thing at a time, and write down the old value.
2. Reconnect after changing it, because the setting applies when the tunnel is built.
3. Retest the failing site or upload with the new value.
4. Revert if nothing improves.

For the VPNclient app used with XPASS, keep the app's default connection settings unless support tells you otherwise, and check your My Pass page for setup information. Not every app exposes an MTU setting, and that is normal. If you have no setting to change, the next best step is to try another location or a different network, then ask support with your measurements in hand. The download page lists the official apps.

Changing the MTU of your whole network adapter is a more advanced operation. On Windows, it is done through netsh interface ipv4 set subinterface with administrator rights, and on Linux through ip link set dev NAME mtu VALUE. These changes affect all traffic on that adapter, and some are lost after a restart. Only do this if you understand how to put it back.

Step 5: Verify the result

After choosing a value, confirm that it solved the original problem.

1. Reconnect the VPN.
2. Open the site that hung, or restart the upload.
3. Run the largest ping test again, with a payload equal to your chosen MTU minus 28. It should pass.
4. Try a payload 10 bytes larger. It should fail, confirming you are near the limit.
5. Test on a second network, such as mobile data, to see that your value still works.

Worked scenarios

A home user on PPPoE. Lina's fibre line uses PPPoE, so her plain path MTU is 1492. With the VPN on, her largest passing payload is 1372, so the tunnel path is 1372 + 28 = 1400. A bank site hangs at the last login step. She picks 1380, reconnects, and the site completes. The change is only 20 bytes below the measurement and costs nothing she can notice.

A traveller on hotel Wi-Fi. Kofi's laptop works fine at home, but at a hotel the largest packet that passes without the VPN is only 1450. The hotel's network wraps traffic itself. With the VPN, he measures 1370, which gives a path MTU of 1398. A default of 1420 would be too high here, which explains why uploads stalled. He lowers the setting for that trip, and later restores the default at home.

A remote worker on a phone hotspot. Mild's phone shares mobile data. The largest packet that passes without the VPN is 1400. With the VPN it is 1320, so the path is 1348. A value near 1330 works, and she notes that mobile networks tend to need lower numbers than fixed lines.

Mistakes and limits

• Forgetting the 28-byte headers. The test payload is not the MTU. Add 28 for IPv4 with ICMP.
• Testing only one address. Different destinations can take different paths, so confirm with a second address.
• Choosing the exact measured number. Leave a margin of 10 to 20 bytes.
• Setting MTU too low "just to be safe". A value of 1000 will often work but wastes capacity and slows large transfers.
• Ignoring that ping may be blocked. Some networks drop ICMP. If every test fails even at tiny sizes, the destination or network does not answer ping at all, so use another address.
• Treating MTU as the cause of every slowdown. If pages load fully but slowly, read why a VPN can be slow instead.
• Applying a fix to every network. A value tuned for hotel Wi-Fi may be wrong at home.

Tuning a protocol's own settings for throughput is a separate topic, covered in OpenVPN performance tuning, and it can interact with MTU, so change one thing at a time.

Summary

MTU is the largest packet a link carries in one piece, and a VPN wraps your packets in extra headers, so the inner packet must be smaller than the plain path allows. To find the right value, send ping packets with the do-not-fragment flag, find the largest size that passes with and without the VPN, add 28 bytes to the payload, and subtract a small safety margin. Most people never need to change anything because apps pick a working value, but when small things load and large things hang, measuring takes only a few minutes. Change one value at a time and revert if there is no improvement.

If you are comparing how short prepaid passes work while you test different networks, the pricing page explains the options.