From owner-freebsd-stable@FreeBSD.ORG Sun Jan 28 17:15:44 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 B234A16A40F; Sun, 28 Jan 2007 17:15:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA4613C441; Sun, 28 Jan 2007 17:15:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.19.181] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HBDcx1pVT-0007U2; Sun, 28 Jan 2007 18:15:41 +0100 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Sun, 28 Jan 2007 18:15:29 +0100 User-Agent: KMail/1.9.5 References: <45BC97E2.4050603@FreeBSD.org> <45BCC255.3010101@criticalmagic.com> In-Reply-To: <45BCC255.3010101@criticalmagic.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11143865.XLAq8e6vHb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701281815.37558.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX19BoxFQLJ9qN6oC5Pn39lPqgs6G98eIg32uJ04Vs508fF/Y9tomXV5A4BBVcORfKfYi/HZSgrYNMboxKVvZ2gnOuJYjkcWQCH7Tu7nMsnyHUg== Cc: "Bruce M. Simpson" , Richard Coleman , 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:15:44 -0000 --nextPart11143865.XLAq8e6vHb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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).=20 > 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. = =20 This can be for three reasons: 1) You use the interface name as address w/o dynamic lookup. i.e. "...=20 from stf0 ..." 2) You use "set loginterface sft0" 3) You use the interface with ALTQ "altq on stf0 ..." (now this doesn't=20 work and wouldn't be a good idea either, but for tun0 it makes slightly=20 more sense). To 1 and 2 there is a simple sollution: Don't do that then! 1 can easily=20 be defused by adding parentheses. i.e. "... from (stf0) ...". If more=20 control is required you have to write explicit addresses in your=20 configuration anyway. 2 is obsolete by "pfctl -vvsI -i stf0" which has=20 all the counters for all the interfaces. ALTQ is the only remaining=20 problem. I did do some initial patches to tear down altq on interface=20 removal, which could be extended to work the other way 'round on=20 interface arrival - if only I had more time :-\ =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart11143865.XLAq8e6vHb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD4DBQBFvNo5XyyEoT62BG0RAiknAJiRBFDrRC60fANBPJ5pxnB4eVqkAJ9CjONi F81YKM6R5ObNEWDI649JJw== =5+o7 -----END PGP SIGNATURE----- --nextPart11143865.XLAq8e6vHb--