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.

  • 1
    This may be of interest to you: w3.org/Protocols/rfc959 May 18, 2011 at 12:07
  • 2
    Thanks Matt. Yes, I have read most of rfc 959, but I feel I wasn't really able to get a clear answer from that to what I was wondering about. The answer from Karol Piczak is more the kind of information I was looking for.
    – Kurt
    May 18, 2011 at 17:10

6 Answers 6


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.

  • BTW, feel free to comment on missed points and inconsistencies here. Even myself, I feel as if I'm nitpicking on a simple answer - yes, you can. ;-) May 18, 2011 at 11:44
  • Thanks a lot Karol! This is spot on the kind of information I was looking for (and really hadn't found anywhere else). My main reason that I asked this question is that I want to know if it's safe to set up an FTP server in Windows Azure and lock the passive mode down to only 1 port (since Azure limits the endpoints). I have tried it, it works, and with your info I also feel safe to do it. However the only issue left is that the Azure load balancer drops the control connection after 1 minute during file transfers (because it is idle), so I'm working on a TCP tunnel with keep alive's to fix it.
    – Kurt
    May 18, 2011 at 17:01
  • 2
    I believe the real reason is that the data channel protocol has no identifying information. The server only knows which file is being transferred from which client based on the port number.
    – Monstieur
    Oct 25, 2016 at 17:57
  • 1
    Passive FTP to a single server port with NAT on the client side would be a serious problem. The client sending its source port doesn't help because the NAT router very likely changes that. Subsequently, somewhat simultanous incoming data connections from the same NATed public IP address would be ambiguous.
    – Zac67
    Jun 18, 2020 at 20:37

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:



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.

          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)

          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.

  • 1
    Thanks for your reply. However what I am interested in knowing is why, in passive mode, can't the ftp server tell all clients to use the same port for the data channel (say for example port 1024) as opposed to giving each client a random port from a specified port range? What are the technical reasons, if any, for why specifying only one single data port in the FTP server port range configuration is not possible or recommended? I would think an ftp server could handle many/lots of simultaneous connections even on only one data channel port, no?
    – Kurt
    May 17, 2011 at 23:40
  • 1
    Because FTP is the devil and needs to finally die. :D
    – user62491
    May 17, 2011 at 23:53
  • 1
    Thanks for your edit with regards to locking the server to a particular single port. I have actually thought about that method (and this is what I want to accomplish), but what I don't quite understand is why that would limit the number of concurrent FTP sessions the server can support. What exactly is it that would prevent the server from supporting multiple concurrent FTP sessions in this case? Because any FTP server obviously supports multiple concurrent connections on port 21, so why not also on port 12345, taken from your example? I will have to test this in greater depth.
    – Kurt
    May 18, 2011 at 0:34
  • It may not limit the number of concurrent connections. It really depends on how the server keeps track of the connections across multiple sessions. Give it a shot!
    – dmourati
    May 18, 2011 at 0:40
  • btw i will have to wait with marking any answer as accepted answer, because 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.
    – Kurt
    May 18, 2011 at 1:07

An FTP server might be able to match the client's Data Port connection to their Control Port connection based on the source IP alone, rather than based on the port number used.

This would break FXP (which may not be a bad thing) where the client connects to two servers (one in passive mode), then after receiving the passive server's PORT information, passes that to the active mode server as a PORT command so that active mode server connects to the passive mode server.

I suspect that many servers don't create the data socket until the client requests passive mode. In that case, if two clients requested passive mode at the same time, the sockets created would need unique port numbers.

EDIT: thought of another reason why FTP servers don't do this: the server could not tell multiple users with the same IP address apart.

  • Thanks. I guess what I don't understand is why would those data channel sockets require a unique port (on the server) if two or more clients requested passive mode at the same time? Because I'm thinking, two or more clients can obviously be connected to port 21 at the same time so why not say port 1024 (for the data channel) at the same time? I feel this may be a stupid question, but my disclaimer is that I've been awake for far too long already :)
    – Kurt
    May 17, 2011 at 23:57
  • The socket itself needs to be unique. You can create one socket listening on a port and accept as many connections as you want from that one socket, or you can create one socket per user on different ports and accept one connection from each socket. If you've designed the server to work one socket per user, then you'd essentially be rewriting everything to change it the other way around, and at the end, people on shared hosts or behind the same IP address would not be able to connect at the same time, because there'd be no way to tell their data connections apart.
    – DerfK
    May 18, 2011 at 2:27
  • Thanks. I am grateful for all the answers I have received on the subject and I think I'm starting to get a pretty good handle on it now.
    – Kurt
    May 19, 2011 at 16:11

On ports 21 or 80 (as on all well known ports), there's a set protocol, that the client uses to tell what does it want. This way the server knows what are you connecting for. On the data connection port, there's no protocol. All that the server knows – the only thing that's unique about that connection – is the port number you connect to.

If you were to connect to the same port every time, the server would not be able to tell what file are you connecting for. The port number serves as a link between a transfer request on the control connection and a data connection.

If two clients were to request a transfer at the same time, when the server accepts a connection on a single port, the server would not be able to tell what file to transfer. Of course, the server could use a client IP for the decision (actually many FTP servers do validate that the client IP matches the IP used on the control connection, for security).

But this would not work for:

  • Multiple connections from the same machine (most FTP clients do support parallel transfers/queues).
  • Connection from different machines within the same (corporate) network, as those have the same external IP.

One interesting solution is what the FTP server built into Bitvise "SSH" server does. It actually supports a single data port only. But it requires TLS/SSL encryption and TLS/SSL session reuse for the data connection. And it uses the TLS/SSL session to link the control and data connections.

See also FTP data connections reuse.


I didn't see this mentioned here, so I will throw it in. The port range assignment was meant to be a kind of security feature, where you could not monitor one port for data traffic, the data was sent on a random port in the range, which could not easily be determined. Security through obscurity.

  • 2
    Do you have any reference for this claim? Sep 17, 2018 at 20:01

Sounds like you already know about control ports and data ports so I'll cut right to the chase. Control ports are burst communication by nature, just like port 80 for websites. they can handle many different requests (not simultaneously, but darn close since they're so quick to complete). data ports on the other hand are where the magic happens with FTP. If you limit yourself to a single data port, only one data transfer happens at a time. consider a large file transfer. With a single data port open, no other data can move until the transfer's complete. This means that while transferring, a second user won't even be able to list the directory contents of the ftp folder. Sure they'll be able to log in successfully, but their behavior will be the same as if the data ports were not open at all. If you're ok with this, a single port will work great for you. Keep in mind that some ftp clients (I can think of 1 right off the bat) by default set up multiple connections within a single session for downloading. So for this client, in a single port scenario, consider a batch transfer of 1 large file and 4 small files.

The client initiates the transfer for the first large file, all hunky dory. Then, while that transfer's going, it starts a second file. No dice. Then the third, also zilch (technical term). In the end, the log should show 1 successful and 4 failed transfers. The work around would be to limit the client to a single connection per session and you'd be good to go (assuming someone else didn't get their foot in the door the very microsecond one transfer completes and another hasn't started yet.)

  • 3
    What? This is completely incorrect. A TCP socket is defined by the 4-tuple (source IP, source port, destination port, destination IP). Many TCP sockets can be created and served simultaneously from the same destination port:IP mapping. The FTP server process can serve data two and from any number of network clients at the same time.
    – EEAA
    Apr 27, 2016 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .