pure-ftpd passive transfers not working
 

I have a dns-323 linux device that's running pure-ftpd with SSL/TLS authentication. Pure-ftpd is sitting behind a linksys router with IP 192.168.1.51. Pure-ftpd is configured for port 8021 and passive port range 55562-55663. The linksys router is configure to forward port 8021 and the passive port range to 192.168.1.51.

From outside my network I can connect to the ftp server using the WAN address of the router. I'm using filezilla 2.2.32 as my client and I choose FTP w/ explicit TLS (no other option will connect). The client will authenticate successfully with pure-ftpd but once it sets up the passive data connection and tries to do a LIST of the root directory, there's a timeout. I'm assuming this is because the passive data connection is not working. In pure-ftpd, I tried changing the passive address that it reports, to be the WAN address of the router, but it did not make a difference. I included the log from filezilla below.

Any tips would be appreciated.

-Kevin

Status: Connecting to WANaddress.com:8021 ...
Status: Connected with WANaddress.com:8021, negotiating SSL connection...
Response: 220---------- Welcome to Pure-FTPd [TLS] ----------
Response: 220-You are user number 1 of 10 allowed.
Response: 220-Local time is now 09:13. Server port: 8021.
Response: 220-This server supports FXP transfers
Response: 220 You will be disconnected after 2 minutes of inactivity.
Command: AUTH TLS
Response: 234 AUTH TLS OK.
Status: SSL connection established. Waiting for welcome message...
Command: USER myusername
Response: 331 User myusername OK. Password required
Command: PASS ********
Response: 230 OK. Current restricted directory is /
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Extensions supported:
Response: EPRT
Response: IDLE
Response: MDTM
Response: SIZE
Response: REST STREAM
Response: MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
Response: MLSD
Response: ESTP
Response: PASV
Response: EPSV
Response: SPSV
Response: ESTA
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: 211 End.
Command: PBSZ 0
Response: 200 PBSZ=0
Command: PROT P
Response: 534 Fallback to [C]
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: CWD /Volume_1/
Response: 250 OK. Current directory is /Volume_1
Command: PWD
Response: 257 "/Volume_1" is your current location
Command: TYPE A
Response: 200 TYPE is now ASCII
Command: PASV
Response: 227 Entering Passive Mode (192,168,1,51,217,106)
Command: LIST
Error: Timeout detected!
Error: Could not retrieve directory listing

The problem is this:

Response: 227 Entering Passive Mode (192,168,1,51,217,106)

Which tells the FTP client to make the passive data connection to 192.168.1.51 on TCP port (217 * 256) + 106 = 55658. The client will never be able to connect directly to that address from outside your LAN. When you tried to have the server report its WAN address, that *should* have worked, esp. since that port is in your range of forwarded ports. So I would try that again, if it doesn't work make sure the server is really sending the WAN address back in its PASV reply with a port that you have forwarded. There are some other things you can try:

- Configure the client to use EPSV (if possible), which will force the server to return just a port - the client will then use the WAN address by default.
- Use curl from the command line to disregard the returned IP. I wrote something up just for this problem a while back, you can see the solution here:

http://blog.unixlore.net/2007/11/usi...-ssl-file.html

I did set it to the wan ip address but I posted the previous log. After I changed it, the log showed the correct wan address but the results were the same. I will check about epsv mode. Does it matter that the client is behind an HTTP proxy? The FTP client is HTTP proxy aware.

Did you double-check that the port was in the range you have forwarded? If so, there is something else blocking the traffic, since from what you have described it should be working. One way to know for sure is to run a tcpdump or wireshark capture on the server during the connection attempt, looking for incoming packets from the client. If you don't see any, you know the router is dropping them or sending them elsewhere.

No - assuming the proxy is only handling HTTP.

Yes, double-checked.

This will be a bit harder because the ftp server is on a linux device, not a computer. I can probably mirror the port for the device on my router to another port and then record with wireshark on that pc.

I'm more worried about this. The proxy is not just for http. But, it is classified as an http proxy. What I mean is that in any application that needs to exit the local network, I have to make it aware that there is an http proxy and give the hostname and port of the proxy. This includes firefox, IE, putty (ssh), filezilla, etc.

I am able to connect to non-tls ftp servers as well as ssh into hosts outside of the local lan.

Sounds like the application proxy is handling your FTP traffic. Can you FTP to a different TLS FTP server outside of your LAN, while still using the proxy? Since you say you can get into your FTP server from elsewhere, perhaps the proxy just doesn't understand FTP over TLS in passive mode, once you get past the initial control connection. I think trying to find out how far the packets get along the path from the proxy to your FTP server is the best way to pinpoint where the problem is.

One other option that may or may not be possible for you is to setup a VPN into your internal network. Then you could tunnel the FTP through the VPN. Recent versions of OpenSSH can do tunneling, or there is openvpn or m0n0wall (which allows you to configure a PPTP VPN server via a nice web GUI). PPTP would be the way to go if you are stuck with a windows client.