From owner-freebsd-isp@FreeBSD.ORG Fri Nov 21 22:36:45 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 319E416A4CF for ; Fri, 21 Nov 2003 22:36:45 -0800 (PST) Received: from dino.dnsalias.com (h24-80-253-172.vc.shawcable.net [24.80.253.172]) by mx1.FreeBSD.org (Postfix) with SMTP id DA67B43FDD for ; Fri, 21 Nov 2003 22:36:41 -0800 (PST) (envelope-from stephen@dino.dnsalias.com) Received: (qmail 31014 invoked from network); 22 Nov 2003 06:36:40 -0000 Received: from unknown (HELO anakin.) (192.168.2.4) by dino.dnsalias.com with SMTP; 22 Nov 2003 06:36:40 -0000 Received: (from stephen@localhost) by anakin. (8.11.6/8.11.6) id hAM6ZsK30178; Fri, 21 Nov 2003 22:35:54 -0800 From: "Stephen J. Bevan" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16319.970.22297.204715@anakin.> Date: Fri, 21 Nov 2003 22:35:54 -0800 To: cjclark@alum.mit.edu In-Reply-To: <20031114201246.GA62521@blossom.cjclark.org> References: <20031114163654.GB61960@blossom.cjclark.org> <200311141722.SAA19138@galaxy.hbg.de.ao-srv.com> <20031114201246.GA62521@blossom.cjclark.org> X-Mailer: VM 7.07 under Emacs 21.2.1 cc: freebsd-isp@freebsd.org cc: freebsd-ipfw@freebsd.org cc: Helge Oldach cc: vgoupil@alis.com cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_address) X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2003 06:36:45 -0000 Crist J. Clark writes: > 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. A cheat is to use the sequence number in the ESP header to matchup the SPI on the inbound packet with the SPI on the outbound packet. This only works if the NAT box doesn't have multiple ESP connections all starting at the same time (otherwise there would obviously be no way to tell which outbound SPI a packet with ESP sequence number 1 should match). A workaround for that is to have the NAT box delay the IKE negotiation for one connection if another one has not completed and resulted in traffic being sent. It all has a bit of a bad smell to it but then NAT isn't exactly sweet smelling either.