MTU black hole: ping works but large transfers hang

The scenario

The Client reaches the Server through Office-FW, Router-A and Router-B. The link between Router-A and Router-B carries at most 1280 bytes per packet (its MTU), the way a VPN tunnel or a PPPoE line does, while every other link carries Ethernet's usual 1500. A ping is tiny, so it crosses without trouble. A full-size TCP packet is 1500 bytes. TCP marks its packets Don't Fragment, so Router-A cannot split one; it drops it and sends the Client an ICMP "fragmentation needed" message saying the link takes 1280. That message has to pass Office-FW, a stateless firewall whose rules allow ICMP only from the Client's and the Server's networks. The message comes from Router-A (10.0.9.2), so Office-FW drops it. The Client never learns, keeps sending 1500-byte packets, and they keep disappearing.

What you will work out

Understand MTU, path MTU discovery, and why blocking the wrong ICMP turns a narrow link into a black hole.

Why this matters

MTU black holes are behind many reports of "websites half-load" or "SSH freezes when output gets long" over VPNs, PPPoE lines and cloud overlay networks. The usual causes are firewalls that drop all ICMP and tunnels that shrink the MTU. The standard fixes are to allow ICMP "fragmentation needed" through every filter, or to clamp TCP's maximum segment size on the router at the edge of the narrow link; lowering the MTU on the hosts also works. The quick test is a Don't Fragment ping at decreasing sizes.

Running it

MTU Black Hole: Ping Works, Big Transfers Hang opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.