From owner-freebsd-pf@FreeBSD.ORG Tue Jun 5 20:00:04 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80D4B16A421; Tue, 5 Jun 2007 20:00:04 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB2013C447; Tue, 5 Jun 2007 20:00:03 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7dbe.q.ppp-pool.de [89.53.125.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 3746A12881E; Tue, 5 Jun 2007 21:59:57 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id B030B3F9E5; Tue, 5 Jun 2007 21:59:08 +0200 (CEST) Message-ID: <4665C091.90808@vwsoft.com> Date: Tue, 05 Jun 2007 21:59:13 +0200 From: Volker User-Agent: Thunderbird 2.0.0.0 (X11/20070528) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <70f41ba20706041403q1d51ac75jee625130ea4ed10@mail.gmail.com> <46648172.3060307@vwsoft.com> <70f41ba20706041537laba6223v8c879e344d799052@mail.gmail.com> In-Reply-To: <70f41ba20706041537laba6223v8c879e344d799052@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: mikhailg@webanoide.org, freebsd-pf Subject: Re: fbsd 6.2 pf starts -- but not on boot X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2007 20:00:04 -0000 Hi snow, On 06/05/07 00:37, snowcrash+freebsd wrote: > On 6/4/07, Volker 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@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