From owner-freebsd-current@FreeBSD.ORG Fri Jun 26 05:53:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20220106564A for ; Fri, 26 Jun 2009 05:53:34 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id A4D308FC1C for ; Fri, 26 Jun 2009 05:53:33 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.145.103.163] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MK4NP-0005xL-11; Fri, 26 Jun 2009 07:53:31 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK4NN-000GGr-5f; Fri, 26 Jun 2009 07:53:29 +0200 To: Doug Barton From: Ian FREISLICH In-Reply-To: <4A444BC2.4010606@FreeBSD.org> References: <4A444BC2.4010606@FreeBSD.org> X-Attribution: BOFH Date: Fri, 26 Jun 2009 07:53:29 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: pfsync rc script breaks pfsync on cloned interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 05:53:34 -0000 Doug Barton wrote: > I have reverted the change that caused pf and ipfw to appear before > netif in the rcorder. While I still feel strongly that it is the > "right thing" to configure the firewalls first, the changes caused too > many problems for too many users, and it's too late in the release > cycle to make a change like this that has significant side effects. Then, what is required is the creation of (cloned) interfaces to be seperated from assigning them addresses. But even that is insufficient because pf.conf allows "interface:network" etc wich expands to the networks on an interface. Unlike ipfw which walks the ifnet structure to compare addresses, if at the time of firewall configuration, the interface has no address, then the rule will expand to have no address. > ipfw it's not quite as urgent since by default it does not pass > packets till it is configured. This is not the case with pf, as its > default is wide open until it is configured. I put it to you that users of pf know that it starts with default allow and changing this will result in a POLA violation. Ian -- Ian Freislich