A user can browse simple pages and ping a destination, but large downloads, file transfers, or uploads stall. Since small packets succeed, the route appears partly healthy. The difference in packet size is a clue that the path may not be carrying larger packets reliably.
Each link supports a maximum transmission unit, or MTU. Tunnels and encapsulation add headers and reduce the space available for the original packet. If devices do not handle fragmentation or path-MTU signaling as expected, small exchanges may pass while large transfers stall or repeatedly retransmit.
Record which applications fail, the transfer size, whether the issue occurs in one direction, and whether VPN or tunnel paths are involved. Compare a small request with a larger transfer and note where behavior changes. Check interface counters and any filtering of ICMP messages used for path-MTU discovery.
Repeat the original large transfer, test the opposite direction, and confirm that smaller applications still behave normally. Check retransmissions and interface errors during the test. Document the effective MTU or MSS and the path segment where the limit applies.
A small ping may fit through every link while larger TCP segments encounter the path MTU limit. A successful small test therefore confirms only that packets of that size can make the trip. Use a controlled size test and confirm with the affected application.
The forward path and return path can have different MTUs or tunnel overhead. A download may fail while an upload works, or a remote site may behave differently from the data center. Test both directions where possible.
Record MTU expectations for tunnels and WAN links, and validate them when adding encapsulation. Keep packet filtering aligned with security policy while allowing required control messages. Include a large-payload test in VPN and application acceptance checks.
Large transfers exercise parts of the path that small pings may never reach. A small packet can pass while a larger packet is dropped because of an MTU mismatch, tunnel overhead, a filtering issue, or a device that cannot fragment as expected. When investigating, record the actual packet sizes, whether the test sets the “do not fragment” behavior, and which direction fails. A basic ping proves only that some ICMP traffic can travel; it does not prove that a long TCP transfer can sustain the same path.
Path MTU discovery relies on feedback that tells the sender when a packet is too large for a segment of the route. If that feedback is filtered, the sender may repeatedly transmit packets that cannot pass, a pattern often called a black hole. VPN and other encapsulation add headers and reduce the space available for the inner packet. Compare results with and without the tunnel, and inspect relevant interface MTUs and tunnel settings before changing the endpoint’s MTU.
Test upload and download separately. A one-way failure can result from different provider routes, asymmetric MTUs, or policy on only one direction. Compare a large ping test with an application transfer and check whether a TCP handshake succeeds but data stalls after a certain size. Packet captures can show retransmissions, missing acknowledgments, or ICMP messages, but capture only the necessary flow and use approved tools because packet data may contain sensitive information.
Possible fixes include correcting the MTU along the path, allowing required path-MTU feedback, or using an appropriate TCP MSS adjustment at a tunnel edge. These are design choices, not interchangeable toggles. A smaller MTU can mask one path problem while reducing efficiency elsewhere. Validate multiple applications, both directions, and the full tunnel or WAN path after a controlled change. Keep one known-large test file and repeatable test endpoints for future comparisons.
Look at the transfer pattern as well as its final outcome. Does it stop immediately, stall after a fixed amount of data, slow down gradually, or fail only in one direction? A fixed stall can suggest a packet-size or protocol threshold; gradual slowdown can reflect congestion, retransmissions, or a receiver bottleneck. Compare the application’s transfer log with TCP retransmission and acknowledgment behavior if approved telemetry is available.
Be aware that increasing an endpoint’s MTU can make the problem worse if an intermediate segment cannot carry the larger packet. Likewise, reducing MTU everywhere can lower efficiency without fixing the broken feedback path. Test the full encapsulated route and validate the intended inner and outer sizes. If a tunnel endpoint applies MSS adjustment, confirm that the configured value is suitable for every relevant path and protocol.
After repair, test more than one large object and include both directions and the VPN or WAN path that originally failed. Run the same transfer from a second client if possible to distinguish an endpoint-specific issue from a shared path issue. Record duration, file size, checksums or application success where appropriate, and relevant packet evidence. Reproducible measurements will show whether the change solved the cause or merely changed the symptom.
If a workaround such as lowering the client MTU appears to help, treat it as evidence rather than the final explanation. Identify which segment or tunnel imposed the smaller packet limit and why path feedback did not reach the sender. Then decide whether the lasting correction belongs at a tunnel boundary, a filtering policy, or a link configuration. Temporary endpoint changes should be documented and removed once the network-side fix is verified.
Packet size is a valuable diagnostic clue. Map the path, account for tunnel overhead, and test the real transfer before making a targeted MTU or MSS change.
Does a successful ping rule out an MTU problem?
No. Small pings can pass while larger packets are fragmented or dropped. Test progressively larger payloads and compare with real application traffic.
Why can a VPN cause large transfers to fail?
Tunnel headers reduce the available payload size. If MTU, MSS, and path-MTU signaling are not handled correctly, larger packets may be dropped or retransmitted.
Should I simply reduce the MTU everywhere?
No. First identify the constrained link and calculate the overhead. Apply a narrow, supported adjustment and validate other traffic afterward.
Can blocking ICMP cause this symptom?
It can. Some ICMP messages help endpoints learn the path MTU. Blocking them indiscriminately may cause larger packets to stall even though smaller traffic works.
Join the discussion: How would you test your MTU hypothesis without guessing?
For hands-on practice with real network troubleshooting, explore training with Atmic Networks.
SEO title: Small Packets Work. Large Transfers Fail. What Does That Tell You?
Meta description: Small packets work but large transfers fail? Check path MTU, fragmentation, VPN overhead, MSS settings, and packet filtering.
Focus keywords: large transfers fail MTU, path MTU troubleshooting, VPN MTU, packet fragmentation
URL slug: small-packets-work-large-transfers-fail
