Moving the pf rc.d scripts to run before netif

[Doug Barton]

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