Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Nov 2003 10:22:06 +0100 (MET)
From:      Helge Oldach <>
Subject:   Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess)
Message-ID:  <>
In-Reply-To: <> from "Crist J. Clark" at "Nov 13, 2003 10:16:20 pm"

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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)
>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

The core issue is that FreeBSD does neither support SPI-based NAT, nor
does it support UDP-encapsulated IPSec.


Want to link to this message? Use this URL: <>