From owner-freebsd-isp@FreeBSD.ORG Fri Nov 14 01:22:50 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 6A05B16A4CE; Fri, 14 Nov 2003 01:22:50 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1F0B43FE5; Fri, 14 Nov 2003 01:22:47 -0800 (PST) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])hAE9M8UQ065683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2003 10:22:08 +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 hAE9M835051462; Fri, 14 Nov 2003 10:22:08 +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 KAA17257; Fri, 14 Nov 2003 10:22:06 +0100 (MET) Message-Id: <200311140922.KAA17257@galaxy.hbg.de.ao-srv.com> In-Reply-To: <20031113211620.GB25920@blossom.cjclark.org> from "Crist J. Clark" at "Nov 13, 2003 10:16:20 pm" To: cjc@freebsd.org Date: Fri, 14 Nov 2003 10:22:06 +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-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: Fri, 14 Nov 2003 09:22:50 -0000 Crist J. Clark: >On Thu, Nov 13, 2003 at 12:46:24PM -0500, Vincent Goupil wrote: >> I setup a firewall with ipfw2 and natd on freebsd 4.9 release. >> >> I have mapped my subnet with alias_address >> I have mapped 4 private ip address with 4 public ip address >> >> Everything is working fine (web, email, ftp, etc..) for outgoing and >> incoming connexion for anyone on my network. >> >> With this configuration, 5 person at a time (on my network) could dial to >> the same VPN server. >> 4 with different IP and the one with the alias_address. I supposed that >> only one person at a time can use the alias_address with the IPSec VPN (I >> think, tell me if I'm wrong) >[snip] > >Nope, that's right. You can have only one machine behind natd(8) using >ESP at a time (you could actually have one AH and one ESP at the same >time, but since NAT breaks AH, what's the point?). The reason within >natd(8) is that accept for a few protocols (TCP, UDP, ICMP, etc.), all >that it enters into its translation table is, > > IPproto: IPsrc_addr-IPdst_addr -> IPalias_addr-IPdst_addr > >The obvious problem is that you can only have one mapping like >this. If you had more than one, when you receive a packet of IPproto >from IPdst_addr, to which internal machine do you send it? > >Now, that's why natd(8) has problems. Why not add a feature to natd(8) >to get around it? Because there is no way to get around the >problem. 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. 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. In Cisco IOS speak: cisco(config)#crypto ipsec nat-transparency ? spi-matching Match inbound SPI to outbound SPI for IPsec aware NAT udp-encapsulation UDP encapsulation of IPsec protocols cisco(config)# The core issue is that FreeBSD does neither support SPI-based NAT, nor does it support UDP-encapsulated IPSec. Helge