Moving the pf rc.d scripts to run before netif

Gert Doering gert at greenie.muc.de
Mon Jun 15 06:58:32 UTC 2009


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 at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de


More information about the freebsd-pf mailing list