Server

ICMP Beyond Ping: The Messages That Keep IP Working

By Prabath Thalangama· October 24, 2026· 3 min read
#networking#icmp#troubleshooting

Introduction

"Block all ICMP, it's a security risk" is folklore that causes real outages. ICMP is IP's control channel; a few types are essential to correct operation. This is what each one does and which you actually need to allow.

The messages that matter

Type/Code Name What breaks without it
3 / 4 Destination Unreachable — Fragmentation Needed Path MTU Discovery. Large packets silently dropped, connections hang after connecting
3 / 0,1,3 Dest Unreachable — net/host/port Fast failure. Without it, connections to a down host/closed port time out instead of failing instantly
11 / 0 Time Exceeded (TTL) traceroute, and loop detection
5 Redirect Suboptimal routing on a multi-gateway segment (often should be blocked, see below)
8 / 0 Echo Request / Reply ping — diagnostics, some load balancer health checks
12 Parameter Problem Malformed-header reporting

For IPv6, ICMPv6 is not optional at all — Neighbour Discovery (the ARP replacement), Router Advertisement, and "Packet Too Big" (the PMTUD message) are all ICMPv6. Blocking it breaks IPv6 entirely.

Why blanket blocking hurts

  • PMTUD black hole — the single most common ICMP-filtering casualty. A tunnel lowers the path MTU, the "fragmentation needed" message is dropped, the sender never shrinks its packets, and the connection stalls on the first big transfer. See Understanding MTU and Path MTU Discovery.
  • Slow failures — with "port unreachable" blocked, a client connecting to a closed UDP port waits for a full timeout instead of failing immediately.
  • Broken diagnostics — no ping, no traceroute, harder incident response.

Hands-on: sane ICMP filtering

Allow the essential types, rate-limit echo:

# IPv4 (iptables)
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp -j DROP
# Do NOT accept type 5 (redirect) from untrusted sources.

# IPv6 (ip6tables) — be permissive; ND lives here
ip6tables -A INPUT -p icmpv6 -j ACCEPT

nftables equivalent uses icmp type { destination-unreachable, time-exceeded, echo-request }.

Disable accepting redirects on hosts (they can be used to hijack traffic):

sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv6.conf.all.accept_redirects=0

Verification and troubleshooting

# Does the path pass "fragmentation needed"? (see the MTU post for the method)
ping -M do -s 1472 example.com

# Watch ICMP
sudo tcpdump -ni any icmp or icmp6

# Is the host generating unreachables?
sysctl net.ipv4.icmp_ratelimit net.ipv4.icmp_ratemask
  • TCP connects, then hangs on data — "fragmentation needed" is blocked somewhere. Allow ICMP type 3 code 4 end-to-end.
  • traceroute shows all * * * past a hop — that hop or the ones after drop "time exceeded". The path may still work for real traffic; traceroute just can't see it. Try traceroute -T (TCP) or -I (ICMP echo) — different filters block different probes.
  • Connections to closed ports take 2 minutes to fail — "port unreachable" (ICMP 3/3 for UDP, though TCP uses RST) is filtered. Allow destination- unreachable inbound.
  • IPv6 completely dead after a firewall change — you applied an IPv4-style "drop ICMP" rule to ip6tables. Revert; ICMPv6 must be allowed.
  • Ping flood concern — rate-limit echo-request rather than dropping it; -m limit --limit 5/s is plenty for legitimate diagnostics.
PrabathStuck on something this site can't fix?Reach out to Prabath directly on LinkedIn.