Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Feb 2007 16:40:02 +0400
From:      admin <admin@azuni.net>
To:        Ian Smith <smithi@nimnet.asn.au>
Cc:        freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Andre Santos <andre.netvision.com.br@gmail.com>
Subject:   Re: ipfw limit src-addr woes
Message-ID:  <45D99AA2.7070406@azuni.net>
In-Reply-To: <Pine.BSF.3.96.1070219220011.26249A-100000@gaia.nimnet.asn.au>
References:  <Pine.BSF.3.96.1070219220011.26249A-100000@gaia.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
Ian Smith wrote:
> On Mon, 19 Feb 2007, admin wrote:
>  > Andre Santos wrote:
>  > > On 2/18/07, admin <admin@azuni.net> wrote:
>  > > 
>  > >> Hi, I'm trying to use ipfw's limit clause to limit the number of
>  > >> connections a single IP can have at the same time in a transparent
>  > >> web-proxy environment:
>  > >>
>  > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port
>  > >> 80 in via if0 setup limit src-addr 10
>  > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80
>  > >> ... the rest fwd...
>  > >>
>  > >> as I understand the manpage, when the current number of connectiions is
>  > >> below 10, the action "skipto" is performed, else, the packet is dropped
>  > >> and the search terminates. But...
> 
> No, a packet is not dropped on a condition that fails a skipto test. 
> 
The manpage doesn't make this point clear.
limit {src-addr | src-port | dst-addr | dst-port} N
              The firewall will only allow N connections with the same 

              set of parameters as specified in the rule.
      To limit the number of connections a user can open you can use the 
following type of rules:
            ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
            ipfw add allow tcp from any to me setup limit src-addr 4

I'm assuming the packet gets silently dropped when the limit is 
overloaded but gets acted upon otherwise due to the stateful "limit" 
behaviour (keep-state in disguise). Just do a "skipto" when there's a 
state entry and that's it. And that's why the counter grows for 
established connections too, even though there's a "setup" modifier.

skipto is a nice thing as it allows you to AND rules ;-)

Besides, that's what my humble testing came up with - connections over 
the limit DO get dropped... if done nicely.

As for the problem, it seems to me that all this noise is because of 
different timeouts in ipfw and TCP layer/whatever. The dynamic state 
entry for a connection expires while netstat -na still show the 
connection as ESTABLISHED, or, worse, the state entry is still there but 
the corresponding connection is in some half-closed state (FIN_WAIT_2, 
CLOSE_WAIT, LAST_ACK). The first case allows many more connections than 
"limit", while the second case won't let many good clients connect due 
to their buggy browsers not closing connections and letting the count 
build up. Could this be it?

>      skipto number
>              Skip all subsequent rules numbered less than number.  The search
>              continues with the first rule numbered number or higher.
> 
> You'll need a specific allow or deny rule; skipto does neither, it just
> branches to 401 if the condition is matched, otherwise proceeds to the
> next rule, which is also 401.  This runs rule 401 and on, either way. 
> 
>  > >> the problem is that the src-addr limit is not enforced as some clients
>  > >> somehow open a huge number (3-5 times the prescribed value) of
>  > >> www-connections to some single address Out There, forcing you to bump up
>  > >> certain sysctl variables (such as kern.ipc.nmbclusters,
>  > >> kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be
>  > >> going on? Is ipfw broken, or am I misusing it?
> 
> You've misread skipto, is all.  As it stands, the counts will show how
> many packets passed the test, but all packets proceed to the next rule. 
> 
> I'd rephrase rules to use skipto only for branching on condition, or
> !condition, past specific allow and/or deny rules to deal with this. 
> 
>  > >> OS: FreeBSD 6.2
>  > > 
>  > > 
>  > > The following command worked here (6.2-RC1). Only one connection was
>  > > allowed to 1.2.3.4.
>  > > # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1
>  > > 
>  > > Use the command "ipfw -d show" to see what connections are matching
>  > > your dynamic rules.
>  > > 
>  > 
>  > # ipfw -d show | fgrep x.x.x.x | wc -l
>  > 20
>  > $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l
>  > 113
>  > 
>  > Why is it that only 20 connections have been accounted for by ipfw's 
>  > dynamic rules but there are actually 113 active connections from that IP 
>  > at the moment? The limit src-addr is 75.
> 
> See above.  Sorry I didn't notice this when you first posted it.  I've
> not yet used limit src-addr myself, but use skipto a lot :)
> 
> Cheers, Ian
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45D99AA2.7070406>