Date: Thu, 6 Dec 2001 20:13:33 +0100 From: Guido van Rooij <guido@gvr.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: Dingo <dingo@microbsd.net>, net@FreeBSD.org Subject: Re: IPSEC and IPNAT (was: Re: IPSec) Message-ID: <20011206201333.A86441@gvr.gvr.org> In-Reply-To: <20011206192927.A14515@sunbay.com>; from ru@FreeBSD.org on Thu, Dec 06, 2001 at 07:29:27PM %2B0200 References: <1007658158.24679.5.camel@devel.netwolves.com> <20011206181039.A12412@sunbay.com> <1007659326.24679.11.camel@devel.netwolves.com> <20011206192927.A14515@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011206201333.A86441>