Date: Mon, 15 Jun 2009 08:58:17 +0200 From: Gert Doering <gert@greenie.muc.de> To: Doug Barton <dougb@FreeBSD.org> Cc: bzeeb-lists@lists.zabbadoz.net, Gert Doering <gert@greenie.muc.de>, freebsd-pf@FreeBSD.org Subject: Re: Moving the pf rc.d scripts to run before netif Message-ID: <20090615065817.GJ290@greenie.muc.de> In-Reply-To: <4A242035.8010101@FreeBSD.org> References: <4A242035.8010101@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090615065817.GJ290>