From owner-freebsd-pf@FreeBSD.ORG Mon Jun 15 19:26:05 2009 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14CF106567C for ; Mon, 15 Jun 2009 19:26:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8488FC12 for ; Mon, 15 Jun 2009 19:26:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23421 invoked by uid 399); 15 Jun 2009 19:26:01 -0000 Received: from localhost (HELO ?10.9.1.131?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Jun 2009 19:26:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A36A051.3040007@FreeBSD.org> Date: Mon, 15 Jun 2009 12:26:09 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gert Doering References: <4A242035.8010101@FreeBSD.org> <20090615065817.GJ290@greenie.muc.de> In-Reply-To: <20090615065817.GJ290@greenie.muc.de> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-pf@FreeBSD.org Subject: Re: Moving the pf rc.d scripts to run before netif X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:26:06 -0000 Gert Doering wrote: > Hi Doug, > > thanks for taking this up - and sorry for not responding more timely. > > I can't answer all the questions but might have a yet-unmentioned idea > that could solve all this in one go :-) > > On Mon, Jun 01, 2009 at 11:38:45AM -0700, Doug Barton wrote: >> 2. The previous rcorder for the pf script was right after netif (the >> network coming up) and before routing .... why? Is this related to how >> pf does its work? The reason I ask this question is that in order to >> fix the IPv6 rcorder problem in the pr the way that Gert is suggesting >> the "BEFORE: routing" would have to be removed because our IPv6 >> startup depends on RA which depends on routing being up. (Side note, >> in the long term I'd like to revise this so that an IPv6-only host >> and/or a host with statically assigned IPv6 addresses can easily be >> configured within rc.d, but that's another thing altogether.) >> >> 3. Is the need to be able to use $ext_if after the network is up so >> overwhelmingly important that it justifies running pf after netif? Or >> is using ($ext_if) a reasonable solution? > > Well - let's turn this one around: since we *have* the functionality in > pf(4), let's not cripple it by building a framework that makes using this > functionality effectively impossible. If I understand Bjoern right, this > is also a performance issue - ($ext_if) needs a per-packet lookup to > get the now-current address, while $ext_if reads the address at pf setup > time. > > > I can see the arguments for having the firewall initialization right at > the start - to avoid opening an window of opportunity where services are > "up" but the firewall hasn't yet been loaded. > > > So what about the following approach: > > - split the firewall initialization into two halves > > - the first half is run before any other networking stuff is configured > and basically sets up a "deny everything incoming" filter (with > exceptions for IPv6 RD/ND, of course). > > Optionally this could permit outbound connections (with state), to > enable things like bgpd to run. > > - after this, run interface configuration, set up routing, ... > > - when all this is finished, load the "real" set of firewall rules, > which can now (if so desired) safely use $ext_if I already said I support this solution, I'm just waiting for someone with some real pf knowledge to propose something. Doug