Why Blocking All ICMP Breaks a Working VPN Path

A tunnel that authenticates, carries a ping and then hangs on the first large transfer is the classic signature of a missing ICMP message rather than a broken VPN. The sender never learns that a packet was too big, keeps retrying the same size, and the application waits. Fixing it is a firewall policy decision, not a client reinstall. The order matters: measure where the size boundary sits, then narrow the rule that swallowed the report.

What ICMP actually carries on this path

IPv4 path MTU discovery relies on a router reporting that a packet with the don't-fragment bit set could not be forwarded. That report is an ICMP Fragmentation Needed message, and without it the sender has no reason to reduce its segment size. IPv6 is stricter: routers do not fragment in transit, so an ICMPv6 Packet Too Big message is the only signal that makes the sender shrink.

Both messages are control-plane feedback, and neither is a diagnostic echo. A policy that blocks ping and a policy that blocks all ICMP look similar in a rule list and behave very differently on the wire. The second can turn a correctly sized tunnel into a one-way path for anything larger than the smallest link in the chain.

Some transports implement their own discovery with probe packets, as RFC 4821 describes, and those are less dependent on this feedback. That is an argument for checking which transport you run, not for assuming every tunnel is immune.

The failure is size-dependent

Ask whether the failure correlates with packet size. A login page, DNS query and short API call succeed while a file upload, a large response or an image download stall. That pattern points at a size limit somewhere between the two ends rather than at authentication or routing. A successful small ping says almost nothing about where that boundary lies.

Inside a tunnel there are two layers to consider: the payload packet and the outer encapsulated packet. The inner sender can be behaving correctly while the outer path is smaller than the tunnel assumes, which is why the tunnel's own MTU setting and the physical link underneath both matter.

Measure before editing rules

Probe with the don't-fragment bit and a payload size you choose, from the failing client toward a protected address:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

A 1472-byte payload plus 28 bytes of headers is a 1500-byte packet. If the large probe fails with a fragmentation error and the smaller one passes, you have found the boundary; adjust for tunnel overhead and repeat until the working size is stable.

Then confirm the gap is the report itself. If the probe fails silently, with no error and no reply, the message is probably being dropped rather than delivered, and the rule is the suspect.

Narrow the rule, then retest the task

The correction should allow the specific control messages, not the whole protocol. On an iptables host the shape is a type-specific accept; adapt the syntax to whatever manages the firewall on your platform:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Keep echo replies blocked if that is the local policy, since they are not what the path needs. Then retest the transfer that originally failed, from a new connection, and confirm the rule counters show the messages arriving.

If the large transfer still stalls after the messages are permitted, the remaining limit is elsewhere: a tunnel MTU that is set too high, a proxy that rewrites packets, or a middlebox that drops instead of reporting. The ICMP rule was necessary, not sufficient.