Follow the packet sizes, not the HTTP message size
Consider a simplified IPv4 path whose physical underlay MTU is 1,500 bytes. The VPN adds 80 bytes of overhead in this scenario. That leaves 1,420 bytes for the inner IP packet. If the inner packet uses ordinary 20-byte IPv4 and 20-byte TCP headers with no additional options, a safe illustrative TCP payload limit is 1,380 bytes. Real tunnels and TCP options can change this number, so measure rather than hardcode it.
Now suppose the sender is using a 1,460-byte TCP MSS, the normal calculation for an untunneled 1,500-byte IPv4 path with those same basic headers. The resulting inner IP packet is 1,500 bytes. Add the 80-byte VPN overhead and the outer packet is too large for that underlay link.
In IPv4, if the inner packet has the Don't Fragment bit set, a router that cannot forward it at that size should report the problem using an ICMP Destination Unreachable, Fragmentation Needed message. The sender can then reduce the effective path MTU and transmit smaller segments. On IPv6, routers do not fragment forwarded packets and use ICMPv6 Packet Too Big feedback. These details differ, but the principle is the same: the sender has to discover the actual supported packet size.
What if a security device blocks the needed ICMP feedback? The sender may keep retransmitting packets that are too large. The receiver never sees them and the sender does not get actionable information. That's a classic PMTU black hole. Packetization-layer MTU probing can sometimes recover without depending entirely on ICMP, but implementation support, configuration and timing vary.
The investigation I would perform
First compare traffic over the VPN with the same operation on a known healthy path. Confirm whether the failure correlates with response size, packet size or an application behavior such as a database cursor timing out. If a 40 KB compressed response succeeds while an uncompressed 2 MB response hangs, the result is consistent with an MTU issue but does not prove one. The transfer size affects how many near-MSS packets the connection sends.
Next capture packet sizes and retransmissions at both ends, and where permitted at the tunnel gateways. Look for repeated large inner packets and their absence downstream. Check for ICMP Fragmentation Needed or ICMPv6 Packet Too Big messages and whether firewalls drop them on the return path. An application trace alone cannot see that signal. Tools such as tracepath and controlled DF probes can help, but may follow a different route from TCP.
Also examine configured tunnel MTU, effective route MTU, TCP MSS negotiation, MSS clamping at VPN gateways and whether the route changes between different network paths. A route may have a lower MTU after failover, even if the usual path supports the original size. Encapsulation overhead can change when encryption modes or additional overlays are introduced.
Don't assume every large-payload hang is PMTU. A reverse proxy may buffer huge responses, flow control may stall, an application may stop reading or a firewall may enforce a maximum response size. The PMTU hypothesis becomes strong when packet captures show size-dependent disappearance along the path, not merely because the JSON was big.
Choose a fix that survives route changes
If the tunnel path has a known lower inner MTU, configure the relevant interface and routes consistently and ensure TCP MSS values do not exceed what the path can carry. MSS clamping at the appropriate edge can be a practical mitigation for TCP flowing through a fixed tunnel. It must be tested in both directions, especially when only server-to-client responses fail. The correct value includes the actual encapsulation and header overhead.
A longer-term fix is to allow validated path MTU feedback to traverse necessary security boundaries instead of blocking all ICMP indiscriminately. Where supported, packetization-layer probing provides resilience when ICMP is filtered or a route changes. Fixing path discovery is preferable to forcing every application to use an unnecessarily tiny segment forever.
I would not solve this by disabling fragmentation safeguards indiscriminately. Fragmenting tunneled packets can shift cost, increase loss sensitivity and create additional security or operational problems. Nor would I accept "raise the timeout" as a fix. Waiting longer for an undeliverable packet only converts a clear transport failure into a slower incident.
Afterward test both directions, normal and failover routes, IPv4 and IPv6 where used, and varying payload sizes. Monitor retransmissions and completion rates. The thing to prove is that maximum-sized packets on the actual path can be delivered or reliably resized, not merely that the test login endpoint returns 200.
