IPSec VPN & NATD (problem with alias_address vs redirect_addr ess)

[Crist J. Clark]

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 at alum.mit.edu
                                   |     cjclark at jhu.edu
http://people.freebsd.org/~cjc/    |     cjc at freebsd.org