fbsd 6.2 pf starts -- but not on boot

[Volker]

Hi snow,

On 06/05/07 00:37, snowcrash+freebsd wrote:
> On 6/4/07, Volker <volker at vwsoft.com> wrote:
>> without seeing your pf.conf ruleset,
> 
> happy to send/post if required/helpful ...

I don't think it's required for now.

>> I guess you're using a ppp
>> connection to your upstream provider and firewalling on the tunX
>> interface (using tun0 as $ext_if).
> 
> you're absolutely correct here.
> 
>> As FreeBSD boots up, this interface does not yet exist when pf is
>> loaded.
> 
> clear.
> 
>> As soon as ppp is loaded and interface tun0 has been created,
>> pf will happily load your ruleset.
> 
> aha. does that suggest that i'm simply not waiting long enough?  your
> following comments suggest otherwise, iiuc, that i need to proactively
> _do_ something different ...

It's not _you_ aren't waiting too long. It's at the time pf is being
loaded, the interface pf want's to filter on does not yet exist. See
it as a wrong load order.

The only thing you could do is only using interfaces which do exist at
boot-up time. tun, ppp and ng interfaces are created a bit later (by
default). You could avoid using dynamic interfaces in your ruleset
(which is not always possible). For example you could filter on the
interface group 'pass out on tun from any to any port http keep state'
should happily be parsed and loaded at boot time, even while no tun
interface does exist. As soon as you're trying to get the IP address
of such interface (rdr rules most likely), pf will fail with a 'device
not configured' error message (or the like).

>> The solution is to either have pf rules loaded late (later than ppp is
>> started)
> 
> clearly, simply including pf-related items in rc.conf after
> pppoe-related items is not sufficient.
> 
> i'll take a look at "rcorder" ... which i wasn't aware of at all.  thanks!

The clearest solution is to have a pf ruleset without any dynamic
interfaces included but having anchors included to later fill the
rules as soon as the dynamic interfaces are created. As that is one
thing on my 2do list for a long time, I don't have any good examples
for that. The OpenBSD pf FAQ does contain a bit about this.

If you want to avoid using anchors, you can use a very quick and dirty
solution by just symlinking /etc/rc.d/pf to /usr/local/etc/rc.d. A bit
better (just a bit) is to create a new rc file in /usr/local/etc/rc.d
which may contain something like:

file: /usr/local/etc/rc.d/pf-late
#!/bin/sh
# PROVIDE: pf-late
# REQUIRE: NETWORKING DAEMON

/etc/rc.d/pf ${1}
#EOF

This script will run after all networking parts and all daemon
processes have been loaded and will load pf rules. Using that, pf
rules will be loaded twice: the first (regular) time will fail and the
2nd time will most likely succeed. Keep in mind this is just a quick
and dirty workaround.

> 
>> or use anchors and load ext rules into the anchor when the
>> ppp interface is up.
> 
> i hadn't thought of using anchors in this fashion.
> 
> i'm off to google, but any good examples you can reference?
> 
>> The easier is to have the rules loading late
>> (check using rcorder) but this may also fail if something goes wrong
>> with ppp.
> 
> i /thought/ i'd dealt with the intfc/ppo/pf ordering issue, configuring,
> 
> cat /etc/ppp/ppp.linkup
>     ------------------------------------
>     ppp1:
>         ! sh -c "/sbin/pfctl -ef /usr/local/etc/pf/pf.conf"

That might work but I would try to have it running in the background
(!bg) as while forking a foreground process, ppp will be blocked for
that time.

>         !bg sh -c "echo `/bin/date` `/etc/bin/ip` ppp.linkup >>
> /etc/ppp/log"
>     ------------------------------------
> 
> cat /etc/ppp/ppp.linkdown
>     ------------------------------------
>     ppp1:
>         !bg route delete HISADDR ppp1
>         !bg pfctl -F all -d
>     ------------------------------------
> 
> cat /etc/ppp/ppp.conf
>     ------------------------------------
>     default:
>         set device PPPoE:sis1:
>         set speed sync
>         set ctsrts off
>         set dial
>         set login
>         set cd 10
>         set timeout 0
>         set redial 0 0
>         enable lqr
>         set lqrperiod 20
>         set log Phase tun command
>     
>         add default HISADDR
>         enable tcpmssfixup
>         disable dns
>     
>     ppp1:
>         set authname me at myisp.com
>         set authkey  ############
>         set MRU 1492
>         set MTU 1492
>     ------------------------------------
> 
> are these NOT supposed to address/solve the problem? or are the configs
> wrong?

Other then the bg issue, I don't have an idea why your current config
does not work. You may check (just a guess) if pf does see that
interface at the time the linkup script is executed by inserting
`pfctl -sI' and check the output.

If running that (pf) script in the background does not solve your
problem, you may go the quick workaround by using a 'pf-late' script.
If you really want to have it clear and well designed (and can afford
the time on hacking and testing this), anchors are the way to go.
Within your ppp.linkup script you would then need to load the rules
into the anchors for the tun interface.

HTH

Volker