Cfrtjryk

I have setup my iptables to disable all incoming connection, i.e.

:INPUT DROP [0:65535]

When the iptables has been started, I run the following command to enable ping:

/usr/sbin/iptables -A INPUT -m icmp --icmp-state 8 -j ACCEPT

/usr/sbin/iptables -A INPUT -m icmp --icmp-state 0 -j ACCEPT

I saw the iptables rules are added from /etc/init.d/iptables status. I can ping the device from both Windows and Linux PC. Now I run the following command to remove them:

/usr/sbin/iptables -D INPUT -m icmp --icmp-state 8 -j ACCEPT

/usr/sbin/iptables -D INPUT -m icmp --icmp-state 0 -j ACCEPT

I saw the iptables rules are removed from /etc/init.d/iptables status. I cannot ping the device from Linux PC which is expected. However, I can ping the device from Windows PC for 1-2 minutes and then I cannot ping it afterwards.

I do not ping the device indefinitely (i.e. without -t) from my Windows XP PC but why do I get this results?

From all information you provided, I only guess that when you delete the rules, your Linux PC's ip address is not in iptables conntrack table anymore, so its traffic is dropped. The Windows PC's ip address may still appear in conntrack table, so its traffic is accepted.

iptables process each rule, from top to bottom. So the order of rules you defined in iptables is very important. In your case, your chain INPUT look like:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -s 127.0.0.0/255.0.0.0 -j ACCEPT

....

-A INPUT -m icmp --icmp-state 8 -j ACCEPT

-A INPUT -m icmp --icmp-state 0 -j ACCEPT

So you can see, even if you delete ICMP rules, if the client connection is in conntrack table, it's still accepted by iptables.

You can read about iptables conntrack table here:

When a connection has seen traffic in both directions, the conntrack
entry will erase the [UNREPLIED] flag, and then reset it. The entry
that tells us that the connection has not seen any traffic in both
directions, will be replaced by the [ASSURED] flag, to be found close
to the end of the entry. The [ASSURED] flag tells us that this
connection is assured and that it will not be erased if we reach the
maximum possible tracked connections. Thus, connections marked as
[ASSURED] will not be erased, contrary to the non-assured connections
(those not marked as [ASSURED]). How many connections that the
connection tracking table can hold depends upon a variable that can be
set through the ip-sysctl functions in recent kernels. The default
value held by this entry varies heavily depending on how much memory
you have. On 128 MB of RAM you will get 8192 possible entries, and at
256 MB of RAM, you will get 16376 entries. You can read and set your
settings through the /proc/sys/net/ipv4/ip_conntrack_max setting.

iptables maintains some state about previous/current connections which can cause changes you issue to iptables to seem to have a delay in being applied. To see and manipulate the state, you first need to have conntrack installed:

sudo apt-get conntrack

With that, you can then issue

sudo conntrack -L

to see a list of previous/current connections in the state.

You can clear this state completely by running

sudo conntrack -F

However, this will kill any currently open connections even if the current rules in effect would still allow them. You can be more fine-grained with what you can remove from the state table. Run

sudo conntrack

to get some basic help on the command. You typically are dealing with the "conntrack" table, which is what the command operates on if the table is not specified. For example, for my use case of turning on or off a NAT, I would run

sudo conntrack -D --any-nat

after issuing the appropriate iptables command to turn the nat off or on.

You can explicitly block the ICMP protocol by adding the rule at the beginning of your ruleset:

iptables -I INPUT -p icmp -j DROP

One thing to note, the RELATED,ESTABLISHED rule should be the last rule in your ruleset. Otherwise the ESTABLISHED state will match packets that are meant to match other rules eventually throwing off your counters and making debugging a nightmare, such as what you're currently experiencing

this is normal behavior and what RELATED,ESTABLISHED is supposed to do

"the RELATED,ESTABLISHED rule should be the last rule in your rulese" is complete nonsense, you don't want hop through the whole chain for every answer package and without an explicit reject/drop before it won't change the behavior anyways but making processing every single package more expensive because it's evaluating every rule and the last one accepts it

have fun pass the 838 million packages through 27 rules in the forward chain for no good reason - a proper ruleset is ordered by the rules with most hits on top and a final reject/drop rule at the end

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 838M 852G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
2 35M 1912M INBOUND all -- wan lan 0.0.0.0/0 0.0.0.0/0 0