impossible rc.d ordering problem with stf and pf ?

[Max Laier]

On Sunday 28 January 2007 16:33, Richard Coleman wrote:
> Bruce M. Simpson wrote:
> > Pete French wrote:
> >> Am trying to solve a little problem with 'pf'. I have a ruleset
> >> which has some firewall rules for the IPv6 interface stf0. This
> >> works fine, except when I rreboot the machine, as the pf script is
> >> run before the network_ipv6 script - so stf0 does not exist. but I
> >> cannot work out how to arrange for stf0 to be created before the pf
> >> script is run - as network_ipv6 requires 'routing', but the pf
> >> script says it must be run before 'routing', if I am reading the
> >> 'REQUIRE' and 'BEFORE' lines correctly.
> >
> > Just chiming in to confirm that this problem definitely exists.
> > I don't have a solution, however, my IPv6 tunnels at home have all
> > expired, so I may well get spare cycles to look at this the same time
> > that I get spare cycles to revive the tunnels.
> >
> > BMS
>
> Essentially the same problem exists with pf and ppp.  The tun device
> (on which most of my pf rules depend) does not yet exist when pf is
> started.
>
> Apparently, someone has looked at this before, since there are commands
> to resync pf and ipf inside the rc.d script for ppp (in ppp_postcmd). 
> But this still doesn't work, since ppp is still negotiating the
> connection when this function is run, so pf fails a second time.  My
> solution was to jam a "sleep 15" inside ppp_postcmd() right before the
> point the commands to reload pf and ipf are run.  It's major ugly, but
> it works.  Hopefully someone will find a better solution to these
> problems.

In oder to solve these problems you have to understand why pf is failing.  
This can be for three reasons:

1) You use the interface name as address w/o dynamic lookup.  i.e. "... 
from stf0 ..."
2) You use "set loginterface sft0"
3) You use the interface with ALTQ "altq on stf0 ..." (now this doesn't 
work and wouldn't be a good idea either, but for tun0 it makes slightly 
more sense).

To 1 and 2 there is a simple sollution: Don't do that then!  1 can easily 
be defused by adding parentheses. i.e. "... from (stf0) ...".  If more 
control is required you have to write explicit addresses in your 
configuration anyway.  2 is obsolete by "pfctl -vvsI -i stf0" which has 
all the counters for all the interfaces.  ALTQ is the only remaining 
problem.  I did do some initial patches to tear down altq on interface 
removal, which could be extended to work the other way 'round on 
interface arrival - if only I had more time :-\

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070128/6f90f604/attachment.pgp