Re: NAT

Tina Bird (tbirdiegroup.com)
Tue, 16 Jun 1998 22:00:13 -0500

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
• Next message: Don Kendrick: "Anyone know much about DCOM?"
• Previous message: Ryan Russell: "Re: Database lookups across firewall"
• Next in thread: Ryan Russell: "Re: NAT"

Hmm, yes, looks like we're talking at cross purposes here. In the
second example I described (sorry, not sufficiently visually oriented
here to do pictures), the firewall wasn't itself performing any
encryption, only the internal server - no wonder I/we was/were
confused!

However, it has recently been brought to my attention that there may be
a legitimate reason for the second sort of scenario. If one needs to
encapsulate non-TCP/IP traffic for Internet transport, say IPX, one
might want to send the IPX traffic to a PPTP encryptor first (or an
L2TP router), then further encrypt the PPTP packets in some
stronger encryption/authentication system. Haven't seen it in
action. Does sound like more of a bottleneck than it might be worth,
but ought to be feasible.

Sorry for the confusion -- t.

Burden, James wrote:
>
> Thanks John for your reply, the URLs were good reading.
>
> Tina,
>
> May I ask what isn't true? I had a hard time following your example ( I
> like pictures myself). So, I am going to draw them.
>
> I think you are giving two examples. First:
> [Outside host(encrypt)]<<--(VPN)-->>[Firewall (decrypt - NAT)]<<---clear
> text--->>[inside host]
>
> I think we can both agree that NAT does not interfere in this scenario.
> Although, NAT will always add _some_ latency to network performance, but
> this is a given.
>
> Second:
> [Outside Host(encrypt)]<<--(VPN)-->>[Firewall(decrypt - NAT -
> encrypt)]<<--VPN#2-->>[inside host(decrypt)]
>
> However, the second scenario I say is costly (kludgey - Is this the
> right spelling??). Not that it cannot be done. If this is done we can
> see that we are encrypting and decrypting twice. As the security
> architectures/products are already behind the network
> infrastructure/products by 2-3 years in terms of throughput (i.e.,
> Gigabit Ethernet and ATM OC-3/OC-12.....) then the security engineers
> are in danger of impeding corporation progress and/or needs. Vendors
> are just now able to support Fast Ethernet (FE) to a fair degree (I
> should define this as not just connecting with a FE interface, but
> supporting near line speeds). There will be a performance hit (cost)
> taken when using scenario 2 compared to if there were no NAT and only
> encrypting & decrypting once.
>
> If I am missing something, please clue me in.
>
> Jim
>
> > -----Original Message-----
> > From: Tina Bird [SMTP:tbirdiegroup.com]
> > Sent: Friday, June 12, 1998 10:33 PM
> > To: Burden, James
> > Cc: 'Appel, John'; 'firewall-wizardsnfr.net'
> > 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
> >
> > Burden, James wrote:
> > >
> > > John,
> > >
> > > Besides RFC1918 you can read RFC1631 - The IP Network Address
> > Translator
> > > (NAT). K. Egevang & P. Francis.
> > > May 1994. (Format: TXT=22714 bytes) (Status: INFORMATIONAL).
> > >
> > > I am not aware of a pro/cons white paper yet. However, VPN
> > (example:
> > > IPSEC) technologies are costly and kludgey working with NAT. If IP
> > > headers are encrypted then a tunnel would have to begin and end any
> > > where NAT is used.
> > >
> > > Jim
> > >
> > > James Burden Phone - 916.351.2243
> > > Security Engineer Page - 916.814.2563
> > > California ISO Fax - 916.351.2181
> > > http://www.caiso.com Email - jburdencaiso.com
> > > 41DF 0E4C 26E0 2FD3 8C81 A260 5C40 280E B4AE 7420
> > > ____________________________________________
> > > To Teach is to Learn - Aaron Nimzovich
> > > ____________________________________________
> > >
> > > > -----Original Message-----
> > > > From: Appel, John [SMTP:AppelJ1st-annapolis.com]
> > > > Sent: Wednesday, June 10, 1998 12:05 PM
> > > > To: 'firewall-wizardsnfr.net'
> > > > Subject: NAT
> > > >
> > > > Is there a FAQ or similar document covering the pros/cons/caveats
> > of
> > > > NAT?
> > > >
> > > > TIA,
> > > >
> > > > John

• text/x-vcard attachment: vcard.vcf

• Next message: Don Kendrick: "Anyone know much about DCOM?"
• Previous message: Ryan Russell: "Re: Database lookups across firewall"
• Next in thread: Ryan Russell: "Re: NAT"

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