Why Dropping All ICMP Breaks Path MTU Discovery

Many firewall guides still advise dropping all incoming ICMP packets. Administrators add iptables -A INPUT -p icmp -j DROP or a catch-all drop in nftables, assuming that silent treatment conceals their servers from attackers on the public internet. The belief persists that if a host ignores ping requests, port scanners will skip past it and move to another target.

Myth

The myth assumes that dropping all ICMP traffic turns your host invisible. Proponents claim that disabling ICMP stops reconnaissance tools, prevents denial-of-service floods, and hides running network services from automated scans.

Filtering ping packets does not prevent host discovery. It only disables the diagnostic signaling that the internet requires to route large packets.

Under this mindset, ICMP is treated as an optional debugging tool instead of an integral part of the IP protocol architecture.

Reality

Modern internet scanners do not rely on ICMP Echo Requests. Tools like ZMap and Masscan sweep entire IPv4 address ranges in minutes by sending raw TCP SYN packets directly to target ports like 80, 443, and 22. If a port is open, the kernel returns a SYN-ACK packet. If a port is closed, the host sends an RST packet unless explicitly dropped. In either situation, the host announces its presence without receiving a single ICMP packet. Even when all closed ports drop silently, an attacker scanning for open web servers or SSH daemons discovers the machine the instant an open service replies.

Worse, dropping all ICMP traffic destroys Path MTU Discovery (PMTUD, RFC 1191). The maximum transmission unit (MTU) represents the largest IP packet size an interface can forward without fragmentation. Standard Ethernet uses an MTU of 1500 bytes. However, traffic passing through tunnels, VPNs like WireGuard, PPPoE uplinks, or cloud overlays often traverses links with lower MTUs, such as 1420 or 1440 bytes.

To prevent IP packet fragmentation, TCP connections set the Don’t Fragment (DF) bit in the IPv4 header. When an intermediate router receives a 1500-byte packet that exceeds its outgoing interface MTU, it must drop the packet. The router then generates an ICMP Type 3, Code 4 message: “Destination Unreachable, Fragmentation Needed and DF set.” This message includes the next-hop MTU so the transmitting host can adjust its maximum segment size (MSS).

When a firewall drops all incoming ICMP, that error packet is discarded before reaching the local network stack. The operating system never learns that the packet was too large. This failure causes a Path MTU black hole:

• Small packets succeed: The initial TCP three-way handshake completes instantly because SYN and ACK segments are only 60 bytes.
• Large packets vanish: As soon as the application transmits application data, such as a TLS certificate exchange or an HTTP response exceeding 1420 bytes, the intermediate router drops it.
• Connections freeze: The client or server waits for an acknowledgment that never arrives, retransmitting until the TCP connection times out after several minutes.

In IPv6, the problem is more severe. IPv6 routers never fragment transit packets; Path MTU Discovery via ICMPv6 Type 2 (“Packet Too Big”) is mandatory by specification. Dropping ICMPv6 breaks IPv6 connectivity entirely.

How to protect

The correct strategy is selective filtering. Keep ICMP control messages open while rate-limiting Echo Requests to prevent abuse.

In modern Linux distributions using nftables, configure explicit rules for necessary ICMP types instead of blanket drops:

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;

        # Accept established and related traffic
        ct state established,related accept
        iif "lo" accept

        # Permit essential IPv4 ICMP types
        ip protocol icmp icmp type {
            destination-unreachable,
            time-exceeded,
            parameter-problem
        } accept

        # Rate-limit ICMP echo requests (ping)
        ip protocol icmp icmp type echo-request limit rate 5/second burst 10 packets accept

        # Permit essential IPv6 ICMP types (RFC 4890)
        ip6 nexthdr icmpv6 icmpv6 type {
            destination-unreachable,
            packet-too-big,
            time-exceeded,
            parameter-problem,
            nd-router-solicit,
            nd-router-advert,
            nd-neighbor-solicit,
            nd-neighbor-advert
        } accept

        # Rate-limit IPv6 echo requests
        ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 5/second burst 10 packets accept

        # Accept required application ports
        tcp dport { 22, 443 } ct state new accept
    }
}

If you must handle broken upstream networks where intermediate routers drop ICMP error notifications outside your control, configure Linux to enable Packetization Layer Path MTU Discovery (PLPMTUD, RFC 4821). This allows the TCP stack to probe for working packet sizes without relying on ICMP:

# Enable TCP MTU probing (1 = probe when black hole detected, 2 = always probe)
sudo sysctl -w net.ipv4.tcp_mtu_probing=1

# Persist the setting
echo "net.ipv4.tcp_mtu_probing = 1" | sudo tee /etc/sysctl.d/99-pmtud.conf

You can diagnose suspected MTU black holes directly from the command line using tracepath or ping with the DF bit set:

# Test path MTU to remote host using Don't Fragment packets
ping -M do -s 1472 198.51.100.1

# Trace the exact MTU boundary along the routing path
tracepath 198.51.100.1

Treating ICMP as an enemy weakens network reliability without improving security. Allow control messages, rate-limit echo requests, and keep your transport layer responsive.