Hello list, as I understand it, this is fundamentally a firewall configuration problem, not a WS_FTP problem.
FTP is always a problem for firewalls because of the dual connections. Essentially you have two choices, active mode or passive mode. 1. In active mode (the original), the client opens a connection FROM a random high port N TO the server's port 21 (the control channel), then the server opens a connection in the reverse direction FROM it's port 20 TO the client's port N+1(the data channel). (Usually, a new data channel is opened for each transfer.) This has the disadvantage that the client's firewall must allow incoming connections to a random high port number, which is rarely allowed. To get around that passive mode was invented. 2. In passive mode the client initiates both connections. The control channel is exactly the same, but after the PASV command the server sends a PORT command to the client with a random high port, and the client connects the data channel to this server port . This is much easier for the client's firewall (any firewall which is reasonably lenient about _outgoing_ connections should allow it), but makes it a lot harder at the server end (now the _server_ is the one which has to accept incoming connections to _all_ high ports, which is a humungous hole.) There are two common solutions to this: 1. First, many modern firewalls get around it completely by having a built-in FTP proxy. As soon as it sees that the packets it's passing are FTP, it proxies them instead of filtering them. In particular, it actually examines packet contents (e.g. PORT and PASV commands) and dynamically opens a new firewall hole for the port. This has the additional advantage that it takes care of port-mapped NAT as well. (Otherwise, the PORT command a machine receives will be to the real port, not the one on the NAT machine - phew, complicated!). However, if the packet payloads are encrypted (e.g. SSL), this application level proxying becomes impossible. 2. Also, a small number of FTP servers allow you to restrict the range of ports they will negotiate for a passive data channel, so you can make firewall holes just for those ports. However, so far as I can tell WS_FTP Server does not have this feature. (Something to think about adding, Ipswitch?) Thus your solutions come back to fiddling with the firewall configuration. Once again I can see two types of solutions, both made simpler if passive mode is used: 1. Sophisticated stateful firewalls can allow you to specify that once a client has successfully connected to some host on some port, it can then be allowed to make another connection between any two high ports. This is the best solution, I think. 2. If your firewall can't do that, then put the FTP server on a DMZ, make sure that absolutely nothing is listening on any high port, and open the DMZ to all incoming connections to any high port. A final consideration is that if the client end firewall rules are sufficiently fascistic about outgoing connections to random high ports, then there is not much you can do. For example I have worked for a company where _all_ outgoing connections were proxied - there was a proxy each for HTTP, SMTP, POP, and FTP, and for anything else you could wrestle with SOCKS. In such an environment FTP over SSL is simply not possible. Also I suspect the problem is close to insoluble if the firewall on _both_ ends is doing NAT. In either of these cases, you would have change to an HTTP based service instead. Cheers, Roger *************************************************************************************************************************************************************************** This email and any files transmitted with it, are confidential and is intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been scanned by AUSTAR Communications content and virus scanning applications for the presence of computer viruses. *************************************************************************************************************************************************************************** Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list.
