Here's a little snippet about how the ftp connection works:
All modern FTP clients send a PORT or PASV command before every file transfer.
There is no way to accomplish a limited range of ports for the server to listen on because it is Winsock's responsibility to assign unused random ports to new listen sockets. It is not the responsibility of the FTP client program.
To clarify, when an FTP client begins a file transfer in active mode, a random port on the client connects to port 21 on the server to establish the command connection. Then the client opens a new socket on a random port in listen mode and transmits a PORT command to the server through the command connection, which specifies the client's IP address and the random port it has chosen. Then a random port on the server connects to the port that the client specified in the PORT command, and the file is transferred through this connection.
When an FTP client begins a file transfer in passive mode, it establishes the command connection in exactly the same way and sends a PASV command to the server through this connection. The server then opens a random port in listen mode and reports its IP and the port back to the client. The client connects a random port to the port that the server specified, and the file is transferred through this connection.
The problem with the whole FTP schema now that NAT routers are in such prevalent use is that there is no guarantee of which port will be used for the data connection. If the server is behind a firewall, the client's only choice is to use active mode, in which the data connection is made from the server to the client. If the client is behind a firewall, its only choice is to use passive mode, in which the data connection is made from the client to the server. If both the client and the server are behind firewalls, then there is absolutely no way for a data connection to be established, because an incoming connection on a random port cannot be accepted in either direction. This is not a mistake, per se; the firewalls are simply doing their job.
Some more advanced routers have a kind of IP translation for active mode FTP clients. The way this works is that the router monitors the commands going through an FTP command connection. When a client that is behind the firewall issues a PORT command over an FTP command connection, it of course specifies its own internal IP address because it is unaware of the router's external IP. The router stores the client's IP and port and modifies the PORT command being sent so that it shows the router's external IP and a new random port that the router opens. Then when a connection comes in from the FTP server to the router's open port, the router forwards that connection to the IP and port that it had stored for the client. This translation works very well on most routers. The only requirement is that the FTP server being used not be behind a firewall.
Unfortunately, no consumer NAT routers I know of perform this translation for FTP servers running on computers behind their firewall. They will only do it for FTP clients. The only real solution to the FTP problem right now is to have a separate external IP that your FTP server is connected to without a firewall. This will ensure that all clients can connect and transfer files in both active and passive modes. Or you can use an SSH "tunnel" to encrypt the whole transaction and run everything through the SSH port. However anonymous access is not possible this way and the client machines need to have a port redirection program installed and configured.
)? note that my lan is behind a hardware firewall (in my smc router). one more thing, any server i use needs to have a configurable outbound port so that i can have it ask the client to connect to my external ip address rather than the internal ip address of the host on my lan (if anybody knows how to do this with iis let me know, haven't tried it yet but i assume it's in there somewhere!).
Facebook
Twitter
Instagram