From owner-freebsd-stable@FreeBSD.ORG Sun Jan 28 17:37:17 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 416C016A401; Sun, 28 Jan 2007 17:37:17 +0000 (UTC) (envelope-from rcoleman@criticalmagic.com) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [64.74.207.196]) by mx1.freebsd.org (Postfix) with ESMTP id 04D4413C4AC; Sun, 28 Jan 2007 17:37:17 +0000 (UTC) (envelope-from rcoleman@criticalmagic.com) Received: from neptune.criticalmagic.com (adsl-074-229-078-253.sip.asm.bellsouth.net [74.229.78.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "neptune.criticalmagic.com", Issuer "Critical Magic Root Certificate" (verified OK)) by saturn.criticalmagic.com (Postfix) with ESMTP id 72C9C39808; Sun, 28 Jan 2007 12:37:16 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by neptune.criticalmagic.com (Postfix) with ESMTP id B52BE6D409; Sun, 28 Jan 2007 12:37:15 -0500 (EST) Message-ID: <45BCDF4B.5050002@criticalmagic.com> Date: Sun, 28 Jan 2007 12:37:15 -0500 From: Richard Coleman Organization: Critical Magic User-Agent: Thunderbird 1.5.0.9 (X11/20061222) MIME-Version: 1.0 To: Max Laier References: <45BC97E2.4050603@FreeBSD.org> <45BCC255.3010101@criticalmagic.com> <200701281815.37558.max@love2party.net> In-Reply-To: <200701281815.37558.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bruce M. Simpson" , freebsd-stable@freebsd.org, Pete French Subject: Re: impossible rc.d ordering problem with stf and pf ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2007 17:37:17 -0000 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@criticalmagic.com