MTU limits packet size on a link; path MTU is the smallest supported size along a path. TCP MSS limits TCP payload size. Tunnels add overhead, and broken path-MTU discovery can cause larger transfers to stall while small requests still work.
Separate the packet from its payload
For ordinary Ethernet, a common IP MTU is 1500 bytes. With a basic 20-byte IPv4 header and 20-byte TCP header, that leaves a nominal 1460-byte TCP payload. Options and encapsulation can change the effective budget. IPv6 has a larger base IP header, so do not reuse every IPv4 calculation unchanged.
A VPN, PPPoE connection, or other tunnel can reduce the effective inner-packet size. The correct value depends on the actual encapsulation and provider configuration; 1500 is a common starting context, not a universal setting to force everywhere.
Recognize a possible PMTU problem
A small ping succeeds, a TCP connection begins, and then a large page or upload stalls. That pattern can suggest a size-related problem, especially if it appears only through a tunnel. It can also have other causes, so compare the same workload without the tunnel and inspect firewall or VPN logs.
Path-MTU discovery relies on appropriate feedback about packets that are too large. Blocking all ICMP indiscriminately can break useful network signaling. IPv6 routers do not fragment forwarded packets, making correct packet-too-big handling especially relevant.
Use an IPv4 size probe carefully
# Windows IPv4; choose a target that answers ICMP
ping -4 -f -l 1472 example.com
Here 1472 is the ICMP data size. Adding the usual 20-byte IPv4 and 8-byte ICMP headers gives a 1500-byte IP packet. If you receive an explicit fragmentation-needed response, try smaller sizes and compare. A timeout alone is inconclusive because the target or path may filter probes.
This test covers that IPv4 destination and probe type. It does not automatically establish the MTU for every route, prove a TCP MSS issue, or apply to IPv6 in the same way. Keep the target constant during the comparison.
Fix the responsible boundary
- Record which routes and applications fail, and whether a VPN is involved.
- Check the supported tunnel/interface MTU in the provider's documentation.
- Allow required path-MTU signaling according to the firewall's policy and protocol guidance.
- Use documented MSS clamping where the router or VPN requires it, then repeat the actual transfer.
Do not lower MTU across every adapter to improve a speed score. A smaller packet budget can add overhead and conceal a firewall fault. Preserve original settings and use a reversible, targeted change with evidence that the affected traffic now works.
Put it into practice
References & further reading
Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.