From owner-freebsd-net Fri Dec 7 0: 2:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 9EFC737B41D for ; Fri, 7 Dec 2001 00:02:06 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fB781KS15548; Fri, 7 Dec 2001 10:01:20 +0200 (EET) (envelope-from ru) Date: Fri, 7 Dec 2001 10:01:20 +0200 From: Ruslan Ermilov To: Guido van Rooij Cc: Dingo , net@FreeBSD.org Subject: Re: IPSEC and IPNAT (was: Re: IPSec) Message-ID: <20011207100120.E13705@sunbay.com> References: <1007658158.24679.5.camel@devel.netwolves.com> <20011206181039.A12412@sunbay.com> <1007659326.24679.11.camel@devel.netwolves.com> <20011206192927.A14515@sunbay.com> <20011206201333.A86441@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011206201333.A86441@gvr.gvr.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 06, 2001 at 08:13:33PM +0100, Guido van Rooij wrote: > On Thu, Dec 06, 2001 at 07:29:27PM +0200, Ruslan Ermilov wrote: > > On Thu, Dec 06, 2001 at 10:22:05PM +0500, Dingo wrote: > > > ipfilters ipnat.... We ran into the IPSec intercept problem with 4.3, > > > can you tell me when the changes were MFCd ? it might just be a matter > > > of updateing Ipfilter on this specific server. its a 4.3 RELEASE box. > > > But If I am correct, your telling me i can create a standard VPN, in > > > tunnel or transport mode, with ipfs ipnat, no gif devices ?? like > > > > > > 10.0.xxx.xxx -> ipnat -> 4.23.122.100 -> IPSEC TUNNEL <- 4.22.121.101 <- > > > ipnat <- 10.20.xxx.xxx > > > > > [What's missing in this picture is how ipnat modifies the 10.0 -> > > 10.20 packets. I will assume it hides the 10.0.xxx.xxx addresses > > after a single 4.23.122.100.] > > > > I'm not fluent in IPFilter (and IPNAT in particular), but I think > > there may be some difference between how IPNAT and IPDIVERT work. > > With IPDIVERT, a packet is first passed to a userland process, > > natd(8) in a similar scenario, and natd(8) writes the modified > > packet back to kernel which then passes this new packet back to > > ip_output(). ip_output() is organized so that IPSEC hooks are > > called before IPDIVERT and IPNAT hooks, but with IPDIVERT it's > > no problem, since the new packet is passed again to ip_output(), > > and if you tell your IPSEC to tunnel between 4.23.122.100 and > > 4.22.121.101, IPSEC will intercept that NATed packet. > > > > If IPNAT doesn't do the same, i.e., if it doesn't consider the > > NATed packet a "new" packet, and just continues with the modified > > packet, we have a trouble -- we have no way to IPSEC modified > > packet. Let IPFilter gurus speak up. :-) > > When you NAT, outgoing packets on the 4.23.122.100 interface > get their source address modified if you have a rule like: > map 10.0.0.0/16 -> 4.23.122.100 > This happens at the end of ip_output after ipsec processing. > Return packets will have their destination address changed at > the moment thye come in, before ip_input (and ipsec) processing. > So we definitely have a problem here. IPNAT processes outgoing packet only once (just modifies its source address), i.e., it's not passed again to ip_output() processing but rather IPFILTER just forwards the modified packet using routing decision. > The packets are already encrypted by then, so no NAT will take > place. On the other hand: NAT seems unnecessary since packets are > in a tunnel anyway, so the 10 addresses will never show up. > FreeBSD: tools, not policy. :-) I can easily imagine a situation where NAT before IPSEC would be useful, though I must admit I have never used this combo, in that order. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message