iptables, ICMP and RELATED

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?

Solution 1:

http://www.linuxtopia.org/Linux_Firewall_iptables/x1571.html

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

Solution 2:

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

Solution 3:

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.