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?

12 Answers 12


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.

  • Awesome.. Helped me instantly Oct 7, 2015 at 21:07
  • you can also just type "passive" when connected via ftp to switch to passive mode instead of re-establishing connection
    – Muppet
    Mar 26, 2021 at 0:39

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.


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, 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).


I had this problem and it was resolved by doing the following.

I was using FireFTP which by default connects via passive mode. When setting up an FTP in IIS the default port will be 21. I had to open port 21 in the firewall which got me a stage further but it'd hang at Opening ASCII mode data connection.

Turns out it then picks some other dynamic ports. I knew it was a firewall issue as with the firewall off the FTP connects fine. Also locally on the server - no problems.

To fix, I loaded IIS (using version 8.0, believe it's the same in 7.5), at the server level of the tree (that is the top node) single click it and select "FTP Firewall support". Each FTP site you use will use these port ranges, individual FTP sites will have this option greyed out as it's inherited from this section.

In Data Channel Port Range, specify x amount of ports, in my case 10000-10125.

Now, in your firewall open up that range of TCP ports as "FTP passive port range".

I then thought the problem would be solved, but not quite. Be sure to restart the Microsoft FTP service service to pick up the new port range. Close FireFTP/client and retry and this time within any luck you'll be in. :)


We resolved this issue using the Windows Firewall New Inbound Rule Wizard. Select Program, then C:\Windows\System32\ftp.exe, Allow the connection, Check options; Domain, Private, Public (you can restrict later if need be), name the rule and you're done.

Now ftp to an ftp site and verify dir or ls respond properly.


I have the same issue with you and fixed now.

What I did is open Windows Firewall (Win7), click 'Allow a program or feature through Windows Firewall', and then in the 'Allowed programs and features' list, find out 'File Transfer Program' and tick the checkbox.

After it's done, open Command Prompt and input ftp X.X.X.X, login and then ls/dir/get/put, all works now.

But I still failed to connect from File Zilla and Web Browser, hope it's useful for you.


Check your server's time syncing


Don't mess anything on your setup

Just add Outbound Rule in Windows Firewall with advance security and put port no 20.

Enjoy FTP on CLI


The problem for me was on the local PC, not the remote host. I confirmed the FTP service install on the remote host had already properly opened all the ports on the server firewall that it needed to, so that wasn't the problem. It was my local client PC that wasn't playing along. So,

  1. I opened Windows Defender Firewall.
  2. Then I clicked the link on the left, "Allow an app or feature through Windows Defender Firewall":

enter image description here

  1. I scrolled down to File Transfer Program and checked the boxes for Domain, Private, and Public:

enter image description here

This finally fixed this for me! When I went to retry an LS command, the response was instantaneous and no more hangups.

  • I had the same problem and was resolved by using the aproach suggested by 'ShieldOfSalvation' above Thanks Jul 1, 2021 at 14:40

I just enabled IIS FTP server on Windows 11 and saw this exact same issue from a client PC. This site was the top hit from my internet searches looking for a solution. Never did find the answer, so I'm posting the answer here:

The fix turned out to be on the client PC, it's also a Windows 11 box on the same subnet. Apparently I had to "Allow an app through firewall" on that machine.

I wasted hours attempting to change the FTP server to work in passive mode.

  • This is exactly what I had to do almost 10 years ago. Glad to see things haven't changed, lol.
    – D3vtr0n
    Jan 6, 2022 at 17:24

I've encountered the same issue as the OP

200 PORT command successful.
150 Opening ASCII mode data connection.
425 Cannot open data connection.

I encountered the above problem when I tried to use passive mode on the command line in Windows.
I found the information I wanted by searching the materials:

IE usually uses passive mode, while the command line utility (ftp command) always uses active mode.

I tried my previous operation in IE and it worked.Problem solved

materials link:https://forums.iis.net/t/1207342.aspx?150+Opening+ASCII+mode+data+connection+for+file+list+425+Can+t+open+data+connection+


In most of the case I found, it was firewall blocking the connection. As stated by @shieldofsalvation, it need's to allow through firewall. But the default list may not contains the "File Transfer Program" option.

To add this in the list click, Allow another app... > Browse... > Select ftp.exe file from the System32 folder > click Add, then it'll show up in the list.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .