From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 14:42:39 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93788106564A for ; Wed, 3 Sep 2008 14:42:39 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 50D708FC15 for ; Wed, 3 Sep 2008 14:42:39 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id EA41C42D83E; Wed, 3 Sep 2008 16:42:37 +0200 (CEST) Date: Wed, 3 Sep 2008 16:42:37 +0200 From: Guido van Rooij To: Jon Radel Message-ID: <20080903144237.GA28697@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BE9B74.90404@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections fails (?) 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: Wed, 03 Sep 2008 14:42:39 -0000 On Wed, Sep 03, 2008 at 10:13:08AM -0400, Jon Radel wrote: > > And why is that so? This bascially rules out keep state on outgouing packets > > on any router-type system. That seems like an unnecessary limitation. > > What? If you want state, turn it on: > > block all > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > should work fine also. Other things being equal (in other words, your > mileage may vary....), that is both more secure and more efficient than > the first rule set I offered as an example. I sent the first one only It's certianly not more efficient as one needs twice as many state entries. > because you insisted that your real rule set for 5 interfaces would not > allow you to maintain state on ep0 (or its equivalent). Suppose I want to limit traffic to 10.0.0.2 which is behind bge0. Then when solving this with keeping state on outgoing packets on bge0 means a single rule. With your suggestion, the amount of rules is five times as big because then I need to add keep state rules for incoming packets on the other interfaces as well. > > You still haven't given us any hints as to why the solution which > maintains state on all interfaces is impossible for you. Like with the ruleset you posted, a single keep state rule is sufficient. > > > > > I have not yet heart any reason why this is the case. pf was modelled > > after ipf, so I wonder why this change in state handling was introduced. > > This is probably the wrong list if you want to have people justify > design decisions. > I honestly don't think this was a design decison, but a bug in pf. Like I said, the state engine was modelled after ipf's (hack, the whole TCP-sepcifics came from a paper I wrote), which behaves exactly similar as pf, _except_ for this specific scenario. So it shure smells like a bug. Please try to undeerstand my question: the question is not: how do I work around a failing ruleset. The question is: why doesn't it work. -Guido