RE: Limit rule for ICMP not working properly?

["podo" <podo@hnup.de>]

Hi Phil,
Yes, I ment the 3th rule (Established accept).

Please what do you mean by "same ID" ? And is this not exactly the problem ?
nf_conntrack is even not needed, when only the first rule is present:
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT

ICMP should not be tracked as established...
In my opinion the behaviour is not correct. 

Podo

-----Original Message-----
From: Phil Oester [mailto:kernel@linuxace.com] 
Sent: 05 September, 2013 17:12
To: podo
Cc: 'netfilter'
Subject: Re: Limit rule for ICMP not working properly?

On Thu, Sep 05, 2013 at 04:58:27PM +0200, podo wrote:
> Hi,
> 
> the default is DROP:
> 
> iptables -L -n -v
> Chain INPUT (policy DROP 314 packets, 98684 bytes)
> pkts bytes target     prot opt in     out     source
> destination
>   963 66540 ACCEPT     tcp  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>    29  1740 ACCEPT     icmp --  *      *       0.0.0.0/0
> 0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
>    39  2836 ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0            state ESTABLISHED
> 
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source
> destination
> 
> Chain OUTPUT (policy ACCEPT 5384 packets, 387K bytes)
> pkts bytes target     prot opt in     out     source
> destination
> 
> The problem is, that the second rule gets hit, even if it shoud not (my
> opinion). ICMP can not be "established". Or ?

I think you mean _third_ rule in the above example.  When you successfully
ping the box, an entry is added to /proc/net/nf_conntrack.  Until that
entry expires (30 seconds by default for icmp), then any additional icmp
packet with the same ID will match that conntrack entry and be considered
"established".  

Wait > 30 seconds between (single) pings and you should not see the
established
rule hitcount increasing.

Phil