From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 14 12:12:34 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E79516A4CE; Fri, 14 Nov 2003 12:12:34 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43A544017; Fri, 14 Nov 2003 12:12:31 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (sccrmhc12) with ESMTP id <2003111420123001200s535ue>; Fri, 14 Nov 2003 20:12:30 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hAEKCmsb062924; Fri, 14 Nov 2003 12:12:48 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hAEKCkrn062923; Fri, 14 Nov 2003 12:12:46 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 14 Nov 2003 12:12:46 -0800 From: "Crist J. Clark" To: Helge Oldach Message-ID: <20031114201246.GA62521@blossom.cjclark.org> References: <20031114163654.GB61960@blossom.cjclark.org> <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 20:12:34 -0000 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