From owner-freebsd-isp@FreeBSD.ORG Tue Nov 18 14:40:32 2003 Return-Path: Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F48B16A4CE; Tue, 18 Nov 2003 14:40:32 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B04243FEA; Tue, 18 Nov 2003 14:40:28 -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 (rwcrmhc13) with ESMTP id <2003111822402701500ovt06e>; Tue, 18 Nov 2003 22:40:27 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id hAIMeksb010901; Tue, 18 Nov 2003 14:40:46 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id hAIMeiC5010900; Tue, 18 Nov 2003 14:40:44 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 18 Nov 2003 14:40:44 -0800 From: "Crist J. Clark" To: Helge Oldach Message-ID: <20031118224044.GA10828@blossom.cjclark.org> References: <20031115182409.GA2001@blossom.cjclark.org> <200311161911.UAA25957@galaxy.hbg.de.ao-srv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311161911.UAA25957@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-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2003 22:40:32 -0000 On Sun, Nov 16, 2003 at 08:11:36PM +0100, Helge Oldach wrote: > Crist J. Clark: > >On Sat, Nov 15, 2003 at 07:54:40AM +0100, Oldach, Helge wrote: > >> From: Crist J. Clark [mailto:cristjc@comcast.net] > >> > 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. > >> You have posted a reference already. W2k SP4 supports UDP > >> encapsulation of IPSec. And yes, it works fine, and reliably. > >> Further, all of Cisco's and Checkpoints VPN gear support > >> IPSec-over-UDP as well. This alone is >70% market share. > >Oh, yeah, I know of UDP or TCP encapsulation tricks that work. I have > >dealt with several of these implementations too. I thought that you > >were implying that there were working NAT implementations that could > >deal with ESP in these circumstances. > > Apologies... I am actually jumping between loosely related topics > somewhat. > > In fact both Cisco and Checkpoint also support many-to-one NAT for ESP > and AH protocols. One can indeed have multiple internal VPN devices > hidden behind a single public address, and talking to the same outside > VPN gateway - without requiring that the VPN devices themselves to > tricks to work around NAT (such as UDP encapsulation). You can't use AH with NAT. (period) The whole point of AH is to detect someone tampering with the packet. NAT tampers with the packet. If you can do NAT, AH is broken. As for ESP, Cisco uses a trick. Their implementation, 'spi-matching,' ...is available only for endpoints that choose SPIs according to the predictive algorithm implemented in Cisco IOS Release 12.2(15)T. I am not aware of this algorithm being published anywhere. If it is freely distributed, we could add that support if there was a call for it. As for Checkpoint, I couldn't find any documentation of this ability and from my experience using NG FP2, this doesn't work. It did not NAT ESP at all, not even for one client behind NAT. If this is a new feature in AI or if there is a hidden knob to activate it, I would appreciate a pointer. > To add, there are all sorts of other drafts that amend IPSec > functionality (such as XAUTH and Mode Config which are also pretty > widely deployed in VPN remote access scenarios) that are missing. That's IKE which is really a whole separate beast. The open source IKE daemons are definately not chock full of bleeding edge or vendor-specific features. And the racoon documentation... But all of these IKE extensions are only useful if the vendors using them publish what they are actually doing with them. Reverse engineering this stuff can be really painful since you can't see the data on the wire. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org