Hello Simon,
I think that you meant to say that Crypto and NAT do not mix. That's
always been the case with all types of NATificating firewalls, whether
they be proxies or stateful packet filters. This has long been
recognized as a problem and was even identified in the first group of
IPSEC RFCs. When you're using the Transport Mode encryption as
described in 1827, only the payload is encrypted and the header is the
actual header as it would normally be sent from the device. When this
passes the NATificator, only the header addresses can be translated.
Any information embedded in the payload cannot be identified by the
NATificator, and therefor cannot be translated. So, in your case, the
header was probably translated but the embedded addresses in the payload
were not. This would certainly cause confusion with the process and
would not allow the session to complete.
The workaround (I think that it's identified in 1825) is to use AH between
the workstation and the NATificating firewall, and then let the firewall
perform ESP. In this way, the payload is protected by the hash in the
AH before it reaches the firewall. The firewall will then perform the ESP
to provide confidentiality as it crosses an untrusted network (i.e. the
Internet). At this time, however, the PIX does not work that way, and I
can't think of any firewalls (of any type) to do.
If you use NAT and Crypto together, the proxy firewall would have to
know the session keys to be able to de-crypt the payload so that it
could
1 - identify the session type (telnet, ftp, http, etc.)
2 - NAT any header information contained in the payload
The proxy would then have to re-encrypt the packet and send it along
its merry way. This, besides being exceptionally computationally
intensive, is a bad idea since keys should only be exchanged between the
endpoints. I actually havn't heard of any of any firewall device which
does this. I think that the firewalls that do perform this just provide
a stateful forwarding process to deal with AH/ESP-transport mode sessions
which connect an internal device to an external device. If anyone knows
differently, please respond back to the list.
Try running your test again without NAT. I expect that it will work
since the header information will always agree with any embedded
information and the PIX (or any other type of firewall) will not have
to muck around with address translation.
Hope this helps,
Chris Lonvick
Cisco Systems
Consulting Engineering
Houston, TX, USA
+1.713.778.5663
At 04:19 PM 6/7/97 +1000, Simon J. Gerraty wrote:
>Ryan Russell writes:
>>Well, I finally got around to writing down my arguments
>>on the above subject. Check it out at:
>
>>>I hope to convince the reader, to whatever degree I can, of the following:
>
>>> 1.Proxies are a special case of a SPF.
>>> 2.SPFs can be the more secure choice depending on the requirements.
>>> 3.Network address translation (NAT) can be considered a form of
>>> security on it's own.
>
>One thing to note - SPF and crypto do not mix.
>
>I saw a case last week where users behind a PIX firewall could not use
>an encrypted FTP, because the PIX box could not inspect the content of
>PORT commands and allow the data ports to be connected to.
>
>Solutions are:
>
>1. Use passive mode transfers.
>2. Turn off the filtering in the PIX :-)
>3. Do without crypto :-)
>
>1 is obviously preferable if both sides can handle it - not always the
>case. The other two are not attractive at all. If they'd been using
>a proxy, they would not have had a problem.
>
>--sjg
>--
>Simon J. Gerraty <sjg @
quick .
com .
au>
>
>#include <disclaimer> /* imagine something _very_ witty here */
>
>
Follow-Ups:
|
|
