From owner-freebsd-pf@FreeBSD.ORG Tue Jun 5 20:43:13 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 CAF6E16A421 for ; Tue, 5 Jun 2007 20:43:13 +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 6CA1F13C484 for ; Tue, 5 Jun 2007 20:43:13 +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 BEA8812881E; Tue, 5 Jun 2007 22:43:05 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 537443F9E5; Tue, 5 Jun 2007 22:42:14 +0200 (CEST) Message-ID: <4665CAAA.6040506@vwsoft.com> Date: Tue, 05 Jun 2007 22:42:18 +0200 From: Volker User-Agent: Thunderbird 2.0.0.0 (X11/20070528) MIME-Version: 1.0 To: David DeSimone References: <70f41ba20706041403q1d51ac75jee625130ea4ed10@mail.gmail.com> <46648172.3060307@vwsoft.com> <20070605202918.GA14693@verio.net> In-Reply-To: <20070605202918.GA14693@verio.net> 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: freebsd-pf@freebsd.org 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:43:13 -0000 On 06/05/07 22:29, David DeSimone wrote: > Volker wrote: >> without seeing your pf.conf ruleset, I guess you're using a ppp >> connection to your upstream provider and firewalling on the tunX >> interface (using tun0 as $ext_if). > >> As FreeBSD boots up, this interface does not yet exist when pf is >> loaded. As soon as ppp is loaded and interface tun0 has been created, >> pf will happily load your ruleset. > > My understanding of PF is that it will happily load a configuration that > contains references to nonexistent interfaces, and when those interface > come around to existing later, it will happily enforce the policy > applied to them. That is to say, I can't find any evidence that an > interface that doesn't exist causes policy loading to fail. > > To test this, I added a couple of lines to my existing policy: > > pass out quick on gpx0 all > > pass in on asdfiawe934 from 1.2.3.4 to 4.3.2.1 > > PF did not complain one bit about these nonsensical interface names, and > "pfctl -sr" verifies that they do indeed remain in force, even though > they have no chance of matching anything. > David, most likely (also look at my statement on using rules which require the interface's IP address) you've got something like: pass in on bla0 from any to bla0 or rdr on bla0 from any to bla0 port whichever -> $nowhere or nat on bla0 from any to any -> bla0 or nat on bla0 from !bla0 to any -> bla0 which will all require pf to get the interface's IP address and all will fail if that interface does not yet exist (all samples from memory and not checked for syntactical correctness). These samples are real world samples and will fail in the first place when being used on dynamic interfaces. The following has nothing to do with pf refusing to load rules, but is an important thing to note: The case becomes more worst if the interface DOES exist but still has no IP address (read this as a big fat warning). When using a rule like pass in on bla0 from any to bla0 but the interface bla0 does not have an IP address, pf will parse this as 'pass in on bla0 from 0.0.0.0/0 to 0.0.0.0/0' which will render your firewall easily wide open and useless. I've posted this a few months ago but never get any reply. Such a mistake is easily been done when using PPPoE as most (physical) PPPoE interfaces don't have an IP address (as it doesn't require one for proper PPPoE operation). HTH Volker