IIS FTP not working with non-default ports

I can't seem to get IIS FTP to work with a non-default FTP port.

I can successfully connect to my FTP server and login, but once I type "ls," to list the contents of the directory, I get the following:

500 'EPSV': command not understood
227 Entering Passive Mode (192,168,1,100,#,#).

and after a while (at least one minute), I get the following:

500 Invalid PORT Command.
425 Can't open data connection.

I've run the adsutil.vbs script with the /MSFTPSVC/PassivePortRange script and specified port "5555," along with restarting FTP Publishing Service and forwarding that port on the router, but the issue persists.

I was able to successfully get the same configuration to work on FileZilla server, but I'd prefer use IIS for my FTP solution in my lab. I was also able to get this to work with the default FTP ports.

The only difference in configuration between FileZilla and IIS (beside FTP port numbers) is that on FileZilla, I can specify how I want to send the external IP address to the client. I did a bit of research and saw one user mention on a forum that IIS doesn't work that great behind NAT, and that there really is no work around to get IIS to push the external IP address out to the client. I also directly attached the server to the Internet :-X and was able to connect and list the directory contents without any issues.

My question is, is it true that I can't tell IIS what IP address to push out to the client on passive mode? If not, how can I get this to work?

thanks for your help

I'm running Windows Server 2003 behind a NAT/Firewall router. Ports 5554 and passive 5555

PS: Besides FileZilla Server and IIS, what other FTP server software is used in businesses?

Interesting KiLLaBeE,

I'm not sure here why passive mode needs to push out (to the client) the external IP of the server since the client already knows that IP. Am I out of scope here?

Any way, it Smells like a firewall config problem. But since FileZilla works (assuming it does with ports 5554 and 5555). Then this adds some confusion. What I know about passive mode is that the CLIENT initiates two connections to the server. The first connection is from client to server on port 5555 (in your case). The second is from client to server on a RANDOM port that was chosen by the server it self (given to the client during the first connection). Ofcourse this random port has to be open on your firewall/router. This guide ( www.slacksite.com/other/ftp.html ) describes this issue well.

You already did the adsutil.vbs set /MSFTPSVC/PassivePortRange thing which gives IIS a pool of ports to choose from. But may be you have to give it a port range away from the 5555. Say 5600-5700. The only thing that remains is that you have to open this SAME range in your router/firewall.

Now how did FileZilla work?!! I have no idea, but I'm guessing (just guessing) that FileZilla uses a passive port range that coincidentally included your 5554 which you have already opened.

Hope some thing here helps.

S0lo,
There's surely more to FTP than what's typically explained. That link cleared things up a lot, thanks!

Keeping in mind that I was using the built-in, command-line FTP utility on a Mac, I think the reason why I wasn't having any success was either because the FTP server was sending the FTP client the server's internal, private/non-routable IP address (I'll try to explain in a bit why this is important) or because at times the FTP client was possibly dropping down to Active Mode from its Passive Mode default (possibly because the Passive Mode port I had specified with the script had maxed out its allowed connections because I interrupted the connection due to the delay, which resulted in the FTP client failing to connect with Passive Mode, and dropping to Active Mode).

Noting that I realy didn't change any major configurations on the FTP server, I retested by using FileZilla client, which in contrast to the built-in, command-line FTP client, has a specific option to force the use of the server's external IP address in case the server provides its internal IP address instead (which I think is the default functionality). After connecting to the FTP server and running "ls," all the contents of the directory showed up!

In a brief summary, Passive Mode FTP works as follows:
After the FTP client tells the FTP server that it wants to operate in Passive Mode, the FTP server tells the FTP client how to connect to its Passive Mode port by giving the client its IP address and port number. being that the built-in, command-line FTP utility is basic and "dumb," it doesn't know that its being told a private/non-routable IP address, so it tries to connect to a non-routable IP address only to fail, which explains why there was always a delay on this part:

227 Entering Passive Mode (192,168,1,100,#,#).

I bet if I setup a host with that IP address on my secondary network (that I'm using to test) and sniffed its traffic, I'd see FTP requests.

The FileZilla client, being more advanced and "intelligent," knows the difference between a private/non-routable IP address, so when it receives the server's non-routable address, it used its external IP address instead:

Command: PASV
Response: 227 Entering Passive Mode (192,168,1,100,#,#)
Status: Server sent passive reply with unroutable address. Using server address instead.

If the FTP client ever did drop down to Active Mode, the reason why I think the connection failed was because the network I was connected to, had a firewall that was blocking whatever port the server was trying to initiate a connection to with the client.

In conclusion, as long as users' FTP clients are "smart" and can differentiate between a routable and non-routable IP address, they should be able to connect (since with Windows Server 2003 IIS, the server will send out its internal IP address instead of its external). This changes with Windows Server 2008, because you can specify the external IP address .....maybe this is reason enough for me to buy a new server

Aha, so it's the FileZilla CLIENT that was able to differentiate between a private IP and the external routable IP, Not the FileZilla SERVER that was sending the external IP. I was under the impression that you used FileZilla server and used only command line FTP as a client. So was wondering how the FileZilla SERVER knew the external IP although the server was behind NAT!!

Any way, your explanation is well described and reasoned. Yes, I have sniffed a passive FTP connection and it indeed sends both the random port and server's IP. But still that doesn't answer why would passive FTP actually need to send any IP at all, since any IP packet has a source and destination already. And since the client is positioned after the NAT, it will always get the EXTERNAL IPs as the source address in the incoming packets from the server!!

hmmm, Forget all the above, I might be missing some thing. But if that is the case, then how did the default ports 21,20 actually work with IIS since the issue here is NOT about ports but about the private and external IP?? In other words, the dumb FTP client should NOT work regardless of the ports being used.

Aha, so it's the FileZilla CLIENT that was able to differentiate between a private IP and the external routable IP, Not the FileZilla SERVER that was sending the external IP.

On my latest test, the FTP server was running IIS FTP, and IIS wasn't sending the external IP (the default design). The FTP client was FileZilla client. When the FileZilla client received the non-routable IP address, it refused it and instead used the external IP address (which is always specified when you want to initially initiate an FTP connection). Note that FileZilla server DOES have a feature that lets you specify how it will send the external IP address (IIS FTP doesn't have this feature):

wiki.filezilla-project.org/wiki/images/2...settings_passive.png

But still that doesn't answer why would passive FTP actually need to send any IP at all, since any IP packet has a source and destination already. And since the client is positioned after the NAT, it will always get the EXTERNAL IPs as the source address in the incoming packets from the server!!

I wonder this too....why doesn't the dumb-FTP client just use the same hostname/IP address specified in the beginning when connecting to the Passive port? Dunno...maybe the answer lies in the history and initial design of FTP (documented in its RFC)?

But if that is the case, then how did the default ports 21,20 actually work with IIS since the issue here is NOT about ports but about the private and external IP?? In other words, the dumb FTP client should NOT work regardless of the ports being used.

I'd have to test this out some more. When I was first setting up FTP on IIS, I didn't know much about the different modes and the network later of it all, so it might have been something I overlooked or worked as I was working to isolate the issue. Or maybe FTP just works different when using default ports? Naw, that doesn't make sense.

Note that FileZilla server DOES have a feature that lets you specify how it will send the external IP address (IIS FTP doesn't have this feature):

wiki.filezilla-project.org/wiki/images/2...settings_passive.png

Well thats impressive. Using a php script on their own servers to get the IP

I'd have to test this out some more. When I was first setting up FTP on IIS, I didn't know much about the different modes and the network later of it all, so it might have been something I overlooked or worked as I was working to isolate the issue. Or maybe FTP just works different when using default ports? Naw, that doesn't make sense.

Could be a double sided problem. I'd stick with FileZilla client while testing.

PS: Besides FileZilla Server and IIS, what other FTP server software is used in businesses?

Almost forgot that question, I personally use zFTP server www.zftpserver.com Supports both secure and usual FTP. Free and has a remote GUI.