Opened 17 years ago

Last modified 17 years ago

#1214 closed Bug report

0.9.22 still doesn't do PASV behind a firewall properly

Reported by: ceb004 Owned by:
Priority: normal Component: FileZilla Server
Keywords: Cc: ceb004, Tim Kosse
Component version: Operating system type:
Operating system version:


I've seen similar bugs opened and closed in this bug tracking system, usually blaming the router, but I think that this is still a problem in the latest version of Filezilla Server 0.9.22. 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.

If the router were to blame, it would not have handled the CentOS system behind the firewall properly either, would it?

A log file of the CentOS client trying to connect to the two server is attached.

Attachments (1)

failure.log (1.5 KB ) - added by ceb004 17 years ago.
CentOS client in debug mode connecting to the two server (router reconfiguration in between)

Download all attachments as: .zip

Change History (3)

by ceb004, 17 years ago

Attachment: failure.log added

CentOS client in debug mode connecting to the two server (router reconfiguration in between)

comment:1 by ceb004, 17 years ago

Whoops. I thought I had tested everything, but missed hidden router intelligence. The router in question is aware of the FTP protocol, and for the FTP service remaps the local IP into the global IP. When the Filezilla server feature intended for this effect also does this, it totally confused the issue. Switching the Filezilla passive IP option back to 'default' fixes the problem.

Closing this bug.

comment:2 by Tim Kosse, 17 years ago

These "intelligent" routers are badly broken by design and are causing lots of problems.

Note: See TracTickets for help on using tickets.