MTU and Path Discovery: Why Small Requests Work but Large Transfers Stall
Packet size can explain a connection that starts normally and stalls later. Gather targeted evidence before changing MTU settings.
A connection that completes a handshake but stalls during a larger response can point to a packet-size problem. MTU is the maximum transmission unit for a link. Tunnels and overlays can add overhead, reducing the useful packet size available to an inner connection. The symptom is suggestive, not conclusive: application limits, disk delays, and proxy timeouts can produce similar behavior.
Map the path before changing a number
Draw the actual connection in a few words: laptop, VPN tunnel, guest firewall, private interface, application. Note which devices add encapsulation and which interface carries the traffic. A server can have different MTUs on different interfaces for valid reasons. Changing every interface to the same guessed value can introduce a second problem.
LayerOne's private virtual networks use an MTU of 1450. Check the relevant guest interface when configuring private-network workloads, particularly when the guest does not apply the expected settings automatically. An additional customer-managed tunnel may have its own documented requirements; its usable size cannot be inferred solely from the underlying private-network setting.
Compare a small operation with a larger one
Use a controlled application endpoint or permitted file transfer between systems you own. Record whether connection setup succeeds, the approximate point where progress stops, and whether the same operation works without the tunnel. Keep the request content non-sensitive. Avoid generating a large stress test merely to establish that a small and larger transfer behave differently.
On Linux, ip link show can display interface MTUs without changing them. Compare those values with the documented network design. If a packet-size diagnostic is available for your operating system, use its documented syntax and a bounded sample rather than transplanting options from another platform.
Consider path feedback and filtering
Path MTU discovery relies on mechanisms that help endpoints learn usable packet sizes along a route. Filtering relevant network-control messages can interfere with that process. This is one reason an indiscriminate policy that drops all ICMP deserves review. The correct allowances depend on address family, firewall platform, and network design.
Suppose a private API responds to short health requests but file downloads stall only through a VPN. Compare interface settings, tunnel overhead, and required control-message handling. Keep the API's own upload and response limits in the investigation. A successful small ping alone cannot rule out a larger-packet issue.
Validate the narrow correction
Make an interface or tunnel change only after identifying the relevant constraint and preserving a recovery path. Retest the original operation, ordinary interactive access, and another representative transfer. Record the reason for the value in configuration documentation so a future administrator does not reset it to a familiar default. Escalate with the path, interface values, timestamps, and comparison results when the cause remains uncertain.
Repeat the check after a tunnel migration or image replacement, since a rebuilt guest may load different interface defaults. Compare the running interface state with the persistent configuration so a temporary correction does not disappear unnoticed at the next reboot.
The IPv4 path MTU specification explains the discovery mechanism. Consult LayerOne VNet setup guidance and the documentation hub for the platform's private-network context.