This article taken from
http://www.mail-archive.com/[email protected]/msg00567.html
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.
