On 4/23/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx> wrote: > Do you have any plans to change that? OK, so apparently I was wrong. I just checked the source code and this is fact what connlimit does now. It keeps a hash of conntrack entries and counts them up when it gets fired. Therefore, the original rule proposed by robee would in fact work as rabbtux thought: iptables -A FORWARD -p tcp --syn -s 10.10.2.96/27 -m connlimit --connlimit-above 20 -j REJECT What this is really saying is: If the IP is between 10.10.2.97 and 10.10.2.126 and we find more than 20 connections from this IP right now in our internal table, jump to the REJECT target. You can specify the --connlimit-mask option to tell it to limit based on something more than a /32, but if you don't specify, /32 is the default. The rule should still probably be used with "-j REJECT --reject-with tcp-reset", though. Here's the information on the usage of the rule from netfilter.org: <snip> This adds an iptables match which allows you to restrict the number of parallel TCP connections to a server per client IP address (or address block). Examples: # allow 2 telnet connections per client host iptables -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT # you can also match the other way around: iptables -p tcp --syn --dport 23 -m connlimit ! --connlimit-above 2 -j ACCEPT # limit the nr of parallel http requests to 16 per class C sized # network (24 bit netmask) iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 16 \ --connlimit-mask 24 -j REJECT </snip> > I'd like a combination of hashlimit and connlimit which also works > for UDP so I can limit the number of simultaneous connections per > IP to avoid overflowing the conntrack table of upstream firewalls. connlimit was designed with TCP in mind and will refuse to be loaded with anything other than -p tcp. This is because it wants to make sure you're using --syn to only operate on the first packet of a connection, and also b/c it will dump some conntrack entries in its hashtable if the TCP state indicates that the connection is terminated. As well, I'm not so sure the combination of the two would be a good idea. I think you'd want the connlimit rules fronting for the hashlimit rules. Having both in one module makes changes to the ruleset more coarse-grained, which could potentially lead to requiring bigger changes to do what you want to do later on down the road. Sorry about my initial confusion on this whole thing: I was thinking of a different, older *limit rule. -- Toby DiPasquale 0x636f6465736c696e67657240676d61696c2e636f6d
