Date: Fri, 7 Dec 2001 10:01:20 +0200 From: Ruslan Ermilov <ru@FreeBSD.org> To: Guido van Rooij <guido@gvr.org> Cc: Dingo <dingo@microbsd.net>, net@FreeBSD.org Subject: Re: IPSEC and IPNAT (was: Re: IPSec) Message-ID: <20011207100120.E13705@sunbay.com> In-Reply-To: <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> <20011206201333.A86441@gvr.gvr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <out ifname> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011207100120.E13705>