From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 07:56:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FFA916AA93; Wed, 21 Feb 2007 07:56:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF8F13C442; Wed, 21 Feb 2007 07:56:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id SAA13714; Wed, 21 Feb 2007 18:56:03 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 21 Feb 2007 18:56:02 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <45DB821D.4050508@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: admin , freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 07:56:25 -0000 On Tue, 20 Feb 2007, Julian Elischer wrote: > admin wrote: > > > Wrong: the implied "check-state" done by the "limit" lets the connection > > through (i.e. performs the action) iff there's state recorded for it > > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > > incoming and the number of current states is trying to cross the limit, > > the SYN packet is implicitly dropped and the search terminates. > > > > This is not to say that I completely understand the things going on when > > the connections start building up (different timeouts?) but the above > > conclusion is based on what simulation has shown. The whole ruleset fits > > on one screen, there's an "allow ip from any to any" in the end, so I'm > > pretty sure I'm not crazy :-) > > One thing to keep in mind is that a 'check-state' rule works by effectively > jumping to the rule that did the 'keep-state' and re-executing it.. > (and incrementing its stats). What if the action of the rule that does the 'keep-state' (here a limit src-addr) is a skipto, rather than an allow / fwd / divert etc rule that would terminate the search? Does 're-executing' here imply anything about whether the skipto's conditional branch is or is not taken? I bought into this because admin said that more connections were being allowed than the limit src-addr clause should allow, and I assumed that the skipto branch was not being taken on over-limit packets, and that the following fwd rule (allowing any type of packets including SYN) was being executed, which would account for what he'd said was happening. admin above asserts that my assumption was wrong, and that in a match beyond the limit number of connections for that src/dest address, the setup packet is 'implicitly dropped and the search terminates', and while I can't find that stated as such in ipfw(8), he may be right. Which still doesn't explain why connections from a particular IP beyond his specified limit are allowed to be established, as originally stated. [shrug] Over to the ipfw gurus. Cheers, Ian