After moving a service behind a VPN to an on-premises system, small API calls succeed and large responses hang indefinitely. Walk through the diagnosis.

What the symptom tells you

Size-dependent failure with a working handshake is a very specific signature. The connection establishes, so routing, firewall rules, DNS and TLS are all fine. Something breaks only when packets get large.

That is path MTU discovery failing.

The mechanism

A VPN encapsulates packets, which reduces the effective MTU below the standard 1500 bytes. When a too-large packet with the don't-fragment bit set reaches the constrained link, the router is supposed to drop it and return an ICMP "fragmentation needed" message telling the sender the correct size.

Firewalls very commonly block all ICMP — often reflexively, as "ICMP is a security risk". So the message never arrives. The sender does not learn the packet was dropped and retransmits the same oversized packet forever.

Small packets fit and succeed. Large ones vanish with no error. Hence a hang rather than a failure.

The fixes

Permit the required ICMP types — type 3 code 4 for IPv4, packet-too-big for IPv6. Blocking all ICMP is a misapplied practice; PMTUD is load-bearing.

Clamp the TCP maximum segment size on the tunnel interface, so both ends negotiate a segment size that fits at connection time and never generate an oversized packet. This works regardless of ICMP and is the standard remedy on VPN links.

Lower the MTU on the affected interfaces as a blunt fallback.

Method, which is the transferable part

Work outward from the symptom's constraints, not through a checklist.

Size-dependent → MTU. Time-dependent → timeouts or keep-alives. Load-dependent → a resource limit (NAT ports, connection tracking, file descriptors). Intermittent by client → DNS or an unhealthy backend still in rotation. Works internally, fails externally → certificate chain or a security group.

Then confirm with evidence: ping with the don't-fragment bit at descending sizes to find the real MTU, flow logs to determine whether the traffic arrived at all and which rule rejected it, and packet capture only when the cheaper signals are ambiguous.

Flow logs answer the one question nothing else does — network problem or application problem — and they must be enabled in advance.