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 -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  --  anywhere

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

    iptables -I INPUT 2 -j DROP
    iptables -L


    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     all  --       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 -j ACCEPT one?)

And why there are different outputs of the source? before adding DROP, and 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.

  • possible duplicate of iptables -L pretty slow. Is this normal? – mgorven Feb 5 '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. – ArtM Feb 5 '13 at 23:59

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 network that is being accepted.

| improve this answer | |
  • 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 and is strange for me. – ArtM Feb 6 '13 at 0: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, then you will have DROPPED the packets. As for the -in-addr.arpa, see en.wikipedia.org/wiki/Reverse_DNS_lookup, and en.wikipedia.org/wiki/.arpa. Or to say it more clearly, if you DROP packets, then you DROP packets. – Zoredache Feb 6 '13 at 0: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? – ArtM Feb 6 '13 at 0: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 6 '13 at 0: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. – ArtM Feb 6 '13 at 1:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.