> What's strange is that, when I run the same command to other machines, say 13.121.8.120, the http access is successfully rejected. Does that mean something wrong with the network configuration of the machine 13.121.8.119? What is the possible cause of that behavior? > This could have been possible only if the rule doesn't match it. Let's look at the rule: * -i eth0 ... If this doesn't match, it means that there is some other routing going on that uses another interface to route the packet to this particular IP address. Try pasting the routing table here, so that we can see. * -p tcp ... This has to be matched :) * --dport=80 ... Unless you're running the webserver on some other port, this is likely to match as well. So, it looks like the packet isn't arriving via interface eth0. > Another thing is quite strange, when capturing network trace from and to 13.121.8.119, I can't find any packet associated with the server which runs "iptables" command. However, when I was capturing network trace from and to 13.121.8.120 (which was successfully blocked), I can see some network packets associated with the server. You might have done the network trace on one interface. How many interfaces are there: * On the server * On the client (13.121.8.119) What is the server IP address? >From what you say, it looks like 13.121.8.119 and the server have established contact via an interface that is other than eth0. -- Vimal -- 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
