OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: NAT

Re: NAT

Ryan Russell (ryanrsybase.com)
Sun, 14 Jun 1998 11:23:01 -0700

Does the instance where IPSec worked when NATted
point out a broken or incomplete implementation, then?

Part of the authentication for an authenticated IPSec
connection is the IP addresses on the endpoints.
>From what little I know, you'd most likely always want
authentication on in a VPN situation.

There is the proxy part of the spec, but that didn't sound
too well defined, and not very workable. Only works for
a single proxy, too.

I'm not clear on your Sidewinder example... Packets
coming in from the VPN client get decrypted on
the gateway in either case.. When the endpoint
is the gateway itself...where does it get the final destination
address.. unless it's in tunnel mode. When the destination
is "inside" past the gateway.. does the gateway change the
source address of the packet to be itself, or does the inside
machine think it's being connected to from all the way out in
the Internet?

To speak to the original question... Checkpoint's SecuRemote
breaks if there is any kind of NAT or proxying going on
before it hits the home gateway. It's happy if the home
gateway is the one doing NAT, after decryption. I'll
second the statement that VTCP/Secure (a.k.a. PowerVPN)
is perfectly happy being NATted and proxied along the way,
making it quite flexible.

                    Ryan

Tina Bird <tbirdiegroup.com> on 06/12/98 10:33:29 PM

Please respond to Tina Bird <tbirdiegroup.com>

To: "Burden, James" <JBurdencaiso.com>
cc: "'Appel, John'" <AppelJ1st-annapolis.com>,
      "'firewall-wizardsnfr.net'" <firewall-wizardsnfr.net> (bcc: Ryan
      Russell/SYBASE)
Subject: Re: NAT

This isn't true! I'm aware of a large number of VPN installations,
both IPSec and proprietary, which work quite happily with NAT. Even
PPTP is interoperable now with address translation, at least once
you've got your routes set up correctly.

F'r instance: Sidewinder firewalls perform NAT "by default" - that
is, you can't have a live Sidewinder that >doesn't< have address
translation thanks to the two-or-more NICs, and the lack of IP
forwarding. Sidewinder supports IPSec in both transport and tunnel
modes, allowing the VPN to terminate on either the external side of
the firewall (in which case the unencrypted, destination side of the
IPSec association is the "final" destination, as far as the VPN is
concerned) or on the internal side of the firewall (in which case
the firewall hands off the traffic to the destination machine on the
interior network). In either case, the firewall is the
decryption server, and it's only ever the external
firewall IP address which is visible to the public network.

I've worked with 3 or 4 other VPN products (Alta Vista, PPTP,
VTCP/Secure and Signal 9) with similar success in a NAT environment.

Tina Bird

Received: from tunnel.sybase.com ([130.214.231.88]) by ibwest.sybase.com
(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 88256623.00282435;
Sun, 14 Jun 1998 00:18:27 -0700
Received: from smtp1.sybase.com (smtp1 [130.214.220.35])
          by tunnel.sybase.com (8.8.4/8.8.4) with SMTP
       id AAA29618; Sun, 14 Jun 1998 00:16:14 -0700 (PDT)
Received: from halon.sybase.com by smtp1.sybase.com
(4.1/SMI-4.1/SybH3.5-030896)
     id AA11836; Sun, 14 Jun 98 00:16:13 PDT
Received: from nfr.net (tower.nfr.net [208.196.145.10])
          by halon.sybase.com (8.8.4/8.8.4) with ESMTP
       id AAA23966; Sun, 14 Jun 1998 00:16:05 -0700 (PDT)
Received: (from Received: (from listslocalhost)
     by nfr.net (8.8.8/8.8.8) id VAA03068
     for firewall-wizards-outgoing; Sat, 13 Jun 1998 21:40:06 -0500 (CDT)
Received: (from Received: (from fwizlocalhost)
     by nfr.net (8.8.8/8.8.8) id VAA03046
     for firewall-wizardsnfr.net; Sat, 13 Jun 1998 21:39:57 -0500 (CDT)
Received: from knot.iegroup.com (ns.iegroup.com [24.124.2.253])
     by nfr.net (8.8.8/8.8.8) with ESMTP id AAA24217
     for <firewall-wizardsnfr.net>; Sat, 13 Jun 1998 00:31:31 -0500 (CDT)
Received: from knot.iegroup.com (Received: from knot.iegroup.com (rootlocalhost)
     by knot.iegroup.com with ESMTP id AAA28801;
     Sat, 13 Jun 1998 00:34:30 -0500 (CDT)
Received: from iegroup.com (pulsar.iegroup.com [10.0.1.5])
     by knot.iegroup.com with SMTP id AAA28797;
     Sat, 13 Jun 1998 00:34:30 -0500 (CDT)
Received: from iegroup.com by iegroup.com (SMI-8.6/SMI-SVR4)
     id AAA25850; Sat, 13 Jun 1998 00:34:29 -0500
Message-Id: <35820F29.23D7888Fiegroup.com>
Date: Sat, 13 Jun 1998 00:33:29 -0500
From: Tina Bird <tbirdiegroup.com>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Mime-Version: 1.0
To: "Burden, James" <JBurdencaiso.com>
Cc: "'Appel, John'" <AppelJ1st-annapolis.com>,
        "'firewall-wizardsnfr.net'" <firewall-wizardsnfr.net>
Subject: Re: NAT
References: <59726335C162D111B2CF00805FA7205DC1BB11csifiapp621.wepex.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-firewall-wizardsnfr.net
Precedence: bulk
Reply-To: Tina Bird <tbirdiegroup.com>

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:22 CDT