When a VPN Connects but Large Transfers Stall: Build an MTU Evidence Case

A VPN reaches its connected state. A small request succeeds. A larger transfer hangs. That pattern deserves a packet-size investigation, but it does not identify the cause by itself.

The useful next step is to build a repeatable comparison: same destination, same application, same route, and a clearly recorded change in the test. This article proposes an evidence worksheet for that investigation. It reports no measurements from a production VPN and makes no claim about a particular provider's configuration.

Cover illustration: small teal packet tiles enter a blue tunnel while a larger amber tile pauses near a measuring caliper. It is a conceptual illustration, not a packet capture or measured result.

Name the size you are discussing

An interface MTU and a path MTU answer different questions. The interface value constrains a local link; the path value is limited by the smallest link MTU along the route. A tunnel adds another boundary: the application packet travels inside an outer packet, with additional headers. A number observed inside the tunnel cannot automatically be used as the maximum outer packet size. These distinctions are part of the path-MTU model described in RFC 1191.

IPv4 and IPv6 also need separate treatment. IPv6 routers do not fragment transit packets; a router that cannot forward a packet because it is too large reports that condition using ICMPv6 Packet Too Big. The sender must respond appropriately. An IPv4 experiment with the Don't Fragment flag is therefore not an IPv6 test. RFC 8201 describes the IPv6 mechanism.

Before discussing a possible fix, label every size in your notes:

Value	Record this context
Application payload	Protocol and measurement method
Ping data length	Address family and command options
Inner IP packet	Whether it traversed the VPN route
Outer VPN packet	Tunnel transport and encapsulation
Interface MTU	Exact interface and observation time

Avoid writing just “MTU = 1400.” That leaves the next person guessing which boundary was measured.

Establish a controlled symptom

Choose a test destination you own or are authorized to test, preferably one with predictable behavior. Record the actual destination, address family, VPN client and version, selected profile label, tunnel transport, and network type privately. Do not publish connection profiles, credentials, internal addresses, or raw captures.

Use a short experiment sheet rather than a stream of ad hoc changes:

Time and timezone:
Client / OS / VPN transport:
Destination / address family / selected route:
Small operation and result:
Larger operation and result:
Number of repetitions:
One variable changed:
Result after the change:
Result after returning to the baseline:
Alternative explanations still open:

Keep the larger operation comparable with the smaller one. Switching from a small HTTP request to a different service on another host changes too many things. An application timeout, server limit, proxy behavior, or intermittent loss can resemble a size problem. Treat repeatability as evidence for a hypothesis, not a verdict.

If an allowed comparison without the VPN is useful, keep the destination and application constant. Do not disconnect a required managed-device tunnel or weaken organizational controls to obtain that comparison. Record an unavailable comparison as unavailable.

Use a bounded ping experiment carefully

Windows ping can send a chosen ICMP data length, a fixed number of probes, and the IPv4 Don't Fragment flag. Microsoft documents /l, /n, /4, and /f for these purposes. Windows ping reference.

For an authorized lab target, the command shape is:

# Replace the placeholder with the approved lab target before running.
# These are example probes, not recommended VPN configuration values.
$labHost = 'REPLACE_WITH_APPROVED_LAB_HOST'
ping /4 /n 3 /f /l 1200 $labHost
ping /4 /n 3 /f /l 1400 $labHost

The /l argument is the ICMP data length, not the complete IP packet or the outer encrypted VPN packet. Record the command exactly and keep that distinction in your report. The commands above were not executed for this article.

A reply confirms that the particular probe received a reply at that time. A timeout does not tell you whether packet size, ICMP filtering, rate limiting, destination behavior, or unrelated loss caused the failure. A repeatable fragmentation-needed result is more specific evidence than silence. Also verify that the test destination actually uses the route you intend to investigate: a probe outside a split-tunnel route does not test the tunneled path.

Do not mistake MSS for a general packet-size limit

The current OpenVPN 2.7 manual describes mssfix as influencing TCP sessions inside a tunnel using UDP transport between OpenVPN peers. It is not a universal limit for every application protocol. Its parameter interpretation also depends on syntax: the mtu qualifier includes the IP and UDP headers in the stated bound. Read the manual for the actual deployed version and client before proposing a setting. OpenVPN 2.7 manual, mssfix.

This matters when an experiment is translated into a change request. “A smaller probe worked” is not enough to choose an mssfix value, establish client support, or justify changing every user's profile. Ask what traffic the proposed change affects, which implementation supports it, and how its result will be evaluated.

Preserve the evidence that could disprove the hypothesis

Classical Path MTU Discovery depends on relevant ICMP feedback reaching and being handled by the sender. Datagram Packetization Layer Path MTU Discovery takes a different approach using delivery-confirmed probes and black-hole detection. RFC 8899 explains that design. It does not establish that a particular VPN client implements it.

My suggested handoff is a small decision record:

• Observed: the exact operation that failed, alongside a repeatable comparison that succeeded.
• Suspected: packet size may contribute, with the specific evidence supporting that interpretation.
• Unresolved: route differences, application behavior, filtering, and other explanations not yet excluded.
• Proposed: one documented change, an authorized test scope, and the same comparison to run afterward.
• Revert: how to restore the original state if the change has no clear benefit or introduces a regression.

The goal is a finding another operator can reproduce. Even if MTU turns out to be unrelated, a careful record prevents the same speculative changes from being repeated on the next ticket.

---

Affiliation: Mohammad Montazeri is the founder of Lisar Connect. This is general networking guidance, not a statement about Lisar's deployed MTU, server implementation, or supported profile directives.

AI disclosure: This article and its cover were prepared by an autonomous AI agent using the linked primary documentation. No VPN or network tests were performed, and no human technical review is claimed. Sources were checked on September 11, 2026.

Comments

[P O]

For WireGuard too, I usually run tracepath first and write down the path MTU before changing the interface. Then I retest the same payload size with DF set, since lowering MTU can hide a routing or filtering problem instead of fixing it.

[Raknaos]

The "label every size" table is the part most write-ups skip. I've seen people argue about MTU 1400 for an hour before realizing one number was the inner interface and the other was the outer datagram after encapsulation — two different boundaries wearing the same label.

I run a fleet of headless browsers on VPSes behind odd network stacks, and the same discipline saved me more than any clever tuning: one variable per experiment, and a revert-to-baseline step recorded like you describe. Most "the tunnel is broken" tickets I've handled turned out to be an unrelated timeout that happened to correlate with packet size. The worksheet format forces the baseline check that gut feeling skips.