From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 17:26:13 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 4A59A16A400; Thu, 22 Feb 2007 17:26:13 +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 3732413C442; Thu, 22 Feb 2007 17:26:10 +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 EAA06297; Fri, 23 Feb 2007 04:25:46 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 23 Feb 2007 04:25:46 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <45DC9AAC.8090301@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: Thu, 22 Feb 2007 17:26:13 -0000 On Wed, 21 Feb 2007, Julian Elischer wrote: > Ian Smith wrote: > > 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? > > if the keep-state rule is a skipto then the check-state will skip to.. > I use that in some rules. > > here's a snippet that I have when acting as a filtering transparent bridge, > with DNS replies (from the outside) being diverted to a snooper. > The bridge is between em2 (inside) and em3 (outside). > > 01200 17588453 1257728932 skipto 1210 udp from any to any dst-port 53 recv em2 > 01201 16192860 2721432229 skipto 1220 udp from any 53 to any recv em3 > 01202 43658738 21537916245 skipto 1250 ip from any to any > 01210 34023270 3994649771 skipto 1240 ip from any to any keep-state > 01220 0 0 check-state > 01229 2364 441701 deny ip from any to any > 01240 16190496 2720990528 divert 5001 udp from any 53 to any recv em3 > 01242 17832774 1273659243 deny ip from any to any > > (note this requires patches to allow divert from a bridge.) > It's convoluted I know but it only (well, mostly) diverts packets from > the outside that are part of a conversation that was started already > (probably by a dns request from inside) DNS packets from the outside > that are not a response to something we already asked for are discarded > (a DOS protection) > > note that all the packets that went to the check-state, (1220) ended up > going back to 1210 where they did the skipto 1240 and were filtered again. Thanks Julian, great illustration! After much chewing I've got most of the marrow, but have buried this bone where I can dig it up again (woof) Re admin's issue, I notice that the em3 packets failing check-state still require denying at 1229, such that p(kts)1201 - p1229 = p1240. Do you have any earlier rules jumping into here too, as the 1210 packet counts don't quite add up; ie p1210 > (p1200 + p1240) by ~244k packets? Re 1242, are these (mostly) diverted packets reentering the firewall? After snooping, how do the clients get their DNS replies if they're denied here, or does your divert code reinsert those elsewhere? And where do the then ~1.2M extra denied packets denied here come from? Cheers, Ian