From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 09:23:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA5216A4CE; Fri, 14 Nov 2003 09:23:47 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0298743FE5; Fri, 14 Nov 2003 09:23:46 -0800 (PST) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])hAEHN3UQ089189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2003 18:23:03 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4])ESMTP id hAEHN335075842; Fri, 14 Nov 2003 18:23:03 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id SAA19138; Fri, 14 Nov 2003 18:22:55 +0100 (MET) Message-Id: <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> In-Reply-To: <20031114163654.GB61960@blossom.cjclark.org> from "Crist J. Clark" at "Nov 14, 2003 5:36:54 pm" To: cjclark@alum.mit.edu Date: Fri, 14 Nov 2003 18:22:55 +0100 (MET) From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782517 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 17:23:48 -0000 Crist J. Clark: >> >ESP packets have this nice SPI field that one could >> >potentially use to map the traffic between multiple machines behind >> >NAT to a single VPN end point on the other side, but there is no >> >practical way for the NAT box to learn the SPI of incoming packets. >> Certainly there is. > >Nope, there isn't a general way to do it. Agreed, there is no *general* trick. But the hacks I have described work very well in many business environments. >> 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. >> 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. >> 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. >> nor >> does it support UDP-encapsulated IPSec. > >I'll post some instructions on how to do this (not compliant with the >draft below). But that still is not a panecea, Thank you, this is very interesting. >NAT is evil. Of course. But it's also a fact of life... Helge