From owner-freebsd-net Thu Dec 6 11:13:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by hub.freebsd.org (Postfix) with ESMTP id 69D8737B405; Thu, 6 Dec 2001 11:13:35 -0800 (PST) Received: by gvr.gvr.org (Postfix, from userid 657) id 61FAD5809; Thu, 6 Dec 2001 20:13:33 +0100 (CET) Date: Thu, 6 Dec 2001 20:13:33 +0100 From: Guido van Rooij To: Ruslan Ermilov Cc: Dingo , net@FreeBSD.org Subject: Re: IPSEC and IPNAT (was: Re: IPSec) Message-ID: <20011206201333.A86441@gvr.gvr.org> References: <1007658158.24679.5.camel@devel.netwolves.com> <20011206181039.A12412@sunbay.com> <1007659326.24679.11.camel@devel.netwolves.com> <20011206192927.A14515@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011206192927.A14515@sunbay.com>; from ru@FreeBSD.org on Thu, Dec 06, 2001 at 07:29:27PM +0200 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 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. 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. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message