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@xxxxxxxxxxxx] 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
