Subject: RE: IPSec Passthrough

From: [email-masked]
Date: Thu, 1 May 2003 11:14:55 -0700

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:[email-masked]] 
Sent: Wednesday, April 30, 2003 11:10 PM
To: Mark Siler
Cc: [email-masked]
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

---

From: Vinay K Nallamothu <[email-masked]>
Date: 02 May 2003 11:39:19 +0530

> and is not a very reliable method of doing things..
what tricks were used by the NAT-T unware IPsec gateways?

Few mechanisms i could imagine the IPsec gateways did:
1. Use L2TP over IPsec and tie (using firewall rules) the PPP/L2TP
assigned IP address to the IPsec SA.

2. Do some sort of (static?) NAT (again using firewall) on the packets
coming out an SA so that the packets on the reverse path can be reliably
channeled to the correct SA.

Any better ways of doing that?

vinay

---

From: Ramana Yarlagadda <[email-masked]>
Date: Fri, 02 May 2003 12:18:43 -0700

Hi, Vinay

>channeled to the correct SA.

The static NAT requires more no of IP addresses. But with out static NAT 
this can be done, by serializing the IPSEC connections of hosts behind the 
NAT device. Linux  implementation is available for this problem.

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 2 May 2003 12:31:01 -0700

Hi,
   These are the ways to run IPSEC tunnel between two SGs with 
   Firewall/NATs in between the security gateways.

   1. L2TP over IPSEC (rfc3193): It works well and very useful
       to provide remote access for VPN clients. As you may be aware,
       WINXP/WIN2000 comes with built in client.
       Microsoft also provides free client software for WIN98.
       More and more vendors are supporting LNS with IPSEC.

        Disadvantage: More bandwidth is used. 

  2. IPSEC NAT Traversal:
       There is very less penalty on bandwidth compared to L2TP over IPSEC
       (use v2 onwards). Most of the vendors support this feature and is
       interoperable.

  3. NAT boxes having ESP/IKE intelligence:
      In this case, there is no bandwidth penalty. But there are some disadvantages
      with this:
          A. Can't expect this intelligence to be there in all NAT boxes.
          B. Though many clients can establish tunnels with the corp. gateway, until
               tunnel is established in both ways, other clients can't connect to the
              same peer.

Srini
Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com