Date: Fri, 14 Nov 2003 08:36:54 -0800 From: "Crist J. Clark" <cristjc@comcast.net> To: Helge Oldach <helge.oldach@atosorigin.com> Cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess) Message-ID: <20031114163654.GB61960@blossom.cjclark.org> In-Reply-To: <200311140922.KAA17257@galaxy.hbg.de.ao-srv.com> References: <20031113211620.GB25920@blossom.cjclark.org> <200311140922.KAA17257@galaxy.hbg.de.ao-srv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 14, 2003 at 10:22:06AM +0100, Helge Oldach wrote: > 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. Nope, there isn't a general way to do it. > 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. > 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. There are heuristics a NAT device could use to guess (when a new SPI shows up at the doorstep, it's to the host that most recently had some IKE activity), but it's just that, a guess. (And if two systems start up or rekey at the same time, you're hosed when guessing by key traffic. Worse yet, there is no requirement to use IKE to setup IPsec SAs, so then what's a NAT box to do?) > 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. > 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, http://ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-06.txt http://ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt NAT is evil. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031114163654.GB61960>