VPN Works for Small Packets but Large Transfers Hang: Check MTU

If a VPN connects and small requests work but large transfers stall, investigate packet size before declaring the tunnel healthy. Encapsulation adds overhead, and the usable packet size can differ from the physical interface’s maximum. A path that cannot communicate its size limit properly may look like an intermittent application failure.

This symptom does not prove an MTU problem. Loss, congestion, application limits, and stateful devices can produce similar behavior. The goal is a bounded comparison that isolates size from destination, timing, and protocol. RFC 8899 describes packetization-layer path MTU discovery, a standards-based way to reason about usable packet size.

Keep one path and one question fixed

Pick an endpoint you control or are authorized to test. Record source network, tunnel, destination, address family, protocol, and time. Compare the same transfer through the VPN and through an approved non-tunnel path if policy permits it.

Do not test random public systems with large traffic bursts. A few small, bounded probes and a controlled file transfer are enough for initial diagnosis. Preserve organizational routing and access rules; bypassing the VPN is not an acceptable “fix” for protected traffic.

Begin by checking whether the stall depends on payload size rather than total transfer duration. If every transfer fails after exactly thirty seconds regardless of size, a timeout may be a better lead than packet size.

Understand inner and outer sizes

The inner packet is what the application’s network stack wants to send. The tunnel wraps it in additional protocol information, producing a larger outer packet. Encryption, encapsulation mode, address family, and other layers affect that overhead.

Do not copy a single overhead number from an unrelated VPN configuration. The useful limit is the actual path’s supported outer size minus the overhead of your configuration, with implementation behavior also considered.

Likewise, distinguish an ICMP probe’s data length from the entire IP packet length. Comparing a command’s payload flag directly with an interface MTU without accounting for headers can produce a misleading boundary.

Run a controlled size ladder

Use the platform’s documented diagnostic tooling to vary probe size over a small range. Where supported, prevent fragmentation so the test reveals whether that size can traverse the path as one packet. Record success, explicit size errors, and silent loss separately.

For example, test a few increasing sizes, then narrow the interval around a repeatable transition. Do not assume a failed echo proves the path cannot carry that size: some devices filter echo traffic independently of application traffic.

Pair the probes with a controlled application test using a file or response large enough to reproduce the symptom. Repeat the application test after each isolated change. A successful ping is supporting evidence, not the acceptance criterion for a file-transfer problem.

Inspect feedback and retransmissions

On authorized endpoints, capture enough packet metadata to determine whether large packets leave, whether responses return, and whether size-related feedback reaches the sender. Limit capture duration and protect payload contents, credentials, and personal data.

Look for repeated retransmission without progress after a larger segment, or explicit packet-too-large feedback that fails to reach the relevant stack. The absence of feedback is ambiguous: it can reflect filtering, an observation point, or another network behavior.

Do not broadly block diagnostic ICMP as a security shortcut. Size-discovery mechanisms may need specific feedback to work. Review required message handling with the network owner rather than opening every protocol indiscriminately.

Make one reversible change

If evidence supports an oversized inner packet, test a conservative tunnel-interface MTU adjustment on one controlled client. Record the old value and restore procedure first. Re-run the same transfer and compare throughput, stalls, and retransmissions.

TCP MSS adjustment may help TCP sessions negotiate smaller segments, but it is not a universal repair for UDP or every encapsulated protocol. If only TCP improves, document that limit rather than claiming the whole tunnel path is fixed.

Avoid setting an arbitrarily tiny MTU across the fleet. It can increase overhead and conceal the actual routing or feedback defect. Promote a change only after checking representative applications and both traffic directions.

Separate MTU from rekeying failures

Size-dependent stalls occur when traffic crosses a packet-size boundary. Failures repeating at a regular tunnel age suggest a different investigation, such as IPsec rekeying and renewal. Both issues can coexist, but changing renewal timers will not establish that large packets fit.

Keep a short incident record with the observed boundary, affected protocol, before-and-after transfer result, and remaining uncertainties. That gives the network team evidence they can reproduce instead of a vague report that “the VPN is slow.”

Repeat the test after reconnecting the tunnel. If the apparent boundary changes with route selection, record each route separately instead of treating one client’s temporary result as a fleet-wide constant.

Conclusion

Prove whether failure follows packet size, inspect the relevant feedback, and test one reversible adjustment. A tunnel is usable only when the real application transfer succeeds—not merely when its smallest probe gets through.