1

I'm starting with an empty iptables structure, all tables and chains are the default ones with the ACCEPT default policy. Steps to reproduce: 

    iptables -I INPUT -s 192.168.0.1/24 -j ACCEPT
    iptables -L

at this point I get the following output (other chains remain unchanged, so I'm skiping them): 

    Chain INPUT (policy ACCEPT)
    target     prot opt source                       destination
    ACCEPT     all  --  0.0.168.192.in-addr.arpa/24  anywhere

The output is printed without any issyes. Then I add a DROP rule: 

    iptables -I INPUT 2 -j DROP
    iptables -L

output

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     all  --  192.168.0.0/24       anywhere
    DROP       all  --  anywhere             anywhere

This second iptables -L makes the output to be printed with a huge delay (25-30 seconds) between the first two header lines and the rules themselves.

Questions: Why adding a DROP rule makes the -L command to run with a delay in the middle? (yes, I know that a it tries to do a reverse DNS lookup, but why after adding a DROP rule and not after adding the -s 192.168.0.1/24 -j ACCEPT one?)

And why there are different outputs of the source? 0.0.168.192.in-addr.arpa/24 before adding DROP, and 192.168.0.0/24 after.

And yes, I've found and read iptables -L pretty slow. Is this normal?. Using -n makes the output to be printed wihtout delays.

Community
  • 1
ArtMat
  • 169
  • 1
  • 6
  • possible duplicate of [iptables -L pretty slow. Is this normal?](http://serverfault.com/questions/85602/iptables-l-pretty-slow-is-this-normal) – mgorven Feb 05 '13 at 20:54
  • @mgorven: I've mentioned about this Q. I'm not asking how to make it quick, but why a DROP rule triggers this slowness while the previous rule that specifies the IP deosn't. It would be logically to have this effect after adding just the first rule. – ArtMat Feb 05 '13 at 23:59

1 Answers1

3

Add a -n to your iptables -L. That will speed up your command. Then look at your DNS resolver settings. My bet is that you are pointing at a DNS server outside of the 192.168.0.0/24 network that is being accepted.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
  • Sorry, but probably you got wrongly the focus of the question. As I wrote above, I know that `-n` will speed up the `-L` command, but the question is why a DROP rule triggers it. It would be logically to get this slowness just after adding the first rule because even the first ACCEPT should process the packets. And also the difference between `0.0.168.192.in-addr.arpa` and `192.168.0.0` is strange for me. – ArtMat Feb 06 '13 at 00:08
  • Did you read the third and fourth sentences? What is unclear? If your machine depends uses a DNS server that is outside of of the `192.168.0.0/24`, then you will have DROPPED the packets. As for the `-in-addr.arpa`, see http://en.wikipedia.org/wiki/Reverse_DNS_lookup, and http://en.wikipedia.org/wiki/.arpa. Or to say it more clearly, if you DROP packets, then you DROP packets. – Zoredache Feb 06 '13 at 00:41
  • But I'm dropping packets of the INPUT chain, i.e. coming from outside world to the PC. Or do I get wrongly this point of the filter:INPUT chain? – ArtMat Feb 06 '13 at 00:45
  • Every single packet passes through netfilter, and will be handled in some way. If you make a DNS request from that computer, then your REQUEST packet will be hit t he OUTPUT chain. The **REPLY** to your request, will hit the INPUT chain. – Zoredache Feb 06 '13 at 00:48
  • Thanks. Yes, REPLY packets, this is definetly the point that skipped to me. Probably it would be useful to mention these details in your answer, so others serching for this subject could read it there and not in comments. Now all the pieces of the puzzle fell into place. – ArtMat Feb 06 '13 at 01:13