From owner-freebsd-security@FreeBSD.ORG Wed Jun 4 08:54:52 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 780DE37B401 for ; Wed, 4 Jun 2003 08:54:52 -0700 (PDT) Received: from irpen.kiev.ua (irpen.kiev.ua [195.178.133.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A17A43F3F for ; Wed, 4 Jun 2003 08:54:50 -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 h54Fr4rt034799; Wed, 4 Jun 2003 18:54:25 +0300 (EEST) (envelope-from duke@irpen.kiev.ua) Received: (from duke@localhost) by irpen.kiev.ua (8.12.8p1/8.12.8/Submit) id h54FqxOD034792; Wed, 4 Jun 2003 18:52:59 +0300 (EEST) (envelope-from duke) Date: Wed, 4 Jun 2003 18:52:59 +0300 From: Vandyuk Eugene To: freebsd-security@freebsd.org Message-ID: <20030604185259.E29212@irpen.kiev.ua> References: <20030602174758.3f85db72.vladg@vipnet.ro> <20030602200857.T6733-100000@cactus.fi.uba.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030602200857.T6733-100000@cactus.fi.uba.ar>; from fgleiser@cactus.fi.uba.ar on Mon, Jun 02, 2003 at 08:11:40PM -0300 Subject: Statefull filtering with IPFW + IPFilter (was: Packet flow through IPFW+IPF+IPNAT) 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: Wed, 04 Jun 2003 15:54:52 -0000 On Mon, Jun 02, 2003 at 08:11:40PM -0300, Fernando Gleiser wrote: > On Mon, 2 Jun 2003, Vlad GALU wrote: > > > Example one: IPF is compiled in kernel, IPFW is a module. In this case > > IPFW stands 'outside' of IPF. > > Example two: viceversa: the order in which they take action is reversed > > too. > > Are you sure? Last time I saw the code (almost a year ago) it didn't > make a difference if they were loaded as modules or compiled in kernel. > The hooks were in the same place. > > > IPNAT is always 'outside' IPF. > > Or, in other words, IPF always 'sees' the real IPs, not the NATed ones. > I have done some tests with IPFW and IPF compiled in kernel and I was confused. Packet flow was: OUTGOING: IPF -> IPNAT -> IPFW INCOMING: IPNAT -> IPF -> IPFW As the result - both outgoing/incoming packets are NAT'ed _before_ IPFW ?! Rules matching in IPFW look very strange: add count ip from NAT_IP to any out add count ip from any to REAL_IP in but in IPFilter it looks good: permit out from REAL_IP to any permit in from any to REAL_IP So I sugest that in kernel with IPFW+IPF compiled statefull filtering not work in IPFW but only work in IPFilter ??? I think it's wrong and it should be corrected in this way: OUTGOING: IPF -> IPNAT -> IPFW INCOMING: IPFW -> IPNAT -> IPF This flow of packets will give IPFW work with right statefull filtering on NAT'ed packets via IPNAT. IPFW would always be 'outside' IPNAT. Also this way will give more capabilities for building firewalls with all power and flexibility of IPFW and IPFilter in one kernel. With respect. Eugene.