Date: Fri, 14 Nov 2003 12:12:46 -0800 From: "Crist J. Clark" <cristjc@comcast.net> To: Helge Oldach <helge.oldach@atosorigin.com> Cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) Message-ID: <20031114201246.GA62521@blossom.cjclark.org> In-Reply-To: <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> References: <20031114163654.GB61960@blossom.cjclark.org> <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 14, 2003 at 06:22:55PM +0100, Helge Oldach wrote:
> Crist J. Clark:
[snip]
> >> This is actually implemented in most modern VPN
> >> devices. They do NAT translation according to SPI. The alternative is to
> >> encapsulate IPSec traffic in UDP (using port 4500) packets which can be
> >> neatly NATted.
> >
> >It's not actually very neat. Most vendor kludges to do this are not
> >interoperable. The IETF draft for it isn't widely implemented AFAIK.
>
> As I said, must modern VPN devices have it. As a minimum, virtually any
> el-cheapo DSL router supports ESP-NAT for a single device (assuming that
> all SPIs belong to a single internal address). But many also support
> SPI-aware NAT.
FreeBSD natd(8) will work fine for a single VPN end point behind a
many-to-one mapping. In fact, it will work fine for arbitrarily many
VPN end points behind NAT as long as each one has a unique address at
the other end.
> >> In Cisco IOS speak:
> >>
> >> cisco(config)#crypto ipsec nat-transparency ?
> >> spi-matching Match inbound SPI to outbound SPI for IPsec aware NAT
> >
> >Not sure what that is going to accomplish. The inbound SPI and
> >outbound SPI are, in general, completely indpendent values. The whole
> >problem is that there is no way to know what the incoming (from the
> >external VPN end point to the one behind the NAT device) SPI is going
> >to be.
>
> Correct. Cisco requires that you use IKE in order to make it work.
> Basically this is NAT for ESP, and the SPI-NAT table is being built up
> using IKE cookie matching. There is no heuristics involved.
The IKE cookies, the IKE-SPI, do not have anything to do with IPsec
protocol SPIs. The cookies can be used to perform NAT tricks with IKE
traffic, but not IPsec (unless there are proprietary vendor kludges to
make the IPsec SPIs derivatives of the IKE-SPI).
> >> udp-encapsulation UDP encapsulation of IPsec protocols
> >> cisco(config)#
> >>
> >> The core issue is that FreeBSD does neither support SPI-based NAT,
> >
> >'Cause unless you have a hacked up IPsec implementation that uses the
> >same SPI both directions, it is useless.
>
> Nothing that works well and has noticeable exposure is useless. This
> definitely has both. Not with FreeBSD, though. It does work with Windows
> 2000 SP4, to put a name up... So it's definitely out there.
Two different ESP end points behind many-to-one NAT connected to a
single ESP end point on the other side of the NAT? I'd be very curious
to get the documentation on how they are cheating to get that to work.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031114201246.GA62521>