Why does FTP passive mode require a port range as opposed to only one port?
I'm struggling to come to grasp with why all FTP servers requires the use of a port range for passive mode data channels as opposed to only using one data port for all incoming data channel connections.
FTP servers handle many simultaneously connected clients on port 21. Web servers handle many simultaneously connected clients on port 80. Etc..
Then why can't an FTP server use only one data channel port for all incoming passive data connections (and still be able to handle many simultaneously connected clients on that port, say port 1024)?
Or can it?
I am interested in knowing the technical details for why this is not possible or not recommended.
Solution 1:
a clear and technical explanation with regards to the multiple concurrent FTP sessions issue when locking the data port to only one port is what I am most interested in knowing in depth. When can it work, when will it not work, why it may not be recommended, etc.
This will be a wild guess, as I haven't tested it, you should try it for yourself and see if there are some other problems I might have missed.
I suppose you could limit the passive port range to one single port. In fact you can see in this question that small port ranges are used in practice. Theoretically, to support multiple concurrent connections you only need the 4 values: local IP, local port, remote IP, remote port to be unique. This is how you discern between different connections.
If you lock down the port on your server to one single value, then the only variable left is the port used by the client. This is not a problem, as long as the client has a large enough pool of free ephemeral ports to choose from. Unless it's doing some heavy NAT, you don't have to worry about this. Now, be warned this will be purely theoretical stuff: if you used multiple ports on your server, you could multiply the number of hypothetical concurrent connections by enabling number of ports in range
connections per one port client-side. But it won't happen in practice, as I doubt there's any implementation of an FTP client that would support this (because it doesn't make much sense). Plus if the client has to share his ephemeral ports in this way and can't just open a new one, then he has much more severe problems to deal with. So, from this perspective you should be totally safe using a single port.
Let's think why a single port may not be sufficient.
First of all, I could come up with a situation where a really buggy FTP server implementation uses solely the local port number as a way to identify the client data transfer. Once again, I don't think any decent FTPd would do that.
The real problem (yes, you can disregard all above as a major digression ;-)) is that passive port range is in a non-privileged range.
This means that your selected port number is not reserved per se, and in fact any user process (doesn't need root privileges) can grab it before your FTP server does. If you have an abundant pool of ports to select from, you just grab a random free one. If you're bound to use the only one and it's already used, you won't be able to handle the transfers properly.
Sorry, if the answer seems a bit too speculative. To be honest, I tried hard to find a reason why you shouldn't use a single port and, apart from the last bit, I couldn't think of any hard evidence against it. Nevertheless, an interesting and challenging question you pose.
Solution 2:
FTP relies on two separate connections, one for the control or command stream, and one for passing the data files and other information such as directory listings. The control stream is carried over a traditional TCP connection. The client binds to a high unprivileged port and sends a connection request to the FTP server, which is bound to port 21. This connection is used to pass commands.
In Port or active mode, the client tells th server which secondary, unprivileged port it will listen on. The server then initiates the data connection from port 20 to the unprivileged port the client specified.
Passive mode, a newer mechanism, is the default when the client is a web browser. Instead of being tied to port 20, the server tells the client which high port to use for data transfer. The data is then transmitted over unprivileged ports between both client and server.
For more details, please see:
https://www.rfc-editor.org/rfc/rfc959
EDIT
As to locking the server to a particular single port, it may be possible in some servers. For example in vsftpd, you have the following configuration options.
pasv_max_port
The maximum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling.
Default: 0 (use any port)
pasv_min_port
The minimum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling.
Default: 0 (use any port)
If you set both ports to the same, e.g. pasv_max_port=12345, pasv_min_port=12345, you may be able to get what you are after. I suspect this will limit the number of concurrent FTP sessions you're server will support. Please test to be sure.