This chapter discusses File Transfer Protocol (FTP) behavior and configuration on the SteelHead, including how to configure in-path and QoS rules to accomplish specific functions. This chapter includes the following sections:

FTP is a standard network protocol used to copy a file from one host to another over a TCP/IP-based network. FTP is built on a client-server architecture and uses separate control and data connections between the client and server.

By default, FTP optimization is enabled on all FTP connections.

The FTP protocol consists of two connections: the control connection and the data connection. A client initiates the control connection to the server on TCP port 21. This connection remains open for the duration of the session and sends administrative data (for example, commands, identification, and passwords). After the control connection is established, the data connection transfers the file data.

The data connection uses various originators and ports. When you look at TCP connections and SteelHead optimization, both the control and data connections appear as separate TCP connections. The control connection always appears to go from the FTP client on a random source port to the FTP server on port 21. The data connection properties change significantly, depending on whether active or passive mode is used for the FTP transfer.

Figure: Active mode shows the control connection and data connection used in FTP active mode:

Most of the time TCP port 21 is associated with FTP control and TCP port 20 with data. TCP port 20 is only true with FTP in active mode.

Source: http://slacksite.com/other/ftp.html (Sept 8, 2010)

A potential issue with active mode FTP is the FTP client does not make the actual connection to the data port of the server—it tells the server what port it is listening on and the server connects back to the specified port on the client. From a client-side firewall this appears to be an outside system initiating a connection to an internal client, which can be blocked. For more information, see the SteelHead Deployment Guide.

Figure: Passive mode shows the control connection and data connection used in FTP passive mode.

With passive FTP, both the control and data connections are both originated from the client and that port 20 is not used.

Source: http://slacksite.com/other/ftp.html (Sept 8, 2010)

Passive mode FTP solves many of the problems from the client-side security perspective, although it does require the server to accept a remote connection to a range of high numbered ports. Most clients today support both active and passive mode FTP. The default Windows client does not support passive FTP, along with some Unix versions, such as Solaris.

Many people prefer to use their web browser as an FTP client. Most browsers only support passive mode when accessing ftp:// URLs.

SteelHeads are aware of FTP connections in either active or passive mode, and they correlate the data channels with the control channel.

By default, FTP uses the standard optimization rule for in-path rules. If you use manual optimization rules, follow the standard in-path practice, configuring the client-side SteelHead in-path rules based on IPs or TCP port. With the TCP port, it is only necessary you specify destination port 21, which automatically includes optimization for the data channels, regardless of whether active or passive mode is used.

To pass through FTP, we recommend creating pass-through rules based on the FTP server IP, on both the client-side and server-side SteelHeads. You base the rules this way because of varying data connection behavior depending on active or passive mode. Because the source of the data connection is the FTP server in active mode, it is necessary to configure the in-path pass-through rules on the server-side SteelHead—this configuration is unlike other protocols.

When configuring QoS classification for FTP, the QoS rules differ depending on whether the FTP data channel is using active or passive FTP. Active versus passive FTP determines whether the FTP client or the FTP server select the port connection for use with the data channel, which has implications for QoS classification.

With active FTP, the FTP client logs in and enters the PORT command, informing the server which port it must use to connect to the client for the FTP data channel. Next, the FTP server initiates the connection towards the client. From a TCP perspective, the server and the client swap roles. The FTP server becomes the client because it sends the SYN packet, and the FTP client becomes the server because it receives the SYN packet.

Although not defined in the RFC, most FTP servers use source port 20 for the active FTP data channel.

For active FTP, configure a QoS rule on the server-side SteelHead to match source port 20. On the client-side SteelHead, configure a QoS rule to match destination port 20.

You can also use the Application Flow Engine (AFE) to classify active FTP traffic.

With passive FTP, the FTP client initiates both connections to the server. First, it requests passive mode by entering the PASV command after logging in. Next, it requests a port number for use with the data channel from the FTP server. The server agrees to this mode, selects a random port number, and returns it to the client. Once the client has this information, it initiates a new TCP connection for the data channel to the server-assigned port. Unlike active FTP, there is no role swapping and the FTP client initiates the SYN packet for the data channel.

The FTP client receives a random port number from the FTP server. Because the FTP server cannot return a consistent port number to use with the FTP data channel, RiOS does not support QoS Classification for passive FTP in versions earlier than RiOS 4.1.8, 5.0.6, or 5.5.1. Later RiOS releases support passive FTP and the QoS Classification configuration for passive FTP is the same as active FTP.

When configuring QoS Classification for passive FTP, port 20 on both the server-side and client-side SteelHeads means the port number is being used by the data channel for passive FTP, as opposed to the literal meaning of source or destination port 20.

With RiOS 8.0.4 and later, the AFE monitors the FTP control connection. AFE learns the negotiated port numbers and connection initiator from the FTP control connection. You can then use AFE to classify active and passive FTP connections for IPv4.

The AFE is unable to classify FTP correctly in a server-side out-of-path (SSOOP) SteelHead deployment with the exception of optimized FTP in active mode.

For more information about QoS and AFE, see the SteelHead Deployment Guide and the SteelHead User Guide.

Although the FTP data and control connections are separate TCP connections, the two channels are correlated. For example, the sender requests to close the data connection over the control channel when a file has finished transmitting.

With WAN optimization in place, the sender can incorrectly believe that the file transfer has complete and send a request over the control channel to prematurely close the data connection. Because the SteelHead acts as a TCP proxy, the sender is actually communicating with the local SteelHead. In certain environments with high latency or low data reduction, the local SteelHead can still be sending the file, but the sender sends the request to close the data connection before the file is completely finished.

If you find that the data connection is closing prematurely, you can adjust a manual delay to the sender request. Use the protocol ftp delay-close-sec <time-in-seconds> command on the SteelHead local to the FTP server. We recommend 30 seconds for most environments.

SteelCentral Controller for SteelHead Mobile only optimizes connections originating from the SteelHead Mobile. With active FTP, the data connection is opened from the server to the client. SteelCentral Controller for SteelHead Mobile does not optimize active FTP because the data connection originates from the server. Although the majority of FTP client software supports passive mode, ensure your client is capable and configured correctly to use passive FTP when using SteelCentral Controller for SteelHead Mobile.

For more information about SteelCentral Controller for SteelHead Mobile, see the SteelHead Deployment Guide.