Subject: Re: IPSec Passthrough

From: Vinay K Nallamothu <[email-masked]>
Date: 01 May 2003 11:40:03 +0530

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: Francis Dupont <[email-masked]>
Date: Thu, 01 May 2003 18:07:13 +0200

In your previous mail you wrote:

=> I know at least one of the cited SOHO routers which just puts
on the "other side" any packet with an "unknown" protocol when
the IPsec passthrough is enabled (i.e., it behaves like a bridge).
It is a bit surprising but convenient for my usage (IPv6 over IPv4
passthrough). But some others seem to be "smart", i.e., they believe
they know IPsec and try to do "clever" things, for instance they
try to support many IPsec "clients", including of the same VPN.

Regards

[email-masked]

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 1 May 2003 10:05:51 -0700

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

> 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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 May 2003 14:40:40 -0400

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

Tunnel and transport mode differ in several ways that make them more 
different that what you suggest above, for example:

	- in tunnel mode we discard the outer IP header, whereas in 
transport mode we don't discard anything from the inbound packet

	- the modes differ in terms of which headers are checked for 
inbound access control (the topic of a recent thread on this list)

Steve

---

From: "Subrata Goswami" <[email-masked]>
Date: Sat, 3 May 2003 09:49:29 -0700

Transport Mode and Tunnel Mode are also different in how fragmentation
is handled. A Transport Mode ESP implementation needs to have its own
fragmentation function as per RFC 2401.

Subrata

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Friday, May 02, 2003 11:41 AM
> To: Joshua Graessley
> Cc: [email-masked]
> Subject: Re: IPSec Passthrough
> 
> 
> >