Dennis HilkLinux Fix LabDE

Networking, DNS & Wi-Fi

Small requests work but large transfers stall

Investigate a path MTU mismatch when large transfers stall through VPNs or tunnels, using destination-specific routing and measured packet-size evidence.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • A session connects and small responses arrive, but larger downloads stop.
  • The problem appears on the tunneled path and changes with packet size.

Relevant environment

IP paths involving VPN encapsulation, PPPoE or other reduced-MTU links; applications and transport policies can also cause similar stalls.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • Encapsulation overhead may exceed the effective path MTU while required ICMP feedback is lost or filtered.
  • A tunnel interface can advertise an unsuitable MTU; endpoint load, packet loss and application behavior remain alternative causes without size-dependent evidence.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace DEST_IP with a known affected destination’s IP; use ip -6 route get for IPv6. Read the chosen device, source and any cached MTU without sending traffic.

ip route get DEST_IP

Interpret the result: Confirm the problem’s traffic actually uses the tunnel. The local interface MTU or a cached route value alone does not establish the entire path’s usable MTU.

Check 2

Replace DEST_IP with that destination and run one bounded trace to a host you may probe. The command sends UDP probes without changing settings; tracepath may need a distribution package.

tracepath -n DEST_IP

Interpret the result: A lower pmtu report supports a path-size limit. Missing replies can mean probe filtering, so they do not prove a black-hole MTU or identify the exact failing hop.

Evidence-guided next steps

Compare a measured tunnel MTU

If destination-specific probes and tunnel overhead support a lower limit, record the current MTU and change only the affected tunnel/profile to a value derived from those measurements. Compare the same previously stalled transfer before making the setting persistent.

Precautions: Use local access or a checkpoint because changing MTU can interrupt the current connection. Do not paste a universal number; IPv6 links must respect the minimum MTU requirements.

Recovery / rollback: Restore the recorded MTU and reconnect the original tunnel profile if loss, throughput or reachability worsens.

Did this solution help you?

Share this solution#

Restore the required PMTU feedback

If filtering evidence shows necessary IPv4 fragmentation-needed or IPv6 Packet Too Big messages are blocked on this path, correct the specific firewall/router rule with its administrator. Retest the same path while keeping unrelated filtering intact.

Precautions: Do not disable the entire firewall. TCP MSS adjustment may help a particular tunnel’s TCP flow but does not repair UDP or all IPv6 PMTU behavior.

Recovery / rollback: Restore the saved rule if the scoped change creates unintended reachability; recover through the router’s management path and prior tunnel configuration.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.