PF in /etc/rc.d: some issues

[Yar Tikhiy]

On Thu, Sep 22, 2005 at 02:12:52PM +0200, Max Laier wrote:
> On Thursday 22 September 2005 13:20, Yar Tikhiy wrote:
> 
> > First, in the presence of vlan's or other dynamic interfaces it can
> > be hard to ensure that pfsync0 will appear after its syncdev on the
> > final list of interfaces built inside /etc/network.subr from several
> > rc.conf variables and other sources.  Consequently, pfsync0 won't
> > get up because it is configured before its syncdev is up and running.
> > IMHO, this problem can be addressed by creating a separate rcNG script
> > for pfsync, which I already did in my systems using PF (see below.)
> 
> Sounds reasonable, but put at least an additional $pfsync_ifconfig_flags at 
> the end of the ifconfig so that people can specify maxupd.  pfsync.4 needs to 
> be updated for this as well.

Just added src/etc/rc.d/pfsync, wired it to the system and updated
the relevant manpages.  The rc.conf variables are pfsync_enable,
pfsync_syncdev and pfsync_ifconfig, the latter being optional.

> > Second, /etc/rc.d/pf script starts before DAEMON and LOGIN, which
> > is too late IMHO.  Can we make it start before "routing"?  In an
> > ideal world, a firewall should start before "netif", but I'm unsure
> > if PF can start when not all interfaces mentioned in pf.conf are
> > present in the system yet.
> 
> The only remaining problem (that I know of) is "set loginterface" on a 
> non-existing interface.  Everything else should be taken care of by now.  
> This late startup was in fact a bandaid to get things working back then, but 
> the problems have been shaken out and now that "set loginterface" is more or 
> less obsolete by $pfctl -vsI -i <interface> anyway, we could move it back to 
> where it belongs.  I'd like to keep that change in HEAD for the time being, 
> however.

It appears we cannot start pf before netif since we have rc.d/pfsync
now, which should start before pf, but after netif.  So I made pf
start before routing for now.  No network services should be running
at that time anyway.  This change won't affect "set loginterface",
so it should be safe to MFC it to RELENG_6, shouldn't it?

-- 
Yar