Chris,
Thanks for the info.
> I think that you meant to say that Crypto and NAT do not mix.
I guess that's true too, but no, I really meant what I said...
> 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
Correct, and this was indeed a problem. However I was able to
configure my ftp proxy to ignore the address part of the PORT command
and just use the port number - thus working around the NAT problem.
[BTW, the ftp sessions we are talking about are outbound through their
PIX f/w and in-bound through my proxy based f/w - hence my requirement
for crypto.]
They still could not get a data session going because the PIX was
blocking the inbound data connections - we presume because it had not
seen the port in the PORT command and therefore not opened a window of
opportunity...
If the above assumption is correct - and the folk who ran the PIX
thought it was, then even with NAT turned off, the encrypted FTP was
never going to work.
So we get back to SPF and crypto don't mix :-)
--sjg
References:
|
|
