im in ur datastreams, fixup’in’ ur protokols

So the other day, I found myself involved in two different attempts to fix the same problem, which had apparently been an issue for over a year for these guys. They both wanted to use FTP to move files from a host on one segment, to an FTP server on another segment. Sounds simple, right? Well if it was, I wouldn’t be writing this article, would I?

 

Situation:
-Two hosts need to communicate with one another using FTP
-across a firewall
-NAT is in place
-the FTP server is using the non-standard port 1959

First, a review of FTP is in order. The current RFC for FTP is 959. Note that FTP commands embed network addressing within the Application layer of the protocol each time a PORT command (amongst others) is issued. The client embeds its IP address in the command, as so.

PORT 010,001,001,024,016,002

Note that the address is represented as padded, comma separated octets. The FTP server uses that information to open a connection back to the client for the data transfer. In this instance, the FTP client is on one network segment, the FTP server is on another, and there is a firewall between them. In the stream, the client’s network traffic is translated by the firewall so that it appears to be at the desired address, even though it is located on another network. This is transparent to both hosts, and to the user. Unfortunately, the FTP server cannot access the FTP client at the real ip.addr (10.1.1.24) because the NAT represents the FTP client as having ip.addr 10.3.1.24.

While Network Address Translation is frequently used, there are limitations to what it can do. The normal NAT process can only alter ip.addrs at the Network layer, and port numbers at the Transport layer. For many protocols, this is sufficient to permit the use of NAT, and to do so in a way that is transparent to the user, the hosts, and the application protocol(s) in use. There are however certain protocols that embed the ip.addr and/or port within the Application layer, as FTP does in its port commands. NAT does not inspect the Application layer, so when the destination host receives traffic with one set of addressing at the Network and/or Transport layer, and another set of addressing at the Application layer, problems will occur. This will break RPC traffic completely. For other traffic, there is the fixup command.

PIX firewalls have a feature called fixup which is enabled by default for many protocols on default (IANA assigned) ports. In the firewall configuration, this command is present.

fixup protocol ftp 21

Fixup does several things, but in this case we are most interested in its ability to basically perform NAT functions at the Application layer. Fixup can substitute the NAT address for the real one in the PORT commands transparently, neatly fixing the problem. Of course, if the FTP service had been bound to the default port, this would not have been a problem to begin with. The necessary action on the firewall is to add this command.

fixup protocol ftp 1959

Problem solved.

Summary:

  1. Whenever possible, stick with default ports.
  2. When using NAT, evaluate the protocols in use for whether or not they play nicely with NAT.
  3. Use the fixup protocol command to inspect the application layer and make relevant corrections.
  4. Remember that not all protocols can be fixed up!

here endeth the lesson 😉

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.