Ryan Russell
Wed, 17 Jun 1998 12:01:18 -0700

Key management is one problem with NAT, but I'll leave that alone
for the moment.

I'm under the impression that if the IP header of an IPSec packet
gets modified, the packet will get rejected because IP addresses
are part of what's checked for in authentication mode.  I'm also
assuming that authentication mode is wanted/needed when doing
VPN applications.

The problem I'm concerned with is remote-access type VPN
applications.  This is where I send users running around the world
with a piece of software on their laptops, and they get whatever
kind of Internet access they can.  This would include sitting
on someone else's net, and going out through their firewall.
I think the IPSec method of transport is going to have limited
value in those situations, and we'll need something simpler
for a transport, like a TCP connection.


Rick Smith <> on 06/17/98 11:49:16 AM

To:   Ryan Russell/SYBASE
cc:   Tina Bird <>, "''"
Subject:  Re: NAT

At 09:53 AM 6/17/98 -0700, Ryan Russell wrote:
>Your first paragraph clears it up, thanks.  If the IPSec happens
>after NAT, it makes perfect sense.  When one wants to use
>NAT with IPSec, then the device doing NAT would have to participate
>in the IPSec connection.

Why couldn't you put an outboard IPSEC box between the external network and
the box performing NAT? Again, the IPSEC implentation would only see the
translated addresses.

>That would imply that one couldn't get an IPSec connection
>through a box that did NAT/proxy when that box didn't
>participate in the connection.  I think that's going to be
>a major problem for IPSec based VPN soultions.

I generally think of VPN solutions as providing protection to traffic
*outside* a site, so I don't see a problem here. The NAT box sits at the
site boundary.

But if there's a requirement for end to end IPSEC crypto, then NAT would
throw a large and nasty monkey wrench in the middle. Perhaps you were
alluding to in your last message: NAT leaves you nothing to hand a security
association on when you're configuring the system. If you're using ISAKMP,
there's no mechanism to pass your key negotiation through to the endpoint
host. Even then, some ISAKMP modes only work if you have predictable IP


Received: from ([]) by
(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998)) with SMTP id 88256626.0067DEA6;
Wed, 17 Jun 1998 11:54:32 -0700
Received: from (smtp1 [])
          by (8.8.4/8.8.4) with SMTP
       id LAA25949 for <Ryan_Russell@tunnel-w>; Wed, 17 Jun 1998 11:52:14
-0700 (PDT)
Received: from by
     id AA12782; Wed, 17 Jun 98 11:52:13 PDT
Received: from ( [])
          by (8.8.4/8.8.4) with ESMTP
       id LAA12366 for <>; Wed, 17 Jun 1998 11:52:04 -0700
Received: from (root@localhost)
     by with ESMTP id NAA11320;
     Wed, 17 Jun 1998 13:53:28 -0500 (CDT)
Received: from ( [])
     by with ESMTP id NAA11316;
     Wed, 17 Jun 1998 13:53:27 -0500 (CDT)
Received: from ( [])
     by (8.8.5/8.8.5) with SMTP id NAA22754;
     Wed, 17 Jun 1998 13:53:07 -0500 (CDT)
Received: from bowtie ( []) by
(8.6.12/8.6.9) with SMTP id NAA14232; Wed, 17 Jun 1998 13:53:06 -0500
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Jun 1998 13:49:16 -0500
To: "Ryan Russell" <>
From: Rick Smith <>
Subject: Re: NAT
Cc: Tina Bird <>,
        "''" <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"