Test environment: CentOS 6.3 - kernel 2.6.32-279.el6.i686, iptables v1.4.7 Win7 <---> CentOS Windows is constantly replaying ICMP echo request in 10pkt/sec rate to CentOS. In iptables, I added the rules as below to limit the incoming icmp request packet rate. But it didn't work. Because after the 1st incoming icmp request was accepted by the 1st rule and my host replied, all the following ICMP request will accepted by the 2nd rule, which will accept the incoming ICMPrequest as ESTABLISHED state packet. I think this doesn't make sense. ACCEPT icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 1 ACCEPT all -- anywhere anywhere state ESTABLISHED DROP icmp -- anywhere anywhere Expected result: 1 pkt/sec will be accepted by CentOS and 1 reply will be sent out, while other 9 requests will be drop by the last rule. Observed result: 1 pkt/sec accepted by the first rule and the other 9 were accepted by the second rule. 10 echo reply were sent back. No pkt dropped. I checked the "Iptables Tutorial 1.2.2" and I found the statement as below. "The reply packet is considered as being ESTABLISHED, as we have already explained. However, we can know for sure that after the ICMP reply, there will be absolutely no more legal traffic in the same connection. For this reason, the connection tracking entry is destroyed once the reply has traveled all the way through the Netfilter structure. In each of the above cases, the request is considered as NEW, while the reply is considered as ESTABLISHED." However, I found the conntrack entry was always there in /proc/net/nf_conntrack after the first reply was sent. It will only be deleted after 29 seconds once an ICMP connection is established. ipv4 2 icmp 1 24 src=192.168.56.1 dst=192.168.56.101 type=8 code=0 id=1 src=192.168.56.101 dst=192.168.56.1 type=0 code=0 id=1 mark=0 secmark=0 use=2 I think each incoming ICMP request should be treated as NEW state not ESTABLISHED even an ICMP connection has been established. Correct me if I don't understand the state match in a proper way. Regards, Ronnie. -- 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
