Filezilla Server Active Mode is not RFC compliant

[anonymous]

Hello,

A customer called me because he had problems using
active FTP through his firewall.
I checked a bit and I remarked that many other FTP
servers were doing well with active FTP through his
firewall (checkpoint). The difference is that the server
that are working ok are RFC 959 compliant. It looks like
Filezilla server is not compliant (because of time, I could
only make very few testings) because when the FTP-
DATA connexion is set up from the server to the client,
the source port should be 20 (actually "listening port -
1", according to the RFC). It looks like filezilla sets the a
random source port > 1023. Stateful firewalls (at least
checkpoint) doesnt take in consideration this connexion
as a part of an existing one and the drops the data
connexion.

Extract of the RFC :

​http://www.w3.org/Protocols/rfc959/A3_FTP_RFCs.html

The user-DTP must "listen" on the specified data port;
this may be the default user port (U) or a port specified
in the PORT command. The server shall initiate the data
connection from his own default data port (L-1) using
the specified user data port.

[yurivkhan]

A quick-and-dirty patch is quoted below. However, I’m not at
all confident this is the proper place to set the
SO_REUSEADDR option. A better design decision would be to
separate socket creation (socket()) and bind()ing, allowing
client code to call SetSockOpt in between them.
--- AsyncSocketEx.cpp.bak Sat Dec 04 05:06:26 2004
+++ AsyncSocketEx.cpp Fri Jan 28 02:33:51 2005
@@ -700,6 +700,12 @@

}

}

+ if (0 != nSocketPort && 0 != (FD_CONNECT & lEvent))
+ {
+ BOOL value = TRUE;
+ SetSockOpt(SO_REUSEADDR, reinterpret_cast<const
void*>(&value), sizeof(value));
+ }
+

if (!Bind(nSocketPort, lpszSocketAddress))
{

Close();

[Tim Kosse]

This bug report has been closed due to inactivity and has possibly
already been solved.

You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).

[yurivkhan]

Oh no you don’t. The problem is still there.

To reproduce:

• Start up the server, in normal configuration (listen on

port 21, allow anonymous ftp).

• Connect a client.
• Connect another client.
• Initiate transfers of big enough files in both clients, in

active FTP mode.

• On clients and the server, execute 'netstat -an'.

Expected behavior:

• On each client: There is one outgoing connection from

client:random_port to server:21, and one incoming connection
from server:20 to client:random_port.

• On server: There is one incoming connection per client,

from client:random_port to server:21; and one outgoing
connection per transfer, from server:20 to client:random_port.

Observed behavior:

• At least one client will report that its incoming data

connection is from server:port_other_than_20.

• Server will report that at least one of its outgoing data

connections is from server:port_other_than_20.