The 40 KB Cliff After the Tunnel Cutover
Site A (10.20.0.0/24, gateway 10.20.0.1) reaches an internal HTTPS server at 10.60.5.20 through a new IPsec tunnel whose MTU is 1400 bytes. Since the cutover, users can open the login page but any download larger than about 40 KB stalls and times out; plain HTTP to the same server still works normally. From a workstation, ping to 10.60.5.20 succeeds with a 1372-byte payload but reports fragmentation needed at 1472 bytes. The tunnel endpoint does emit ICMP type 3 code 4, but an inter-site policy drops all ICMP before it reaches the workstation VLAN. The firewall team proposes lowering the workstation VLAN MTU to 1300 and moving on.
1. Explain the failure mechanism, and state precisely why lowering the workstation VLAN MTU to 1300 will not fix it.
Read the worked answer
This is a Path-MTU-Discovery black hole. The client's small packets (SYN, the GET, the early TLS handshake records) fit inside 1400 bytes, so the session establishes and the login page loads. When the server sends full-size segments with DF set, the tunnel router must drop them and return ICMP type 3 code 4 - but that ICMP is discarded before it reaches the client, so the client never learns to lower its MSS. The same too-large segment is retransmitted on an exponential backoff (1s, 2s, 4s...) until the session times out. Slow start explains the size threshold: responses under ~40 KB are still sent as small segments.
Lowering the workstation VLAN MTU only shrinks client-to-server segments. The stalling direction is server-to-client, and the server's segment size is unchanged by anything the workstation does. The ICMP that would tell the client to shrink is still dropped, so the black hole persists. It also penalises every host on the VLAN, including traffic that never crosses the tunnel. The fix has to change the return path or the MSS, not the client's own MTU.
2. Propose two fixes that address the root cause, and give one concrete tradeoff for each.
Read the worked answer
1. MSS clamping on the tunnel. Rewrite the MSS option in SYN and SYN-ACK to about 1360 bytes (1400 − 20 IP − 20 TCP) on both tunnel endpoints.
- Tradeoff: it only helps TCP. Large UDP/ESP/DTLS payloads (big DNS answers, IKE, some VoIP) will still black-hole, and the fix silently disappears if someone rebuilds the tunnel without the clamp.
2. Permit ICMP type 3 code 4 (plus the related fragmentation-needed variants) from the tunnel endpoints to the site VLANs, rate-limited.
- Tradeoff: requires a firewall policy change and review, exposes the internal topology to ICMP-based enumeration, and fails again if any intermediate device strips ICMP.
Best practice is both: clamp now to stop the bleeding, open PMTUD ICMP so non-TCP protocols are also covered. Either alone leaves a known gap.
3. If you captured at the workstation during a stall, what would you see, and which single observation would separate this from ordinary packet loss or a slow server?
Read the worked answer
You would see the handshake and a small server response complete normally, then repeated retransmissions of the same large segment (at or above the 1400-byte tunnel MTU) from 10.60.5.20, spaced roughly 1s/2s/4s apart, with the client ACKing nothing beyond the last small segment. No ICMP arrives at the client.
The discriminator is uniformity: the retransmitted segment is always the same size and always larger than the tunnel MTU, and it repeats with zero application progress. Genuine loss shows varied segment sizes and partial progress between losses; a slow server shows delayed but successful, increasing responses with few or no retransmissions. Seeing the same oversized frame retried five times with no ACK advance is the PMTUD signature.