3

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 -A WEB -j ACCEPT

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?

Improve this question
2
  • 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. Commented May 13, 2014 at 12:18
  • @AndreasWiese, I found out the reason why this is so. See if you agree to my answer below. Commented May 14, 2014 at 2:49

1 Answer 1

Reset to default
1

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

*filter -F -X :INPUT DROP [0:0]

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:

-A INPUT -j DROP

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.

Improve this answer
4
  • 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 Commented Jun 5, 2014 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. Commented Jun 5, 2014 at 3:12
  • The kernel and iptables versions are updated in the question itself. Commented Jun 5, 2014 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. Commented Jun 5, 2014 at 3:24

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.