Rick Smith
Wed, 17 Jun 1998 13:49:16 -0500

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