IIS 7.5 FTPS error Failed to retrieve directory listing

Posted on 2011-04-27
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.
Question by:ZachTouba
    LVL 16

    Expert Comment

    by:Bryan Butler
    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:
    LVL 16

    Expert Comment

    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.

    Author Comment

    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?
    LVL 16

    Expert Comment

    by:Bryan Butler
    I think the "passive" causes the client to decide what the upper port is w/o any help from the server.
    LVL 16

    Expert Comment

    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.

    Author Comment

    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?
    LVL 16

    Expert Comment

    by:Bryan Butler
    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.)

    Author Comment

    There is no firewall. The windows firewall is completely shut off.
    LVL 16

    Expert Comment

    by:Bryan Butler
    Can you try active mode?  I that previous link it talks about some issues with passive:

    Does just ftp work?  (without the ssh)

    Author Comment

    ... 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.
    LVL 16

    Expert Comment

    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.
    LVL 16

    Expert Comment

    by:Bryan Butler
    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 has it's own settings.  There must be a setting there that causing issues.  Do you have traffic restricted for SSL or TCL?
    LVL 9

    Accepted Solution

    The reason FTP works without SSL is because the firewall knows that it's FTP and automatically opens the ports up as and when required. With SSL, the Firewall cannot determine that it's FTP traffic, and therefore does not open the ports up when it's needed

    I have an SSL FTP on IIS running in a DMZ, and I can support both Passive FTP (PASV) and Active FTP (PORT).  I do this by forwarding a predefined range of ports in to my FTP server (like ports 15000-15100), and then tell my FTP server to use these ports.

    You have to specify these at the Server node - not at the FTP Site Node.


    Data Channel Port Range
    This shows my FTP Port Range for Passive Connections

    Firewall RulesThis shows my Firewall rules which will support both passive and active.

    Author Closing Comment

    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.

    Featured Post

    Highfive Gives IT Their Time Back

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    One of the typical problems I have experienced is when you have to move a web server from one hosting site to another. You normally prepare all on the new host, transfer the site, change DNS and cross your fingers hoping all will be ok on new server…
    Periodically we have to update or add SSL certificates for customers. Depending upon your hosting plan you may be responsible for the installation and/or key generation. In the wake of Heartbleed many sites were forced to re-key. We will concen…
    Hi everyone! This is Experts Exchange customer support.  This quick video will show you how to change your primary email address.  If you have any questions, then please Write a Comment below!
    This video is in connection to the article "The case of a missing mobile phone (". It will help one to understand clearly the steps to track a lost android phone.

    728 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    22 Experts available now in Live!

    Get 1:1 Help Now