Re: ICMP question

[Joel Newkirk <netfilter@newkirk.us>]

On Thursday 14 November 2002 01:28 pm, Luis Fernando Barrera wrote:

> iptables -A FORWARD -p ICMP -s 192.168.1.37 -m state --state
> NEW,ESTABLISHED -j ACCEPT
> iptables -A FORWARD -p ICMP -d 192.168.1.37 -m state --state ESTABLISHED -j
> ACCEPT
>
> I've been experiencing the problem that with this set of rules, suddenly,
> the PC in the LAN cannot "ping" any hosts in the Internet. To solve the
> problem

> iptables -A FORWARD -p ICMP -s 192.168.1.37 -j ACCEPT
> iptables -A FORWARD -p ICMP -d 192.168.1.37 -j ACCEPT
>
> These are the same rules, except that don't track the state of the
> connections...
>
> Could someone tell me what is the risk asociated to NOT to track the
> connections?

For the first rule just use the second version (without state match), but for 
the second rule you want state as it will prevent any ICMP connections 
originating anywhere else from being forwarded to that IP, assuming other 
rules and policy don't ACCEPT it.  (and assuming you don't want that...)  The 
new pair would then allow any ICMP through that came FROM 192.168.1.37, and 
prevent any ICMP from going TO 192.168.1.37 UNLESS it is part of an 
established connection, IE a response to a ping that was ACCEPTed by the 
first rule.

Using the state matches can help you tighten things up considerably, and also 
considerably reduce the number of rules you need to explicitly define.  You 
can allow a local machine out only to port 80 and 53, nothing back to it at 
all, then accept ESTABLISHED/RELATED both ways and everything will work, 
because the responses back to the local machine, and even ICMP messages 
related to the connection, are matched based on state.

> One more question... Is it true that when you specify the ICMP protocol,
> iptables only
> applies the rule to the type 0?

Nope, unless it's a bug in a version other than 1.2.5, I just tested.  (Ping 
my ISP's DNS, nothing, added ICMP rule with no type specified, 18.2ms)

> thanks in advance
>
> Luis Fernando Barrera
> luba@assist.com.gt

j