When This Error Shows Up
You're in the middle of something—maybe uploading a big file to a client's server, or connecting to a remote desktop over VPN—and bam, the connection drops. You see an error like Packet Fragmentation Exceeds MTU Limit in your network logs or a firewall alert. This happens a lot with VPN connections, especially when someone uses a cheap router or an old modem that can't handle big packets. I had a client last month whose whole print queue died because their NAS couldn't send a PDF over a VPN without this error. The trigger is almost always a mismatch between what your device sends and what the network path can carry.
What's Actually Going On
Think of data packets like trucks on a highway. The MTU (Maximum Transmission Unit) is the size limit for each truck. Most networks use 1500 bytes as the standard size—kinda like a standard shipping container. But some parts of your network, like a VPN tunnel or a DSL line, might only handle smaller trucks, say 1400 bytes. If your computer sends a 1500-byte packet and hits a tunnel that only takes 1400, the network has two choices: chop the packet into pieces (fragmentation) or drop it. The error means it tried to chop it, but something—like a firewall or a router with Don't Fragment flag set—said no. So the packet gets dropped, and your connection stalls.
The fix is simple: find the biggest packet size that works end-to-end, and set your MTU to that. Don't guess. Use a ping test.
How to Fix It: Step-by-Step
Step 1: Find Your Current MTU
On Windows, open Command Prompt as admin and run:
netsh interface ipv4 show subinterfacesLook for your main network adapter (like Ethernet or Wi-Fi) and note the MTU. On Mac or Linux, run:
ip link showYou'll see something like mtu 1500. Write it down.
Step 2: Ping Test to Find the Max Size
Ping a reliable server—Google's DNS 8.8.8.8 works fine. Use the -f flag to prevent fragmentation and -l to set packet size. Start with 1472 bytes (that's 1500 minus 28 for the header).
ping 8.8.8.8 -f -l 1472If it works, increase the size by 10 bytes until you get a Packet needs to be fragmented error. Then drop back by 10 and test in 1-byte increments. The highest number that works is your safe MTU. Add 28 to get the real MTU. So if 1464 works, your MTU is 1492.
Step 3: Change the MTU
On Windows, run this (replace Ethernet with your adapter name):
netsh interface ipv4 set subinterface "Ethernet" mtu=1492 store=persistentOn Mac, use Terminal:
sudo ifconfig en0 mtu 1492On Linux, edit /etc/network/interfaces or run:
sudo ip link set dev eth0 mtu 1492Reboot or restart the network service.
Step 4: Test the Fix
Try the thing that was failing before—upload a file, connect to the VPN, whatever. If it works, you're done. If not, go lower. Some VPNs need 1350 or even 1200.
What to Check If It Still Fails
- VPN client settings: Some VPNs have a built-in MTU fix. On OpenVPN, set
mssfix 1400in the config. - Router firmware: Old routers sometimes ignore MTU settings. Update the firmware or replace it. I had a client with a 2012 Linksys that just couldn't handle 1500—dropped to 1452 and it worked.
- Firewall rules: Check if your firewall is dropping fragmented packets. Some security tools block all fragments. You might need to allow them or adjust your MTU so no fragmentation happens.
- IPv6: If you're on IPv6, the MTU discovery works differently. Set the MTU on both IPv4 and IPv6 interfaces.
- DSL or PPPoE: These add an 8-byte header. So your real MTU is often 1492. If you're on DSL, try 1492 first.
Bottom line: don't overthink it. Run the ping test, set the MTU, test again. 90% of the time that's all you need. If not, it's usually a hardware issue or a misconfigured VPN.
Real-world example: Last week I fixed a small law firm's file transfer issues by dropping their MTU from 1500 to 1460. They were using a cheap DSL modem with a VPN. Took 5 minutes. They thought they needed a new server. Nope.