FTP Client is blocked by Windows Firewall

[nate]

In our application we use the Internet Toolkit FTP VIs to send data to RT controllers from the host PC.  This works without any issues.  We have recently added the ability for the host PC to ftp data to another PC.  When I try to FTP to the second PC, I get error 66.  The second PC's firewall is disabled.  The only way I can ftp the data to the second PC is to disable the firewall on the host PC. 

So I guess my question is: Why does FTP work to RT controllers from the host PC, but not to other PC's?

I have unblocked our .exe in the firewall exceptions on the host PC. 

Any ideas would be much appreciated.

[Hillary_C_E]

Hi Nate,

You might want to check this KnowledgeBases here. They might point you in the right direction.

[nate]

Thanks for the references to the error code 66.  However, there is no issues when I am using the TCP VIs to communicate.  I only get the error when I use the FTP VI which I know uses the TCP VIs.  Weird!  I think that it may be realated to how FTP opens a secondary port that has not been explicity defined.  My guess is that Windows Firewall is blocking dynamic ports. 

[Hillary_C_E]

Nate,

This KB has details of which ports to allow on your Firewall. Maybe this will help clear up your connection problem.

[nate]

Yea, I had already checked that one out.  I have added all of those ports, but it still does not help.

[Hillary_C_E]

Hi Nate,

Here is another try. This KB talks about Windows Firewall and Networking. Let us know!

[altenbach]

FTP is a fancy protocol that uses secondary connections on "relatively" arbitrary ports for the data connection. The control connection is on port 21. There are also two modes, active (PORT) mode and passive and some work better under some conditions than the other. They differ in the direction in which the data connection is established.

Stateful firewalls are supposed to listen to the control connection for PORT and PASV commands and open the secondary ports for the data connection automatically. In additions, you should be able to give certain executables full access on any server ports they use. Since this is now application based and not port based, there should be no problem. It seems you tried that, though).

Have you tried manual ftp (e.g. via commandline or internet explorer)? Does that work?

(I don't have the internet toolkit so I don't know how much control you have over ftp modes.)

What is your network topology? e.g. is there a router in-between that does NAT? Most newer models should have full ftp alg support, but some ancients ones have incomplete implementation. How about a corporate firewall? Or are all sides on the same subnet?

If you're up to it, run a packet sniffer to see what's going on in detail. Try wireshark. (www.wireshark.org)

Message Edited by altenbach on 03-20-2008 10:29 AM

[nate]

Yea, I have the application unblocked.  It seems that LabVIEW and Windows Firewall do not like having dynamic ports in the application.  I'm guess that it is Windows more then LabVIEW that is causing the problems.  I put a probe on which port the ftp server was telling the client to open.  (Passive Mode)  It constantly changes with ISS on the host.  I tried to limit the Passive ports, but apparently there is no way to do that in XP, or at least all of the examples I've found are for Server 2003. 

I think at this point I have given up on FTP and am going to use a http web-service to get around the issue.  At least doing it this way, I know what ports are going to be used.