FTP sessions failing through Checkpoint firewall
(Last modified: 25May2004)
This document (10076230) is provided subject to the disclaimer at the end of this document.
fact
Novell NetWare 5.1
Novell NetWare 6.0
Novell NetWare FTP Server
Checkpoint Firewall
symptom
FTP sessions failing through Checkpoint firewall
FTP control connections are reset by the Checkpoint firewall.
The output from the commands HELP and STAT (or QUOTE HELP and QUOTE STAT) can trigger Checkpoint firewall to reset the FTP control connection.
The tranmissions of a welcome.txt or message.txt file can trigger Checkpoint firewall to reset the FTP control connection.
cause
When multi-lined control connection responses are split into multiple packets, Checkpoint is not accepting the first packet, and immediately resets the connection.
fix
This is a Checkpoint problem (see below for details). However, Novell has made modifications to FTP to eliminate the issue anyway. NetWare 6.5's NWFTPD.NLM contains the changes. For other platforms, download NWFTPD9.EXE or apply NetWare 5.1 SP7 or NetWare 6.0 SP4.
note
Before discussing the technical details of this issue, it is important to understand three points:
1. There is a difference between a command entered by a user, and the actual command sent to the FTP server. For example, when a user types the command "dir" at a FTP client prompt, the FTP client translates that into a series of actions. At a minimum, it will issue a command to establish the parameters of a data connection (PORT or PASV) then it will issue the LIST command to get a directory list. The command "dir" would actually have no meaning to an FTP server. It is only meaningful to the FTP client.
2. Some FTP data is transmitted over the control connection (like success or failure messages, in response to commands) and some is transmitted over a separate data connection (like directory lists and file transfers). Sometime a command can trigger output using both types of transmissions. For example, a data connection is used to give the directory list, but the control connection is used to announce that the tranmission is complete.
3. According to FTP RFC 959, when an FTP server sends information over the control connection, a 3 digit code is given. When the message will only be one line long, the 3 digit code is followed by a space. When the message will be multiple lines, the 3 digit code is followed by a dash (or hyphen, - ) and the last line of the message will contain the 3 digit code followed by a space. Once that code followed by a space is given, the receiving side knows that it is the last line, and the next end-of-line signal will be the end of the whole message. Usually, all the lines in between the first and last have the 3 digit code and dash as well. This format for the in-between lines is not technically required by the RFC, but it is the most common implementation.
Now, on to the details:
The Checkpoint firewall appears to reject FTP packets that contain just a 3-digit code and a dash. So if the server choses to send just that much in one packet, with the rest of the message coming in another packet, it will not make it through the firewall. Novell's FTP server sends messages in this manner, in 5 cases:
a. Response to a HELP command (if a user wants to force a command-based FTP client to send "HELP", the user should enter "quote help").
b. Response to a STAT command (a user may have to enter "quote stat" to force the STAT command to be sent).
c. During login, if a WELCOME.TXT file is in use, to give a welcome message to users.
d. When CDing to a directory which contains a MESSAGE.TXT file, which is automatically transmitted on the control connection to give a message about the directory.
e. Response to various SITE commands, include SITE HELP, SITE SERVER, SITE SLIST, SITE OU.
The NetWare FTP Server sends (or intends to send) the remainder of the message in a second packet, but the firewall resets the connection and drops the packet before that is possible. FTP clients and FTP servers (and therefore a firewall in between the two) should not care how the data is divided into packets. An application has no guaranteed way to know how the TCPIP stack on the server, client, or router in between may chose to package or fragment the data into one or more packets. The only way to know if the FTP data is valid or not is to reassemble the data from the various packets and then evaluate its validity. Therefore, Checkpoint firewall can not rightfully decide that a FTP packet containing "220-" is invalid, because it has not waited for the rest of the message as defined by the FTP RFC 959.
document
| Document Title: | FTP sessions failing through Checkpoint firewall |
| Document ID: | 10076230 |
| Solution ID: | NOVL83613 |
| Creation Date: | 29Oct2002 |
| Modified Date: | 25May2004 |
| Novell Product Class: | Groupware NetWare |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.