I wanted to set a limit to the number of concurrent connections allowed on my web server. I tried the following rules on an iptables (v1.4.19.1) kernel 3.14.4-200.fc20.x86_64 with a default DROP policy for the INPUT chain under filter table:

-A INPUT -p tcp --dport 80 -m connlimit --connlimit-upto 10 -j WEB

Then, I hit the server with 50 concurrent connections using apache benchmark:

$ ab -kc 50 -t 10 http://mysite.com/

But, when I look at my server access log, I can still see a few hundred lines of successful requests. I am expecting the connlimit rule to kick in and drop all connections. Is there something wrong with my rules or my interpretation of concurrent connections?

  • 2
    Did you try benchmarking against something »bigger« than your / page? You could e.g. create an (apparently) 100MiB file with truncate -s 100M /path/inside/your/wwwroot/testfile and fetch this. I guess with fetching / the number of requests in your logs seem so high because they only take some microseconds, each, even if they are actually limited to 10 at a time. – Andreas Wiese May 13 '14 at 12:18
  • @AndreasWiese, I found out the reason why this is so. See if you agree to my answer below. – Question Overflow May 14 '14 at 2:49

After much testing, I found out that having a default drop policy is not enough,


It is very important not to assume that it would be followed. The connlimit rule would only kick in if you explicitly add a drop rule at the end of the chain:


It works now even at a lower concurrency than the limit specified:

$ ab -kc 7 -t 6 http://mysite.com/
This is ApacheBench, Version 2.3 <$Revision: 1554214 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking mysite.com (be patient)
apr_pollset_poll: The timeout specified has expired (70007)

The important thing is to test. Not sure if you would classify this as a bug though.

  • 1
    If that were true you'd have found a bug. However, what your iptables-save style line does not tell is what table this chain is tied into. INPUT chains also exist in the nat and mangle tables, for example - it's not visible into which table it goes. Besides, you do not state kernel or netfilter or iptables version. -1 – 0xC0000022L Jun 5 '14 at 2:04
  • @0xC0000022L, glad to have some feedback, otherwise it looks like I am talking to myself. I am referring to the filter table, not nat, not mangle. Will update this answer. By the way can you do some testing too, I would like to know if this is indeed a bug. – Question Overflow Jun 5 '14 at 3:12
  • The kernel and iptables versions are updated in the question itself. – Question Overflow Jun 5 '14 at 3:19
  • I know the feeling (talking to oneself). Retracted the downvote according to your edit. When I test it, it does actually work (i.e. setting a policy as opposed to rule at the end). One possible caveat are jumps and gotos. IIRC goto means you cannot return to the originating table, but with jump that's possible. The man page will know the details. Have to hit the bed for now. Will look for responses in a few hours from now. – 0xC0000022L Jun 5 '14 at 3:24

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.