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

[Helge Oldach]

Crist J. Clark:
>> >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.

Agreed, there is no *general* trick. But the hacks I have described work
very well in many business environments.

>> 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.

As I said, must modern VPN devices have it. As a minimum, virtually any
el-cheapo DSL router supports ESP-NAT for a single device (assuming that
all SPIs belong to a single internal address). But many also support
SPI-aware NAT.

>> 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.

Correct. Cisco requires that you use IKE in order to make it work.
Basically this is NAT for ESP, and the SPI-NAT table is being built up
using IKE cookie matching. There is no heuristics involved.

>>   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.

Nothing that works well and has noticeable exposure is useless. This
definitely has both. Not with FreeBSD, though. It does work with Windows
2000 SP4, to put a name up... So it's definitely out there.

>> 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,

Thank you, this is very interesting.

>NAT is evil.

Of course. But it's also a fact of life...

Helge