We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


IIS 7.5 FTPS error Failed to retrieve directory listing

Medium Priority
Last Modified: 2013-12-02
Server: Win Server 2008 x64 SP2, IIS 7.5

I have tried several FTP clients including FileZilla, GoFTP, Core FTP

I get the same result with all of them:

Status:      Resolving address of ***********
Status:      Connecting to (my correct external IP shows here):21...
Status:      Connection established, waiting for welcome message...
Response:      220 Microsoft FTP Service
Command:      AUTH TLS
Response:      234 AUTH command ok. Expecting TLS Negotiation.
Status:      Initializing TLS...
Status:      Verifying certificate...
Command:      USER ztouba
Status:      TLS/SSL connection established.
Response:      331 Password required for ztouba.
Command:      PASS ***********
Response:      230 User logged in.
Command:      SYST
Response:      215 Windows_NT
Command:      FEAT
Response:      211-Extended features supported:
Response:       LANG EN*
Response:       UTF8
Response:       AUTH TLS;TLS-C;SSL;TLS-P;
Response:       PBSZ
Response:       PROT C;P;
Response:       CCC
Response:       HOST
Response:       SIZE
Response:       MDTM
Response:       REST STREAM
Response:      211 END
Command:      OPTS UTF8 ON
Response:      200 OPTS UTF8 command successful - UTF8 encoding now ON.
Command:      PBSZ 0
Response:      200 PBSZ command successful.
Command:      PROT P
Response:      200 PROT command successful.
Status:      Connected
Status:      Retrieving directory listing...
Command:      PWD
Response:      257 "/" is current directory.
Command:      TYPE I
Response:      200 Type set to I.
Command:      PASV
Response:      227 Entering Passive Mode (my correct external IP shows here,252,186).
Command:      LIST
Response:      150 Opening BINARY mode data connection.
Error:      Connection timed out
Error:      Failed to retrieve directory listing

Settings (Set at both the server(top) level and on the FTP within the "Sites" folder):

FTP Firewall Support:
Data Channel Port Range: 51701-51710
External IP Address of Firewall: (my correct external IP address)

FTP SSL Settings:
SSL Certificate: a standard SSL cert from godaddy (not EV)
SSL Policy: Custom: Control Channel: "Require only for credentials", Data Channel: "Allow"

FTP Authentication:
Basic Authentication: Enabled

FTP Authorization Rules:
Allow: All Users, Permissions: Read + Write

Type: FTP, Host Name (blank), Port 21, IP Address (*)
Type: FTP, Host Name (blank), Port 990, IP Address (*)

In my Router/Firewall:
Ports allowed (and NATed): TCP: 21, 20, 990, 989, 51701-51710

Whether I connect on port 21 or 990 I get the same result. There's no difference in the log aside from it saying "external IP address:21" to saying "external IP address:990"
The only thing I've noticed is that towards the end where it says:
"Response:      227 Entering Passive Mode (my correct external IP shows here,252,186)."
the two numbers that show after my external IP are different each time.
Watch Question

In passive, the client make both connections to the server and could be the problem.  Can you try taking out the PASV command?  

Here's some info on it:


The two numbers after the IP are the port number used for the data channel.  Here is how to decode it:
252 = FC (hex)
186 = BA (hex)
FCBA = 64698 (decimal)

So, in this example, it was trying to use port 64698 as the data port but that was blocked by something, probably the firewall.


developedtester: I have tried setting the clients to "Active" instead of "Passive" and it still won't connect.

AlexPace: Okay that would be a problem because I don't have port 64698 open so of course it couldn't connect. By specifying the data port range in IIS isn't it supposed to only give those ports as options to the client trying to connect? After the user auth finishes on the control port (21 or 990) isn't it then supposed to essentially let the client know that the ports it's listening on are: 51701-51710?
I think the "passive" causes the client to decide what the upper port is w/o any help from the server.

In Active mode the client sends the PORT command which specifies the data channel port that the server is supposed to connect back to the client on.

In Passive mode the client sends the PASV command and the server responds with the data channel port that the client is supposed to connect back to the server on.

If you specified a passive range but it isn't using that passive range... well thats a problem in the server software.


Okay... well I did set the Data Channel Port Range: 51701-51710 (and it says right in the description that it's used for Passive connections). I've setup many FTP servers before and never had an issue but this is my first time setting up a FTP over SSL. Any ideas where to start troubleshooting?
Can you try the settings the fire wall as in this link?


near the bottom is:
Using Windows Firewall with secure FTP over SSL (FTPS) traffic

The note right before it has:
...the SSL negotiation will most likely fail because the Windows Firewall filter for stateful FTP inspection will not be able to parse encrypted data. (Some 3rd-party firewall filters recognize the beginning of SSL negotiation, e.g. AUTH SSL or AUTH TLS commands, and return an error to prevent SSL negotiation from starting.)


There is no firewall. The windows firewall is completely shut off.
Can you try active mode?  I that previous link it talks about some issues with passive:


Does just ftp work?  (without the ssh)


... its not SFTP (FTP over SSH), it's FTPS (FTP over SSL) which is an entirely different port/protocol. It does not work in active mode or passive mode. I have tried both. Yes just FTP without the SSL works.

It is interesting that FTP without SSL works because the SSL is negotiated at the very beginning before you even pass the username and password for authentication.  In the log you posted not only were you able to negotiate SSL and pass authentication, you also got a successful response to the PROT command specifying private mode protection on the data channel.  In the log you posted the connection died right after the server replied to the PASV command and offered your client a connection on port 64698 which is strong evidence that your client was unable to open the connection to that port.
Sorry, I meant "without the SSL".  If ftp works, then it must be some security setting.  As you said, there's no firewall on the server, but what about the router...it has it's own settings.  There must be a setting there that causing issues.  Do you have traffic restricted for SSL or TCL?
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview


Answer was explained well. Unfortunately the answer to my question is that it cannot be done without setting up the server in a DMZ. As mentioned in the solution, since it can't tell its FTP traffic it wont open the ports for it.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.