Small Requests Work but Large Transfers Hang: Proving a Path MTU Black Hole

Direct answer: if ping and small requests across a link work, but file copies, large web pages, TLS handshakes with big certificate chains or database result sets stall and then time out, test for a Path MTU (PMTU) black hole before you suspect the application.

A black hole happens when a hop on the path cannot carry full-size packets, and the ICMP message that would tell the sender to send smaller packets never reaches it. With IPv4 that message is "Fragmentation Needed". With IPv6 it is "Packet Too Big". The message can be lost because a router does not send it or because a firewall filters it.

To prove it:

• Probe with don't-fragment pings of decreasing size. On Windows use ping /f /l. On Linux use ping -M do -s, or use tracepath.
• Capture on the sender to see whether any ICMP replies arrive.

Then choose a fix:

1. Let the ICMP through. This is the correct fix for the path.
2. Clamp TCP MSS at the device in front of the constricted link. This is a targeted TCP-only workaround.
3. Lower the MTU on a specific interface. This is a scoped change with side effects.

Do not disable PMTU discovery or turn on fragmentation broadly as a default fix.

Why it matters

RFC 2923 calls black hole detection a "connectivity failure" class of problem. It explains why it is so hard to spot: "pings and some interactive TCP connections to the destination host work. Bulk transfers fail with the first large packet and the connection eventually times out."

That matches the help desk symptoms:

• "VPN connects, but the file share hangs."
• "The site loads its login page, but not the dashboard."
• "Backups to the new provider stall at the first large write."

Teams often spend days on application settings, antivirus and DNS, while the real fault is a firewall rule or tunnel several hops away.

Typical ways to end up with a smaller-than-1500-byte hop include:

• New tunnels: IPsec, GRE, VXLAN or a provider overlay.
• PPPoE access links.
• A provider path change.
• A firewall policy that drops all ICMP.

The IPsec article under Related articles covers MTU as one item in tunnel troubleshooting. This article is the general method for any routed path.

How it works

IPv4 (RFC 1191)

The sender sets the Don't Fragment (DF) bit and sends packets as large as its interface allows. A router that cannot forward a packet onto a smaller link must drop it. It then sends back an ICMP Destination Unreachable, "Fragmentation Needed" (type 3, code 4) message containing the next-hop MTU. The sender lowers its estimate for that destination and retransmits smaller packets.

RFC 2923 describes what goes wrong. Routers do not always send the message, "Firewalls are often misconfigured to suppress all ICMP messages," and without the message "the upper-layer protocol continues to try to send large packets … Its packets are disappearing into a PMTUD black hole."

IPv6 (RFC 8200, RFC 8201)

IPv6 routers never fragment. RFC 8200 says that "fragmentation in IPv6 is performed only by source nodes, not by routers". It also requires every link to carry at least 1280 octets.

PMTU discovery in IPv6 relies on ICMPv6 Packet Too Big (type 2) messages (RFC 8201). So dropping Packet Too Big breaks large IPv6 transfers in exactly the same way. RFC 4890, the ICMPv6 filtering recommendations, puts Packet Too Big in the category of messages that must not be dropped.

RFC 8201 adds two rules:

• A node must not reduce its PMTU estimate below 1280 because of a Packet Too Big message.
• A node should validate that a received Packet Too Big message corresponds to traffic it actually sent.

Why TCP stalls rather than failing fast

The TCP handshake packets are small, so the connection opens. The first full-size data segments are dropped silently. The sender keeps retransmitting the same large segments and never learns why they are lost.

TLS is a common victim. The server's certificate chain can fill full-size packets early in the handshake, so it can stall before any application data moves.

Mitigations

MSS clamping. RFC 4459 describes "MSS clamping" as a technique, or rather a "hack". Tunnel endpoints reduce the TCP Maximum Segment Size so that connections "automatically restrict" themselves to the available packet size. The RFC notes that it "does not work for UDP or other protocols that have no MSS". It also assumes all the traffic passes through the clamping device.

Packetization-layer discovery. Packetization-layer PMTU discovery (RFC 4821 for TCP and similar protocols, and RFC 8899 for datagram transports) lets endpoints find the PMTU by probing, without relying on ICMP. Whether a given host uses it depends on the operating system and how it is configured. It is not a substitute for fixing the path.

Read-only checks

None of these was run for this article. The pings and tracepath need no special privilege. Packet captures need administrator or root rights, or a capture-capable account. They record traffic contents, so handle capture files under your data-handling rules and filter them narrowly.

1. Find the local MTU on each end.

Windows PowerShell:

Get-NetIPInterface | Sort-Object InterfaceAlias | Format-Table InterfaceAlias,AddressFamily,NlMtu

Linux:

ip link show

2. Probe the path with DF set (IPv4).

The ping size is the ICMP data length, not the packet length. With a 20-byte IPv4 header and an 8-byte ICMP header, 1472 bytes of data makes a 1500-byte packet.

Windows. Microsoft documents /f as setting Do not Fragment (IPv4 only) and /l as the data size:

ping /f /l 1472 <destination>
ping /f /l 1400 <destination>
ping /f /l 1300 <destination>

Linux (iputils). -M do sets DF and rejects packets that are too large for the kernel's PMTU estimate:

ping -M do -s 1472 -c 3 <destination>
ping -M do -s 1400 -c 3 <destination>

Narrow the size down until you find the largest size that gets a reply. If you get a "fragmentation needed" or "message too long" error with a reported MTU, PMTU discovery is working. If you get a silent timeout above a certain size while small sizes succeed, that points to a black hole. It is not proof yet, though, because the far end may simply not answer large pings, and a ping can take a different path from the TCP flow. Step 4 adds evidence from the real traffic.

3. Trace where the MTU drops.

tracepath -n <destination>
tracepath -6 -n <destination>

tracepath reports the path MTU it discovers at each hop, and needs no superuser privileges. Its man page notes that IPv4 results can be incomplete, because commercial routers do not always return enough information in their ICMP errors.

4. Capture on the sending host during a failing transfer.

Capture on the interface that carries the flow (ip route get <peer> names it), start the capture, reproduce the stall once, and stop it. The ICMP error that matters normally comes from an intermediate router, not from the peer, so do not filter it by the peer's address. With tcpdump on Linux, using pcap-filter syntax, one capture with grouped conditions covers both:

tcpdump -ni <interface> -c 2000 '(tcp and host <peer>) or icmp[icmptype] = icmp-unreach or (icmp6 and ip6[40] = 2)'

-c 2000 caps the packet count, not the time: on a quiet or stalled flow it may never be reached. Decide the observation window before you start (for example two minutes, enough to reproduce the stall once) and stop the capture with Ctrl+C at the end of that window, or sooner once the stall has been reproduced, whichever comes first. The ip6[40] test reads the ICMPv6 type only when no IPv6 extension header precedes it. On a busy host, add your own source address to the ICMP part, for example (icmp[icmptype] = icmp-unreach and dst host <local-address>). Each ICMP error quotes the start of the packet that triggered it; check that the quoted addresses and ports match the stalled connection before you count it.

The pattern to look for is the same large segment retransmitted several times, with no matching ICMP type 3 code 4 or ICMPv6 type 2 arriving. That is consistent with a black hole, but ordinary loss or filtering of large packets can look the same. Segment-offload features can also make segments in a local capture look larger than what goes on the wire, so judge sizes against the interface MTU and the MSS negotiated in the handshake. If the ICMP does arrive and the sender keeps sending large segments, the problem is on the sender: it is ignoring the message, or a host firewall is dropping it locally.

On Windows, use the capture tool your organisation approves, such as pktmon or Wireshark, with an equivalent filter.

5. Capture on both sides if you can. If large segments leave the sender but never reach the receiver, and no ICMP comes back, the loss is in between. A capture on each side of a firewall or tunnel narrows down which device drops the segments or the ICMP.

Interpreting the results

Decision guidance

Every change below should be made on one device or interface, after a capture or ping baseline. Verify it by repeating the same DF probes and the original failing transfer. Keep the previous configuration so you can restore it.

1. Allow the PMTU ICMP messages (preferred)

On the firewall or router that drops them, permit:

• IPv4 ICMP type 3 code 4 ("Fragmentation Needed"), at least for related or established flows.
• ICMPv6 type 2 (Packet Too Big), in line with RFC 4890.

This fixes the path for every protocol and every host behind it. Stateful firewalls can usually permit ICMP errors that relate to existing connections without opening ICMP generally.

• Verification: the capture now shows the ICMP arriving, the sender adapts, and the transfer completes.
• Rollback: remove the added rule.

Note that RFC 8201 tells nodes to validate Packet Too Big messages and ignore values below 1280. That reduces the risk of allowing them.

2. Clamp TCP MSS at the constricted link

Use this when you cannot fix the ICMP filtering, for example when it is inside a provider network. It is common on tunnel and PPPoE endpoints. Set the clamp on the device in front of the smaller link, for traffic in both directions, using the vendor's MSS-adjust feature. Calculate the value from the link MTU minus IP and TCP headers and the tunnel overhead, using the vendor's documented overheads.

• Limits: it is TCP only, and all affected traffic must pass through that device (RFC 4459).
• Verification: the original failing TCP transfer completes, and captures show SYN packets with the reduced MSS.
• Rollback: remove the MSS-adjust setting.

3. Lower the interface MTU on a specific host or tunnel

This can be appropriate for a tunnel interface, or for a single host that only uses the constricted path. It affects every protocol on that interface, so test before you widen it.

• Verification: Get-NetIPInterface or ip link show shows the new value, and the DF probe and the transfer succeed.
• Rollback: restore the recorded value.

What not to do

• Do not block all ICMP and ICMPv6 as a "security" default. It breaks PMTUD (RFC 2923, RFC 4890).
• Do not disable PMTU discovery or clear DF across servers to work around one path.
• Do not lower MTU on every server or every VM when one tunnel is the cause.
• Do not assume MSS clamping fixes UDP, QUIC or other non-TCP traffic.
• Do not treat a failed large ping as proof on its own. Some hosts rate-limit or drop large ICMP. Confirm with a capture of the real traffic.
• Do not leave captures running, or store them where unauthorised people can read them.

Limitations

• Commands use the documented options of Windows ping, iputils ping and tracepath, and pcap filters. Other implementations differ.
• Tunnel overheads and the MSS-adjust syntax are vendor specific and are not given here.
• Whether a particular OS uses packetization-layer PMTUD (RFC 4821 or RFC 8899) by default was not verified.
• Endpoint black-hole detection settings in Windows are not covered, because no current Microsoft documentation for Windows Server 2022 or 2025 was read for this article.

Acceptance checklist

• [ ] Local MTU recorded on both endpoints
• [ ] DF probe results recorded for IPv4 (and IPv6 if used), including the largest working size
• [ ] Capture during a failing transfer shows whether ICMP 3/4 or ICMPv6 type 2 arrives
• [ ] The constricted hop and the filtering device are identified
• [ ] Fix chosen in order of preference (allow ICMP, then MSS clamp, then scoped MTU) and recorded with its rollback
• [ ] Original failing transfer, and a TLS handshake, succeed after the change
• [ ] Captures deleted or stored according to policy

References

All accessed 2 November 2026.

• RFC 1191, Path MTU Discovery: https://www.rfc-editor.org/rfc/rfc1191.txt
• RFC 2923, TCP Problems with Path MTU Discovery: https://www.rfc-editor.org/rfc/rfc2923.txt
• RFC 8200, Internet Protocol, Version 6 (IPv6) Specification: https://www.rfc-editor.org/rfc/rfc8200.txt
• RFC 8201, Path MTU Discovery for IP version 6: https://www.rfc-editor.org/rfc/rfc8201.txt
• RFC 4890, Recommendations for Filtering ICMPv6 Messages in Firewalls: https://www.rfc-editor.org/rfc/rfc4890.txt
• RFC 4459, MTU and Fragmentation Issues with In-the-Network Tunneling: https://www.rfc-editor.org/rfc/rfc4459.txt
• RFC 4821, Packetization Layer Path MTU Discovery: https://www.rfc-editor.org/rfc/rfc4821.txt
• RFC 8899, Packetization Layer Path MTU Discovery for Datagram Transports: https://www.rfc-editor.org/rfc/rfc8899.txt
• Microsoft Learn, ping: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping
• Microsoft Learn, Get-NetIPInterface: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipinterface
• Linux man-pages, ping(8): https://man7.org/linux/man-pages/man8/ping.8.html
• Linux man-pages, tracepath(8): https://man7.org/linux/man-pages/man8/tracepath.8.html
• tcpdump, pcap-filter(7): https://www.tcpdump.org/manpages/pcap-filter.7.html

Related articles

• IPsec VPN Tunnel Up but No Traffic: Read-Only Diagnosis
• How to design and troubleshoot VMware networking

• How to diagnose and tune Windows SMB file services on VMware

• Connections Half-Work Through Two Gateways: Proving Asymmetric Routing

• Proving Packet Loss and Latency to a Provider: Reading mtr and pathping Correctly

Learning notes

1. PMTUD depends on ICMP "Fragmentation Needed" (IPv4) or "Packet Too Big" (IPv6). If you filter those, large packets vanish without any error.
2. The signature is small requests working and bulk transfers or TLS stalling, with the same large segment retransmitted.
3. Build the case with DF pings of decreasing size and a capture on the sender during the failure, then confirm it with a controlled size change or a paired capture.
4. IPv6 routers never fragment, so Packet Too Big must never be dropped (RFC 4890).
5. Fix in this order: allow the ICMP, clamp MSS for TCP at the constricted link, or lower the MTU on one interface. Each change gets a before/after probe and a rollback.