Reachability can depend on packet size
A successful small request does not prove that a path can carry larger packets in the same way. Encapsulation, a lower-MTU link and missing feedback can create size-dependent failures. An application may connect successfully and then stall when it transfers a certificate chain, file or larger response.
Path MTU is the usable packet-size limit across a particular route, not simply the number configured on the application's nearest interface. This guide investigates that path with the network owner. It does not prescribe a single replacement MTU for every VPN, IPv4 route or IPv6 deployment.
Setup: preserve the working and failing flows
Record the source, destination, IP version, ports, route and any tunnel or overlay. Compare a small and larger operation over the same intended path. Note whether only one direction fails, because return traffic can follow different links or encounter different filtering.
On a suitable Linux diagnostic host, a read-oriented starting tool is:
tracepath -n example.internal
Use the approved target rather than the illustrative name. Tool availability and the usefulness of its probes depend on the host and network policy. A missing response from an intermediate hop does not by itself establish a broken MTU path; correlate it with actual traffic and the relevant endpoint evidence.
Illustrative incident: a VPN introduces a smaller usable payload
In this fictional incident, a service works on the local network but larger responses stall through a new encrypted tunnel. Basic connectivity and short requests succeed. The network team examines tunnel overhead, permitted control messages and the actual packet-size behavior rather than immediately changing application timeouts.
The comparison uses the same service operation on the working and failing paths. It establishes a testable hypothesis about packet size, not a conclusion that every VPN stall is an MTU defect. Congestion, retransmission and application limits remain separate possibilities until evidence distinguishes them.
Troubleshooting: connect size, path and feedback
| Observation | Evidence | Question |
|---|---|---|
| Small requests succeed and larger ones stall | Comparable flow tests and endpoint captures | Is failure correlated with packet size? |
| Issue appears only through a tunnel | Encapsulation design and effective path | Does overhead reduce the usable packet size? |
| Sender repeats without useful progress | Packet and permitted control-message evidence | Is MTU feedback reaching the sender? |
| One direction behaves differently | Forward and return path comparison | Are the routing or filtering boundaries asymmetric? |
IPv4 and IPv6 path-MTU discovery have different protocol details. Follow the correct procedure for the observed IP version instead of applying an IPv4-specific assumption to IPv6. Keep packet captures access-controlled and limited to the diagnostic scope.
Correct the evidenced network boundary
Review the tunnel or interface design, required ICMP feedback and any supported transport adjustment with the network and security owners. Permit the specific control traffic needed by the design rather than removing filtering broadly. Where a transport workaround is justified, document the traffic to which it applies and the limitation it addresses.
Avoid reducing MTU everywhere as an unexplained permanent fix. That can conceal the problematic path and affect unrelated workloads. Define a rollback, test both directions and retain a representative large-transfer check for the route that originally failed.
Verification, alerting and SOP
Verify small and large transfers, connection setup and the original application operation over the repaired path. Compare retransmission or stall evidence before and after under a similar workload. A successful ping alone is not acceptance of the original problem.
Monitor path-specific transfer failures and relevant tunnel changes, using synthetic tests where appropriate. An internal SLO can describe completion of representative transfers on supported paths; a contractual network SLA needs separate terms. The SOP should record IP version, routes, encapsulation, approved tools, packet-size evidence, security-owner review and the test that demonstrates recovery.
See Clouvenix network architecture for a reviewed implementation and operational handover.
Technical reference
iputils tracepath manual, IETF IPv4 path MTU discovery, IETF IPv6 path MTU discovery. Reviewed 19 October 2026; use documentation for the installed product and release.