Certain clients disconnect or stall

[nollidj]

I run an FTP server with FileZilla Server (currently on 0.9.20 on Windows Server 2003 SP1). Users use a great variety of clients to connect, and I have found that some have trouble with the service FileZilla offers. Sometimes, for little apparent reason, a client will not be able connect after it issues a PASV command. It appears to hang, as though it is expecting something further from the server.

One such client is Bulletproof FTP 2.58 under Windows. A trial version can be downloaded from bpftp.com .

I have attached the logs that I have on the server end and what the client reports.

After connecting and authenticating, the client issues PASV and then hangs. The server reports that it disconnects, but the client behaves as though it is still connected and is expecting a response to the PASV command.

[nollidj]

Client and sever logs

[Tim Kosse]

Are you using any routers or firwalls on client and/or server side? Please check router configuration and try with firewalls uninstalled (Only way to truly disable them) to see if problem persists.

[nollidj]

I think I am mistaken in saying that this is an issue with certain clients. I am sorry about being confused in this; there have been many users here who have had trouble with their FTP clients, and I have had to troubleshoot them to the extent my memory has confused things.

I can recreate the problem under any client with any user by connecting with SSL disabled and passive mode on. For some reason, the server disconnects from the client after PASV is sent. I am able to issue other commands; here is an example, using lftp under Linux, of sending just CWD without PASV.

Server says:
(001315) 11/20/2006 12:19:02 PM - (not logged in) (xxx)> Connected, sending welcome message...
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> FEAT
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> 211-Features:
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> MDTM
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> REST STREAM
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> SIZE
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> MLST type*;size*;modify*;
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> MLSD
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> AUTH SSL
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> AUTH TLS
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> UTF8
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> CLNT
(001315) 11/20/2006 12:19:04 PM - (not logged in) (xxx)> 211 End
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> CLNT lftp/3.5.6
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> 200 Don't care
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> OPTS UTF8 ON
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> 530 Please log in with USER and PASS first.
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> USER user
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> 331 Password required for user
(001315) 11/20/2006 12:19:06 PM - (not logged in) (xxx)> PASS *
(001315) 11/20/2006 12:19:06 PM - user (xxx)> 230 Logged on
(001315) 11/20/2006 12:19:06 PM - user (xxx)> CLNT lftp/3.5.6
(001315) 11/20/2006 12:19:06 PM - user (xxx)> 200 Don't care
(001315) 11/20/2006 12:19:06 PM - user (xxx)> OPTS UTF8 ON
(001315) 11/20/2006 12:19:06 PM - user (xxx)> 200 UTF8 mode enabled
(001315) 11/20/2006 12:19:06 PM - user (xxx)> PWD
(001315) 11/20/2006 12:19:06 PM - user (xxx)> 257 "/" is current directory.
(001315) 11/20/2006 12:19:07 PM - user (xxx)> CWD /wwwroot
(001315) 11/20/2006 12:19:07 PM - user (xxx)> 250 CWD successful. "/wwwroot" is current directory.
(001315) 11/20/2006 12:19:22 PM - user (xxx)> QUIT
(001315) 11/20/2006 12:19:22 PM - user (xxx)> 221 Goodbye
(001315) 11/20/2006 12:19:22 PM - user (xxx)> disconnected.

Client says:
lftp :~> set ssl-allow no
lftp :~> set passive-mode yes
lftp :~> open xxx
lftp xxx:~> login user
Password:
lftp user@xxx:~> cd /wwwroot
cd ok, cwd=/wwwroot
lftp user@xxx:/wwwroot> cd /
lftp user@xxx:/> exit

I do not believe that firewalls or routing is a problem; if I connect to any account using SSL, there is no problem with a passive connection. In addition, I have tried connecting from a third location (a Linux machine where I recorded the lftp session) not on the network where I first encountered this problem and had the same issues.

[nollidj]

I have continued to investigate this, and it looks like a NAT or firewall issue, though it is a strange one. I am able to to the server from the server using passive and active FTP in SSL/TLS and non-encrypted FTP sessions.

I have tried to connect from a client that does not have any NAT or firewalling between it and the Internet, the problem persists: the client is disconnected after issuing PASV unless it is using a secure connection. Is there any difference between an encryption-less FTP session and one that uses some form of SSL or TLS authentication that would cause a firewall or NAT setup to disconnect clients that are not using SSL or TLS?

[nollidj]

Configuration for which clients do not get a response to PASV

[nollidj]

I have continued to investigate this, and here is what else I have found:

Our firewall is not restricting outgoing traffic in any way. It looks at traffic and will dynamically open ports if it sees a passive response in an FTP conversation, but that is all it is doing. We already have the appropriate ports open anyway.

One of our firewall admins gave me a dump of what our firewall sees when a client sends a PASV request without authenticating under SSL. The firewall never sees the server's passive response to a PASV request.

I then went so far as to create a blank, new server configuration file and create a single user with it. I was able to log in as that user using a passive connection using the port range that our regular configuration used.

I then took our original configuration file and copied the <Settings>...</Settings> block over the corresponding block of the fresh, single-user configuration. After starting the server with this configuration, I was no longer able to log in as the single user.

This leads me to believe that there is something to do with the specifics of our server configuration that is causing the problem and not an issue with a firewall. I have attached our (sanitized) test configuration file.
File Added: FileZilla Server.xml.example

[nollidj]

Further investigation with a packet sniffer shows that FileZilla Server sends a TCP reset when a client issues PASV. This only happens when the value of "External Server IP Address for passive mode transfers" is set to a valid value other than the server's IP address behind the NAT/firewall.

Here are some sample conversations that match what I have observed:

(Server is configured to advertise its external IP as its address in passive connections):
Client: authenticate under TLS?
Server: authentication OK
Client: PASV
Server: EXTERNAL,ADDRESS,AND,PORTS
(client can issue LIST and other commands to get data on the passive connection)

Client: authenticate in cleartext?
Server: authentication OK
Client: PASV
Server: EXTERNAL,ADDRESS,AND,PORTS
Server: TCP reset, connection closed
Client: (hangs waiting for a reply to the PASV, may reissue PASV command several times)

(Server is configured with an invalid address like 127.0.0.1 or 0.0.0.0 as its address in passive connections)
Client: authenticate under TLS?
Server: authentication OK
Client: PASV
Server: INVALID,ADDRESS,AND,PORTS
Client: LIST
Client: (error because a connection to get the data cannot be made)

Client: authenticate in cleartext?
Server: authentication OK
Client: PASV
Server: INVALID,ADDRESS,AND,PORTS
Server: TCP reset, connection closed
Client: (hangs waiting for a reply to the PASV, may reissue PASV command several times)

(Server is configured with default address or the local address set as a custom value to advertise as its address in passive connections.)
Client: authenticate under TLS?
Server: authentication OK
Client: PASV
Server: LOCAL,ADDRESS,AND,PORTS
Client: LIST
Client: (error because a connection to get the data cannot be made)

Client: authenticate in cleartext?
Server: authentication OK
Client: PASV
Server: LOCAL,ADDRESS,AND,PORTS this is corrected to the external address by our firewall, but what may be important is that there is no TCP reset sent
Client: (sees the correct external address and can connect for LIST and other commands)

[Tim Kosse]

"Further investigation with a packet sniffer shows that FileZilla Server
sends a TCP reset when a client issues PASV"

FileZilla Server doesn't, but your broken router or firewall does. Please contact their support.

[nollidj]

You are right on about it being a problem with a firewall in front of the server. It took a long time of discussing this with our hosting provider (as long as this bug has been around), but they finally told me that they use the Cisco fixups on FTP connections. Disabling them got things working properly. Thanks for bearing with this, especially since you see it so often.

[ceb004]

I think this is still a problem on 0.9.22, and this bug should not be closed. Here's what I did to demonstrate this.

Inside a router firewall, I set up two servers, one WinXP with Filezilla 0.9.22. The other was a CentOS server running vsftpd. The router was set up to pass ports 20,21 as well as ports 1024-1033, with the two FTP servers configured accordingly.

Outside the firewall, I had two Unix servers, one running CentOS, and the other running FreeBSD.

The FTP client on the CentOS system speaks PASV mode only. When the router was set to point to the CentOS system behind my firewall, then things worked -- the 227 response provided my public IP (of the router), and two port numbers, which when multiplied together, provided something in the specified range of 1024-1033. However, when the router was redirected with the same rules to point to the Filezilla server (differen LAN IP only), then I could log in, but I could not execute an LS. Looking at the Filezilla server log, a correct 227 response to the PASV mode command was entered, but apparently never properly received by the CentOS FTP client. So it hung until the connection timed out.

On the other hand, the FTP client of the FreeBSD server outside the firewall speaks EPSV, which seems to work fine with both the CentOS and Filezilla servers behind my firewalls. With EPSV, the port number to use is transmitted premultiplied together.

I've seen this bug opened and closed several times in this system, but I still don't believe it has been fixed. The times that it was closed, the router got the blame, but here that cannot be the case -- how is it that the router works fine for the CentOS server but not for the Filezilla server.