I have an application that runs as a service and contains an FTP client. It needs to connect to an FTP server that only supports Active FTP. When I attempt to get a list of files or download a file, Windows Firewall is dropping the incoming connection from the FTP server. (I don't believe we had this problem in Windows XP or Windows Vista.)

Active FTP is the protocol that requires the the server to open a connection to the client on a port that the client specified. (http://slacksite.com/other/ftp.html)

I know I could open up a large port range in Windows Firewall and force my FTP client to only use those ports, but I would have guessed that Windows Firewall would support Active FTP natively.

Is there some setting that needs to be made in order to have Windows Firewall automatically detect Active FTP and open up the necessary ports as needed? Can I change that setting programmatically?


  • probably something like technet.microsoft.com/en-us/library/cc739791(WS.10).aspx though to keep this less serverfault and a bit more stackoverflow, curious why you do not use passive FTP. – Andrew Y Oct 27 '09 at 22:33
  • We had an issue very recently with Windows 2003 not accepting active FTP through our firewall, though the firewall in that instance was external to Windows. We opted to just use passive FTP. – Eric J. Oct 27 '09 at 23:10
  • Our application needs to connect to a third party service that does not permit Passive FTP -- it only allows Active FTP. Crazy, I know, but they say they will not support passive FTP anytime soon. And you're right, I should probably ask on ServerFault as well, but I was thinking that whatever the fix is we would need to do it programmatically as part of our application install or update. – Eli Oct 27 '09 at 23:17
  • I know this seems like pass-the-buck, but this is actually better suited to superuser.com – Izzy Oct 27 '09 at 23:58
  • On an internet where NAT is almost everywhere, how can they be relying on active FTP? If possible, switch to a different service, or hound the third party service until they start supporting something sensible like scp/sftp. – Grant Jun 22 '12 at 14:14

Here's the thing: Whether in Active or Passive mode, the server always uses port 20 on it's side for the data connection and connects to the client on whatever port the client specified when it issued the FTP PORT command.

After looking at the Windows 7 firewall it looks like you can create a custom inbound rule that allows connections to any local port from a specific remote port (20) for a given protocol type (TCP). You can also specify the local and remote ip addresses that this rule applies to.

I have to admit that I've never monkeyed around with the Windows firewall but it looks to me like it might work for you.

| improve this answer | |
  • I have these rules implemented (the were already there), but I still can't connect. I think it is a network issue for me because I can send commands fine, but the data channel is trying to communicate with for some reason, instead of the external FTP server... but vote up because your answer should still be applicable. – John Bubriski Sep 16 '11 at 18:27
  • If the only rule you set is the remote port, which the remote side is completely free to choose, you are effectively opening your firewall to anyone, aren't you? – Martin Prikryl Dec 17 '19 at 19:01

Instead of adding ports to the Windows Firewall exception list, add the application you need to have access. Windows Firewall will then allow that application to bind and use whatever ports it wishes.

| improve this answer | |
  • The problem is that the server is initiating the data connection on a random port to the client. The firewall will reject unsolicited inbound connections. – Izzy Oct 28 '09 at 2:25
  • 1
    the connection is not really unsolicited. nor is the port random. The client picks the port and sends it to the server. Most non crappy firewalls that do connection tracking will see the port being sent to the server and allow the resulting connection. In the case of the windows firewall, since the client picks the port and binds the port, the application exception should allow the incoming connection. – Justin Jan 7 '10 at 4:30
  • FYI, I've tried this and it didn't work for me. I think there is something going on with my network because after trying a get command, the FTP client says PORT which is obviously a local server... not sure why it's trying to do that though. But vote up because your answer should still be applicable. Maybe our network firewall is doing something? – John Bubriski Sep 16 '11 at 18:29

Windows XP/Vista/7 all use the 'Application Layer Gateway Service' as a connection helper for Active FTP. You need to ensure that this service is started for Active FTP to work.

To start it:

  1. Click the Windows Start button
  2. Type 'services.msc' into the search bar and press Enter (the Windows Services panel will pop up)
  3. Scroll down until you find the 'Application Layer Gateway Service'
  4. Look at the 'Status' column, it should say 'Started'.
  5. If not started, double click the service name to get into its options panel.
  6. Change the 'Statup Type' drop down to say 'Automatic'
  7. Click on the button that says 'Start'
  8. Click on 'Apply'
  9. Click 'OK'
| improve this answer | |
  • Isn't this a resolution to a server side problem. His issue is that the client (his machine) wont accept the incoming connection from the server. – John Bubriski Sep 16 '11 at 18:17

Have you tried making sure that your firewall is doing stateful FTP filtering?

You can do that by opening a command prompt with admin permissions and typing:

netsh advfirewall set global StatefulFtp enable

I'd be curious if that impacted your problem at all.

| improve this answer | |
  • 1
    Can run "netsh advfirewall show global StatefulFtp" first to see the existing setting. It looks like its enabled by default. – fschwiet Oct 3 '10 at 1:38
  • Yeah, FYI, I tried this and no luck :( I'm not sure what the initial state what but it is enabled now. – John Bubriski Sep 16 '11 at 18:19
  • AFAIK, the stateful filtering does not work for active mode, just for passive. – Martin Prikryl Mar 3 '15 at 14:07

I had the problem with an FTP client on our Intranet, and didn't want to make a firewall exception for that particular program. I wanted Active FTP to "Just Work", with any client program.

I tried to enable the "Application Layer Gateway Service" (sc start ALG), and made sure that I had "statefulftp" enabled (netsh advfirewall set global statefulftp enable). I suppose these are needed in some cases, but they didn't make a difference for me.

In the end, I just opend connections from port 20 from local IPs, and Active FTP works, with any program.

netsh advfirewall firewall add rule name="FTP (active)" action=allow protocol=TCP dir=in remoteport=20 remoteip=localsubnet

Instead of remoteip=localsubnet, you could also specify a particluar IP.

| improve this answer | |

I resolved this issue looking more accurately at the top of inbound rules. Noticed there was two rules called File Transfer Program (one for TCP and another one for UDP) which was blocking "c:\windows\system32\ftp.exe" program. Disabled both and everything worked like a charm! Just my 2 cent ;-)

| improve this answer | |

Many people don't care about %SystemRoot%\system32\inetsrv\inetinfo.exe While creating the FTP server on Windows Machine.

The application must be white listed before you access the connection from your sub-net or the internet.

First you allow these ports: 80, 20, 21 for both HTTP and FTP. Then add exception for "inetinfo.exe"

| improve this answer | |

I would recommend tunneling instead. For example, running WinSSHD server on the remote server. It has UPnP and will auto open the port 22 for you. It has an accompanying client program called Tunnelier if you coming from the client side. The point here is that when you have a tunnel on port 22, then both active or passive FTP will work fine from that point forward via the tunnel. In fact, if you run WinSSHD ( or SSHD) on the remote FTP server, it has a FTP subsystem that does the same thing as the FTP server does. So, if the remote FTP server is Linux, most likely they already have the SSHD service running and so the FTP server itself is a mute point.

| improve this answer | |
  • I don't have control of the FTP server. I'm trying to connect to a third party FTP server using my own application. My own application has to automatically deal with the local machine's own Windows Firewall as this is what most customers run out of the box. – Eli May 19 '10 at 17:02
  • I know that if you app is C# or VB.net that there is an API for controlling the local windows firewall ports. Maybe that is an option for you? – djangofan May 19 '10 at 17:17

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.