RE: IPSec Passthrough

[[e-mail]]

Actually since the SPI values are different in the 2 directions, these
devices first try to associate the incoming and outgoing SPIs by preventing
further new connections to the same IPSec server from clients behind the NAT
device till they see atleast one incoming packet containing the SPI from the
server. Once that association is made, the connection information is
considered complete and they allow other clients to connect to the same
server. It is dependent on the server implementation to distinguish 2
different connections coming from the same IP address (of the NAT device)
and is not a very reliable method of doing things..

Regards

-Bik

-----Original Message-----
From: Vinay K Nallamothu [mailto:[e-mail]] 
Sent: Wednesday, April 30, 2003 11:10 PM
To: Mark Siler
Cc: [e-mail]
Subject: Re: IPSec Passthrough

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.

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


vinay