Which port number to use for FTP on IIS 7

Question

Following these instructions I managed to configure my FTP server for SSL on a windows server 2008 (IIS 7) while enabling Require SSL connections. However I'm not able to connect to the FTP server over SSL.

Troubleshooting done
-disabled firewall on server
-did nmap to the server which reported the below ports:

PORT      STATE SERVICE
21/tcp    open  ftp
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
443/tcp   open  https
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
1433/tcp  open  ms-sql-s
1723/tcp  open  pptp
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-term-serv
49152/tcp open  unknown
49153/tcp open  unknown
49154/tcp open  unknown
49155/tcp open  unknown
49157/tcp open  unknown
49158/tcp open  unknown
49159/tcp open  unknown

-based on this list of TCP port I was expecting to see either FTPS (990) or SFTP (22) opened. If I go to the FTP Bindings... settings, the only one list is fto (21) and there aren't any other FTP-related choices I can add. If I try to add HTTPS

-tried filezilla as a client and did following tests over port 21:
FTP mode -> fails with Response: 534 Policy requires SSL.
SFTP mode -> client happy after receiving Response: 220 Microsoft FTP service
FTPS mode -> client sending what looks like a client hello, fails with Response: 451 The parameter is incorrect.

Q: How can I troubleshoot this issue further (ultimate goal is to be able to force client of secured FTP)?

Additional troubleshooting

I'm really stuck at this point. I've tried every protocol Filezilla is offering me (FTPS, SFTP, FTPES): either Filezilla starts talking clear-text FTP and IIS returns Response: 534 Policy requires SSL, or it tries to initiate a secure connection and I get responses such as Response: 451 The parameter is incorrect or Response: 431 Failed to setup secure session.

I'm sniffing traffic with wireshark and I can see that filezilla is properly using the port I'm setting. I've added several ports to the FTP binding on IIS (e.g. 21,22,990..., TCP-handshake is properly established in every case) and I get the same behaviour whatever I try.

I also had a look at the FTP logs in c:\inetpub\logs\LogFiles and all I get are useless messages such as ControlChannelOpened, ControlChannelClosed, AUTH TLS, AUTH SSL which don't help with understanding why things are actually failing.

Q: How can I troubleshoot this further (is there a debug mode for the ISS FTP) ?

Answer 1

Your test worked. What you are setting up is actually FTPS, or FTP-Secure, and Filezilla noted this with a successful 220 response in your test. Despite the similar name, SFTP is a totally different animal, which transmits files over an SSH (Linux standard) connection.

Ports are agnostic, that is, they don't particularly care if the traffic you send through is encrypted or not, and they only require that the same port is being used for both the sender (the server) and the receiver (the client) of traffic. So, if you know that you will only send your traffic over port 21, just remember that the server requires an SSL connection.

If you do not control the client, and which ports they are allowed to connect to, you should change your IIS FTP port from the default of 21 to the industry standard 990. Changing the port in IIS is quite simple, in step 4 of the tutorial that you used, just change the default port of 21, as seen in the image below, to the FTPS port of 990.

Remember to reset your firewall to port 990 as well, and to restart your IIS server for the changes to take effect.

UPDATED (Now with Filezilla client instructions)

I think that we may be going a bit haywire with figuring out the problem, so rather than changing more settings and possibly creating more issues, I created a test server using localhost on my Windows 7 laptop, and connected to it with Filezilla. Because you showed me your tutorial on creating an FTP site, and you were able to create a non-secured connection without any problems, I am going to gloss over that and concentrate on the Filezilla session, where the problem has a better chance of occurring.

First, I set up my default FTP site, called "Test." Remember, I am running Windows 7, so even though the steps are the same, they may look different than your server. As I said before, the port is not important, the only requirement is that the server and client use the same one. But, to keep with convention, I will continue to use port 990.

I tell IIS to require an SSL connection (the default allow is okay, but we want to force clients to use SSL, so we make is clear that is what we want). And, because we are testing, we will use the default IIS Express Development Certificate as in the screenshot below. In real life, you should get an SSL certificate from a reputable source, but if you do not, you probably will be able to connect, but the client will give a warning. (disclosure: I am not terribly familiar with securing sites with SSL, so I would confirm your settings before releasing your site to the public)

Once the site is started, confirm that you are connecting to your server using the prefix ftps://. This is how the FTP client knows you need to create a secure connection, and why I keep repeating that the port number is irrelevant. Continue to use your username and password as you've set it up (I am using anonymous and no password), and insert your port number at the end, though if you are using the FTPS default of 990, Filezilla tends to erase it when you connect. My log is shown in the screenshot below.

The last gotcha that comes to mind is this: be sure that the clock is set correctly between the server and the client. It can be a few hours off, but SSL uses the timestamp to validate the security, and often a computer is set to the default California timezone, and the user naively resets the time to the local time without correcting the timezone. This would create an enormous variation in the times, and may account for odd SSL errors.

Let me know how your logs look, and I'll see if I can help you from there!