I have two machines behind the same firewall/router - one is a Windows 7 workstation and the other is a Windows 2003 server. The problem is with outgoing FTP access using the FileZilla FTP client (note: not server) on the Windows 2003 server.

Using FileZilla client on the Win7 workstation I am able to connect to an external FTP site using passive mode without issue. However, when I try the same thing from FileZilla client on the Windows 2003 server it hangs when attempting to retrieve the directory list. The log output is as follows:

Status: Resolving address of xxxxx.com
Status: Connecting to xxx.xxx.xxx.xxx:21...
Status: Connection established, waiting for welcome message...
Response:   220---------- Welcome to ...
Command:    USER ...
Response:   331 User ... OK. Password required
Command:    PASS *************
Response:   230 OK. Current directory is /
Command:    SYST
Response:   215 UNIX Type: L8
Command:    FEAT
Response:   211-Extensions supported:
Response:    EPRT
Response:    IDLE
Response:    MDTM
Response:    SIZE
Response:    REST STREAM
Response:    MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
Response:    MLSD
Response:    ESTP
Response:    PASV
Response:    EPSV
Response:    SPSV
Response:   211 End.
Status: Connected
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is your current location
Command:    TYPE I
Response:   200 TYPE is now 8-bit binary
Command:    PASV
Response:   227 Entering Passive Mode (xxx,xxx,xxx,xxx,164,24)
Command:    MLSD
Error:  Connection timed out
Error:  Failed to retrieve directory listing

As you can see, a connection over port 21 is established and a request to enter passive mode results in port 42008 being established. But the attempt to retrieve data over that port fails. This works flawlessly on the Win7 machine.

I understand passive vs. active mode fairly well. It appears in this case that Windows Server 2003 is blocking traffic on certain ports. The Windows Firewall service isn't running on this device so I can eliminate that as the culprit. I would appreciate any other suggestions on how to track this down.

UPDATE Turns out that it's specific to one FTP site. I can connect to another site using passive mode just fine. The difference appears to be port number. The passive port number on the site I can reach is 4693. The passive port number on the site that I can't reach is over 42000. Does this have any bearing on the situation?

UPDATE I wrote a little socket server program running on the Win7 workstation that listened on port 50000, then from the Windows 2003 box I ran telnet to the address/port of the workstation and...it worked. So within the LAN Windows 2003 is allowing the traffic. Somehow it's not allowing the traffic out over the Internet. Baffling.

UPDATE Problem was with FTP server. See answer below.

  • Typically, I'd blame the server for not opening the passive ports, but it looks like you've covered that angle. In your shoes, I'd install wireshark and watch traffic to the server. It might give you a better idea of what the client is attempting to do that's different from the Win 7 box (if anything) Apr 8, 2011 at 16:51
  • Thanks SmallClanger. I'm familiar with WireShark, although hardly expert, so I didn't think of that. Will give it a try.
    – Bob Mc
    Apr 8, 2011 at 17:06
  • @SmallClanger - Well, I tried WireShark. I can see the packet that sends the MLSD command over the passive port, but it doesn't get a response. It just times out. When I do this from a workstation, no problem. To another site with passive port < 5000, no problem. So WireShark just reports what I already know. I just can't figure out why the high ports are blocked.
    – Bob Mc
    Apr 9, 2011 at 16:17

2 Answers 2


On Windows Server 2003 and Windows XP the default range of ephemeral ports used by client applications is from 1025 through 5000. Under certain conditions it is possible that the available ports in the default range will be exhausted.

netstat -n or netstat -b to see active connections

Increase the upper range of ephemeral ports that are dynamically allocated to client TCP/IP socket connections.

  1. Start Registry Editor.
  2. Browse to, and then click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  3. On the Edit menu, click New, DWORD Value, and then add the following registry value to increase the number of ephemeral ports that can by dynamically allocated to clients: Value name MaxUserPort Value data
  4. Close Registry Editor.

Note: You must restart your computer for this change to take effect.

Note: Increasing the range of ephemeral ports used for client TCP/IP connections consumes Windows kernel memory. Do not increase the upper limit for this setting to a value higher than is required to accommodate client application socket connections so as to minimize unnecessary consumption of Windows kernel memory.

  • Thanks alexm. I had already ran across and tried this KB article (support.microsoft.com/kb/196271) that outlined the fix you noted. I added the registry key, but it doesn't appear to correct the issue. Still, this appears to be exactly the cause of the problem. I'll continue to investigate.
    – Bob Mc
    Apr 9, 2011 at 3:31
  • Still no joy. Is it possible that this setting only applies to Windows 2003 server R2?
    – Bob Mc
    May 2, 2011 at 11:52

So now it appears that this was a problem with the FTP server (PureFTPd). The admin tweaked something and restarted the server and, voilá, everything started working. I have to stop assuming the problem is with my code/configuration all the time.

Thanks to everyone that contributed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.