Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Dec 2001 19:29:27 +0200
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Dingo <dingo@microbsd.net>
Cc:        guido@FreeBSD.org, net@FreeBSD.org
Subject:   IPSEC and IPNAT (was: Re: IPSec)
Message-ID:  <20011206192927.A14515@sunbay.com>
In-Reply-To: <1007659326.24679.11.camel@devel.netwolves.com>
References:  <1007658158.24679.5.camel@devel.netwolves.com> <20011206181039.A12412@sunbay.com> <1007659326.24679.11.camel@devel.netwolves.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.  :-)

> On Thu, 2001-12-06 at 11:10, Ruslan Ermilov wrote:
> > On Thu, Dec 06, 2001 at 10:02:38PM +0500, Dingo wrote:
> > > can you enlighten me a bit, GIF devices are the only way I know how to
> > > do tunnel mode IPSec along with NAT
> > > 
> > What kind of NAT?  What would you like to NAT: payload or armour?
> > ipnat(1) or natd(8)?  How, in your opinion, gif(4) devices help
> > NAT?
> > 
> > We're runnign an (over Inet) distributed VPN using IPSEC without
> > any gif(s), and with NAT (using natd(8)).
> > 
> > ISTR some problems in the past, where IPSEC intercepted packets
> > (in ip_output()) before they were passed to "ipfw" and/or "ipf",
> > but the order was fixed a later day.

-- 
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?20011206192927.A14515>