impossible rc.d ordering problem with stf and pf ?

[Richard Coleman]

Max Laier wrote:
> 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 :-\

I remember trying a dynamic interface for tun before, and it failed.  But I now see that it was 
because I also use "set logininterface".  I didn't think to remove that.  Thanks for the help.  I'll 
give it a try.

Richard Coleman
rcoleman at criticalmagic.com