On Friday 2012-05-25 11:50, Eric Petit wrote: >On May 23, 2012, at 5:29 PM, Eric Petit wrote: >> I am trying to limit the total number of concurrent connections that may be established on a given port. I need additional connection attempts to be explicitly rejected, so I went for something like: >> >> iptables -P INPUT DROP >> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >> iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 512 --connlimit-mask 0 -j REJECT >> iptables -A INPUT -p tcp --dport 80 -j ACCEPT >> >> My problem is, when the limit is reached and new connections are rejected, those stay in the conntrack table in a SYN_SENT / UNREPLIED state, and are only cleaned up after 120 seconds (ip_conntrack_tcp_timeout_syn_sent). As such, they are accounted for as active connections by connlimit, and new connections keep being rejected even though the number of established connections is, in fact, lower than the limit that I set. If connections keep coming in at a fast pace, it may just never accept a connection again. I've tried "--reject-with tcp-reset" and the behavior was the same. > >Finally figured this out - those conntrack entries weren't, in fact >related to connlimit rejecting connections. The SYNs were unreplied >because SYN flood protection kicked in when I tested by throwing lots >of connections at it. I have enabled SYN cookies and things are now >working as expected. Odd, because I could reproduce what you described (with as few as 3..5 connections). -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
