From owner-freebsd-security@FreeBSD.ORG Fri Jun 6 02:44:35 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90A2837B401 for ; Fri, 6 Jun 2003 02:44:35 -0700 (PDT) Received: from irpen.kiev.ua (irpen.kiev.ua [195.178.133.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 596C343FA3 for ; Fri, 6 Jun 2003 02:44:33 -0700 (PDT) (envelope-from duke@irpen.kiev.ua) Received: from irpen.kiev.ua (localhost.irpen.kiev.ua [127.0.0.1]) by irpen.kiev.ua (8.12.8p1/8.12.8) with ESMTP id h569iJrt034502; Fri, 6 Jun 2003 12:44:20 +0300 (EEST) (envelope-from duke@irpen.kiev.ua) Received: (from duke@localhost) by irpen.kiev.ua (8.12.8p1/8.12.8/Submit) id h569iIYa034501; Fri, 6 Jun 2003 12:44:18 +0300 (EEST) (envelope-from duke) Date: Fri, 6 Jun 2003 12:44:18 +0300 From: Vandyuk Eugene To: freebsd-security@freebsd.org Message-ID: <20030606124418.A33769@irpen.kiev.ua> References: <20030604133021.H24576-100000@cactus.fi.uba.ar> <200306050339.h553dPUJ002919@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200306050339.h553dPUJ002919@caligula.anu.edu.au>; from avalon@caligula.anu.edu.au on Thu, Jun 05, 2003 at 01:39:25PM +1000 cc: Darren Reed Subject: Re: Statefull filtering with IPFW + IPFilter (was: Packet flow X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2003 09:44:35 -0000 On Thu, Jun 05, 2003 at 01:39:25PM +1000, Darren Reed wrote: > In some mail from Fernando Gleiser, sie said: > > > > > OUTGOING: IPF -> IPNAT -> IPFW > > > INCOMING: IPFW -> IPNAT -> IPF > > > > There was some discusion some time ago in ipf's mailing list. I don't remember > > Darren's position on this. > > My perspective is that it best serves IPFilter for it to be like that. > > I'm not sure why it isn't, except to say that it's entirely possible that > I have applied a patch incorrectly. > > Darren But it's no so hard to move IpHack section in ip_input.c to call after IPFW proxessing? In this way we can keep all of the functionality all of IPFW, IPFilter and IPNAT. Because now people who want to use IPNAT with his kernel processing (versus NATd with userland processing) forced to use IPFilter and fully rebuild their firewall. It's some trouble with this changes in ip_input.c processing ?