When dealing with iptables, the RELATED state in conntrack is designed to handle protocol-specific auxiliary connections. For TCP, this typically means FTP data connections, while for ICMP it handles error messages related to existing connections.

# Basic rule accepting established/related connections
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

The critical question is whether "useful" ICMP messages like:

• destination-unreachable (type 3)
• time-exceeded (type 11)
• parameter-problem (type 12)

are properly handled by the RELATED state. The answer depends on your kernel version and conntrack implementation.

To verify behavior, you can use tcpdump while testing:

tcpdump -ni eth0 'icmp and (icmp[0] == 3 or icmp[0] == 11 or icmp[0] == 12)'

For maximum compatibility across kernel versions, explicit rules are recommended:

# Accept important ICMP error messages
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT

Modern kernels (≥ 3.10) generally handle these ICMP types as RELATED when they reference an existing conntrack entry. However, some scenarios might require explicit rules:

• When using stateless firewall rules
• With certain NAT configurations
• When dealing with fragmented packets

Here's a more complete example covering both scenarios:

# Connection tracking
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED -j ACCEPT

# Explicit ICMP rules (optional but recommended)
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT

When configuring iptables firewall rules, many administrators wonder about the proper way to handle ICMP error messages while using connection tracking (conntrack). The core question revolves around whether these messages are automatically handled by the RELATED state or require explicit rules.

The RELATED state in iptables is designed to handle protocol-specific helper connections that are logically associated with an existing connection. For TCP, this includes things like FTP data connections. For ICMP, certain error messages are indeed classified as RELATED when they reference an existing connection.

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

While many ICMP error messages will be caught by the RELATED state, there are cases where explicit rules are beneficial:

• Destination Unreachable (type 3): Helps with path MTU discovery
• Time Exceeded (type 11): Useful for traceroute functionality
• Parameter Problem (type 12): Important for protocol operation

For comprehensive ICMP handling, consider these rules:

# Basic connection acceptance
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow ping requests if desired
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Explicitly allow important ICMP error messages
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT

# Rate limit ICMP to prevent floods
-A INPUT -p icmp -m limit --limit 1/second --limit-burst 5 -j ACCEPT
-A INPUT -p icmp -j DROP

To verify your ICMP rules are working:

# Check if Destination Unreachable is getting through
ping -M do -s 1500 example.com

# Test Time Exceeded with traceroute
traceroute example.com

# Check conntrack state for ICMP
conntrack -L | grep icmp

For more complex networks:

# Allow ICMP from specific networks only
-A INPUT -s 192.168.1.0/24 -p icmp --icmp-type destination-unreachable -j ACCEPT

# Create separate chains for ICMP handling
:NICMP - [0:0]
-A INPUT -p icmp -j NICMP
-A NICMP -m conntrack --ctstate RELATED -j ACCEPT
-A NICMP -p icmp --icmp-type echo-request -j ACCEPT