Re: IPSec Passthrough

[Joshua Graessley <jgraessley@apple.com>]

On Wednesday, April 30, 2003, at 23:10, Vinay K Nallamothu wrote:

> On Wed, 2003-04-30 at 20:37, Mark Siler wrote:
>> I'm curious on how IPSec passthrough works.  I know AH prevents a
>> traditional NAT from occurring, but how do the SOHO routers (Linksys,
>> D-Link, Ascend, etc) accomplish the IPSec passthrough?
>
> These devices track the IPsec connections by looking at the SPI in
> IKE/ESP headers.
>
> When they first see the IKE packets from the client behind the NAT they
> note down the SPI value, client address and then masquarade the packet
> as usual with its own IP.
>
> When they see the packets from the remote IPsec peer, it looks into the
> table using SPI and replaces the destination with client's IP.
>
> This mechanism works only with ESP and not with AH which is fine as 
> most
> of the road warriors connect to IPsec gateways.
>
> You can get more details about this in sections 9.0 to 9.3 of
> draft-ietf-ipsec-ikev2-tutorial-01.txt.

The SPI for traffic in each direction will be different. As a result, 
the NAT will not know which node to send incoming packets to. Most NATs 
will only support IPSec NAT Transparency for one node behind the NAT. 
The remote IP address can be used as a selector to support multiple 
devices behind one NAT as long as they all communicate with different 
remote hosts.

>>  Do they
>> encapsulate the entire IPSec packet from the client?
> No
>
>>  I keep reading
>> about a Transparent Mode and Tunnel Mode,
> For NAT-T unware IPsec peers, the above mentioned mechanism is not
> visible and hence called transparent. Further this works only when the
> client behind the NAT is a road warrior.

There are two "modes" that IPSec operates in, tunnel mode and transport 
mode. This is, in my opinion, a little bogus because "tunnel mode" is 
really just transport mode where the next header is an IP header 
instead of UDP, TCP, ICMP or some other protocol. Anyhow, the NAT 
transparency only works with Tunnel mode (where the next header after 
the ESP header is IP). In transport mode, the TCP and UDP checksums 
will be screwed up. ESP encrypts and authenticates the payload so the 
NAT can't molest it. The UDP and TCP checksums take bits of the IP 
header in to account, most notably the source and destination IP 
addresses. The NAT modifies the destination IP address. Since it can't 
see or modify the TCP or UDP checksum to compensate for the address 
change, TCP and UDP packets will be dropped due to a bad checksum.

-josh