From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 5 04:56:22 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1DD737B401; Tue, 5 Aug 2003 04:56:22 -0700 (PDT) Received: from cocoa.syncrontech.com (cocoa-e0.syncrontech.com [62.71.8.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 062DE43F75; Tue, 5 Aug 2003 04:56:21 -0700 (PDT) (envelope-from ari.suutari@syncrontech.com) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19])h75BuEsV058199; Tue, 5 Aug 2003 14:56:14 +0300 (EEST) (envelope-from ari.suutari@syncrontech.com) Received: from coffee.syncrontech.com (coffee.syncrontech.com [62.71.8.37]) h75BuCk6093375; Tue, 5 Aug 2003 14:56:12 +0300 (EEST) (envelope-from ari.suutari@syncrontech.com) From: Ari Suutari Organization: Syncron Tech Oy To: Christian Kratzer , Christian Kratzer , Luigi Rizzo Date: Tue, 5 Aug 2003 14:56:11 +0300 User-Agent: KMail/1.5.2 References: <200307070113.h671DPeG082710@freefall.freebsd.org> <20030805034145.B49439@xorpc.icir.org> <20030805125910.Y22923@majakka.cksoft.de> In-Reply-To: <20030805125910.Y22923@majakka.cksoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308051456.11854.ari.suutari@syncrontech.com> X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) cc: Christian Kratzer cc: sam@FreeBSD.org cc: freebsd-ipfw@FreeBSD.org Subject: Re: kern/53624: patches for ipfw2 to support ipsec packet filtering X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2003 11:56:23 -0000 Hi, On Tuesday 05 August 2003 14:22, Christian Kratzer wrote: > > Case1 (this is working) > ----------------------- > This is working fine with Good. > Case2: > ------ > > The problem with this seemed to be that outgoing packets would pass through > the divert rules before having ipsec applied if originating from the local > host. Also returning packets did not alway get tagged early enough. > Since the packets pass through ipfw both encrypted and unencrypted, I think the flow is something like: outgoing packets: ipfw -> natd(does NAT) -> ipfw -> ipsec (encrypts) -> ipfw -> natd(DOES nothing) -> ipfw -> network incoming packets: network -> ipfw -> natd(does nothing) -> ipfw -> ipsec(decrypts) -> ipfw -> natd(does NAT) -> ipfw -> to rest of network stack This is how I *think* it works. I'm not very, very sure. I have one test box running which does nat before ipsec tunnel and it works correctly. Ari S.