FTP hangs on: 150 Opening ASCII mode data connection

I am setting up an FTP server on my Windows 2008 server (R2).

Everything appears to be installed correctly but I am having trouble using an FTP Client to login to my FTP server.

I can remote desktop on to the server and through DOS commands I can login rather easily.

But if I issue a command like "DIR", it hangs with: 150 Opening ASCII mode data connection.

Everything I have researched and read points to Firewall ports and/or Passive/Active mode settings.

Here is what bothers me...if I use DOS FTP commands, I can login and use the "DIR" command only if I use "localhost" as my address.

If I specify my full FTP URL, I get the hanging error.

if I specify the "localhost" URL, I do not get the error.

This leads me to believe its a Firewall issue, (or even an IIS7 issue?) but I am unsure what ports I need to open?

I have ports 20, 21 open on my Windows firewall. I have also opened those ports on my AWS (Amazon) firewall.

I believe my FTP client is using some long range port number(s) that are potentially blocked by one of my two firewalls. Ive used Network Monitoring tools to try and see what ports it is calling but I cant figure that out.

Any ideas, tips, tricks, help?


Solution 1:

FTP server and FTP client negotiates which ports are going to be used for the transfer of data (including the directory list when you do a "dir" or "ls") using the "control channel" of FTP. So if your "AWS firewall" is not doing protocol inspection on this channel there is no way he will know which ports it has to dynamically open to allow the traffic flow (and close once those ports are not longer used).

IMHO using network monitoring to discover which ports are being used is not worth the effort because these ports are going to change for every new FTP session.

Unless you have already done it, my best shot at troubleshooting this issue would be to look for any tweak on the firewall that is protecting your FTP server (if I understand your question correctly this would be the "AWS firewall") and see if there is any "knob" to enable inspection for the FTP protocol.

Solution 2:

I received the same message when trying to use the ls command to list the files stored on a UNIX FTP host server from my Ubuntu command line. I was able to successfully log in using ftp ftp.example.com and entering my username and password when prompted. However, I would receive the 150 Opening ASCII mode data connection message and nothing ever happened. Then, I simply entered the option -p (changes it to "passive" mode to deal with firewalls) with the command and it worked.

 ftp -p ftp.example.com

Enter user name and password when prompted, then commands such as ls and cd will work. I believe you can also enter this command and it will do the same thing, but I haven't tested it.

pftp ftp.example.com

I know the question pertains to Windows; however, given the same error was produced figured this tip was worth posting.

Solution 3:

To get real information on why the connection is stuck, you're going to have to use a client that logs all of the protocol commands to see what's really happening. Theres a good site on FTP with example logs here.

Most likely though, either

  1. your client is behind a (dumb, or else SSL-blocked) firewall and is trying to use Active-mode FTP
  2. your server is behind a (dumb, or else SSL-blocked) firewall and is trying to use Passive-mode FTP

If you're using SSL, the only answer is to open a range of ports (say, 10000-11000) on the firewall and configure your FTP server to force Passive mode and use that port range. If your server is using NAT you'll also need to set up the proper IP address for the server to advertise to clients, most obey whatever the server provides as the passive mode connection string and if the server thinks it's 10.1.1.1, that's what it's going to tell the clients.

If you're not using SSL, the best answer is to see if you can get your firewall to do protocol inspection for FTP. The firewall will read the traffic on port 21 and open whatever port your server wants open. This can often fix NAT addresses as well (when the firewall is also handling the NAT). You'll probably still want to force passive mode since some people don't know how to configure their FTP client properly and nearly everyone is behind a broadband router/firewall these days.

If you can't get a smarter firewall, then you'll have to stick to the "open a bunch of ports" option (or switch to a protocol that doesn't need to open a bunch of random ports like ssh's sftp).