I am using the following simple iptables rule that accepts related packets:

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

I am letting ICMP echo-requests pass with this other rule:

-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Should I explicitly add anything to receive "useful" ICMP messages like destination-unreachable, time-exceeded and parameter-problem, or the RELATED clause will already accept them?


5 Answers 5



Another hugely important part of ICMP is the fact that it is used to tell the hosts what happened to specific UDP and TCP connections or connection attempts. For this simple reason, ICMP replies will very often be recognized as RELATED to original connections or connection attempts. A simple example would be the ICMP Host unreachable or ICMP Network unreachable. These should always be spawned back to our host if it attempts an unsuccessful connection to some other host, but the network or host in question could be down, and hence the last router trying to reach the site in question will reply with an ICMP message telling us about it. In this case, the ICMP reply is considered as a RELATED packet

  • 2
    This netfilter feature needs some advertising. All iptables tutorials I found either suggest to block, or to allow icmp and icmpv6 inconditionally. The clean solution for home router users is a RELATED rule with topmost priority. Apr 8, 2018 at 12:17

The RELATED rule will take care of the associated ICMP messages by default. From iptables man page, in the section related to conntrack (http://linux.die.net/man/8/iptables):

RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

Other states reported by conntrack are:

  • INVALID meaning that the packet is associated with no known connection
  • ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions
  • NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions
  • SNAT A virtual state, matching if the original source address differs from the reply destination
  • DNAT A virtual state, matching if the original destination differs from the reply source

You can examine and manage the conntrack table using the conntrack package.

$ sudo conntrack -L

In general is a very bad idea to filter or block icmp, usually the only "valid" bit of icmp to filter is echo-request to "appear" down in a naïve scan.

But if you want to explicit allow parts of it you are missing at least two very important bits, fragmentation needed & Source Quench:

-A INPUT -p icmp --icmp-type fragmentation-needed -m state --state NEW -j ACCEPT
-A INPUT -p icmp --icmp-type source-quench -m state --state NEW -j ACCEPT

Let me tell you again that filtering icmp is a bad idea that will mask problems and make it difficult to discover.

That was the problem with DF (don't fragment) and fragmentation-needed which is needed for automatic PTMU discovery and caused sites to be inaccessible because intermediate firewalls/routers dropped the icmp packets advertising the endpoint to lower the MTU.

  • +1. Great answer. Never block fragmentation-needed, and most importantly, never ever block ICMPv6 "Packet Too Big". Oct 5, 2014 at 23:41
  • 2
    Hasn't source-quench been deprecated in 2012? tools.ietf.org/html/rfc6633#section-2
    – S19N
    Oct 6, 2014 at 13:38
  • @S19N you are right, that was a bit I remembered from long time ago, I didn't new it was deprecated. Oct 7, 2014 at 6:42
  • 3
    Wouldn't fragmentation needed ICMP packet classify as RELATED, and as such taken care of by the rule presented in the question? May 4, 2019 at 11:05

I'll add my own answer to provide my final configuration, inspired by other answers and the following sources:

  1. an expired draft by IETF with a useful table which shows which ICMP types allow, deny or rate limit;

  2. another page with the minimum lines for iptables and Cisco IOS;

  3. a third resource which uses RELATED:

    iptables -P INPUT DROP
    iptables -A INPUT -p icmp --fragment -j DROP
    iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
    iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
  • Be aware that blindly filtering may lead you to problems. See the ones it caused when ECN bit in TCP began to be used and firewalls with obsolete configurations blindly dropped this SYN packets: icir.org/floyd/ecnProblems.html Oct 7, 2014 at 6:49
  • You mean that there could be new ICMP types that could be useful to accept in the future? I agree, but I consider a 'firewall with obsolete configuration' a problem by itself, so I am willing to update the rules as needed.
    – S19N
    Oct 7, 2014 at 9:47

ICMP is a very important connection protocol. The "echo-request" is the only important useful message that helps communication. Rest of them including "destination-unreachable" is safe to block specially if the application you're running receives a large number of unknown hits.

You're better off with something like this,

-A INPUT -p icmp --icmp-type echo-request -m recent --set 
-A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 1 --hitcount 30 -j DROP 

-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

-A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP
-A INPUT -p icmp -j DROP

This would not only accept "echo-request" but also block ping floods greater than 30 packets/s. Anything else you want to add has to explicitly be accepted because the RELATED clause will not receive them as long as the connection is established by letting it in.

  • If you rate-limit ICMP, it's important to remember that you can no longer use this host to gauge packet loss via ICMP during network debugging/diagnostics! 2c. TW Oct 5, 2014 at 23:36
  • I usually rate limit echo-request with --limit and --limit-burst that are global counters with a high enough limit to not cause problems, but you can also use --hashlimit-mode srcip and have per-ip counters, or even whitelist the sending host. Oct 7, 2014 at 6:54
  • destination-unreachable/* is NOT safe to block, this is what causes PMTU black holes.
    – figtrap
    Sep 23, 2016 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.