Hi Kelly,
The PIX conforms to RFC-1631. The big example that they give in that RFC is
the case of ftp. There are some ftp commands that embed the IP address into
the payload, just like you noted. The PIX (like most other NAT devices -
and actually I can't think of any that don't) will actually look into the
payload and convert the appropriate addresses it finds there. And, like the
RFC says, the IP and TCP checksums will need to be recalculated before it
can be forwarded. The RFC also mentions ICMP as another protocol that will
require checking for addresses embedded in the payload. Since that time,
there have been a lot of protocols which also embed some of the IP or TCP
header information into the payload. This is the challenge of all NAT
engineers; to keep up with the new protocols and make sure that they work
through the NATificator.
And actually (since I'm thinking about it and I still have a glug of beer
left in the bottle), the PIX engineers told me that RFC-1001/1002
NetBIOS/TCP/IP has the IP addresses embedded in various frames at mobile
places. Yech. In your example, the right PIX would convert the IP
source address in the IP header as well as any occurances of the source
address in the payload for outgoing frames. The left PIX would convert
the destination IP address as well as any occurances of that in the
payload for incoming packets. As long as the PIXen maintain translation
tables, the session will be built between the two end stations. (And,
in fact, this will be just the same for any other NATificators.)
Hope this helps,
Chris Lonvick
Cisco Systems
Consulting Engineering
Houston, TX, USA
+1.713.778.5663
At 06:43 PM 6/6/97 -0700, Kelly E. Gibbs wrote:
>
>Is it fair to assume that PIX does not alter data content, for example, if
>I FTP to another host through 2 pix boxes, the FTP PORT command would
>reveal the IP address - correct?
>
>
> 10.10.2.2 ---> 10.20.2.1 |-| 10.20.3.1 ------> 10.10.3.3
> PIX PIX
>
>
>
>
>
>
|
|
