VPN Ping Works but the Website Hangs: Check the Size

Ping replies arrive, remote desktop works, and the browser sits on a blank page until it gives up. Two explanations fit that pattern, and they are not variations of one problem: a policy that never allowed the service, or packets that stop fitting once the transfer grows. The echo reply rules out neither.

Walk from the smallest question to the largest one, and write down what each step actually proved.

A Ping Reply Answers a Much Smaller Question

An echo reply says the destination's IP stack answered an ICMP request from your source. It says nothing about whether a TCP listener exists on the port you need, whether a policy permits that port, or whether the destination host filters traffic independently of the gateway. A gateway that allows one service can drop another while both targets answer ping. Read the reply as one fact about one packet and one direction.

Confirm the destination and the service port before interpreting anything else. The address you tested and the address the application uses are sometimes different records, and a name that resolves to two addresses makes that likely.

Find Out Whether the Connection Started

A connection refused immediately is a listener or policy answer: something replied, and it said no. A connection that opens and then stalls when data starts moving points at size. A connection that never completes the handshake at all is usually policy or routing, and looks like a timeout rather than a refusal.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Record which of those three you observed before touching MTU settings. Changing a tunnel size to fix a refused connection wastes the change and hides the actual cause for a while.

Measure Size With a Stated Number

When the stall appears under load, test one packet size with the don't-fragment bit set and state the arithmetic so the result means something. On Linux with iputils, a payload of 1392 bytes plus the 8-byte ICMP header and the 20-byte IPv4 header produces an inner packet of exactly 1420 bytes. State that arithmetic in the ticket, because a bare ping that reaches the gateway proves nothing about an application.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Both probes are measurement points, not recommendations for a tunnel size. If ICMP is filtered anywhere on the path, a timeout tells you nothing about size, because filtering and a too-large packet look identical from the client. A success also says nothing about the reverse direction or about a different destination.

Account for the Outer Path

Encapsulation adds its own headers, so the packet on the wire is larger than the packet you measured inside the tunnel. The gap between the two is what makes a working small request and a failing large one possible at the same time.

IPv4 path MTU discovery depends on feedback about packets that cannot be forwarded without fragmentation, and IPv6 uses Packet Too Big messages. The IPv4 specification describes that mechanism. Filtering the feedback breaks the sender's ability to learn, which leaves it retransmitting packets that will never fit. That is why a working small request and a failing large one coexist so comfortably.

Change One Number and Re-test the Application

Lower the tunnel MTU, or clamp the maximum segment size for TCP, then repeat the original application test rather than the probe. A probe that succeeds after the change and an application that still hangs is a different problem with a similar shape, and only the application test tells them apart.

Keep the arithmetic in the change record: the measured size, the overhead you assumed, and the value you set. Anyone reviewing that later can check the assumption instead of re-deriving it from a screenshot of a ping.

If the application works at every size you tried, stop adjusting numbers and look at the policy that separates the working service from the failing one.