Why I cannot Connect to the FTP Server from the Network even though I can telnet to Port 21?


Let’s continue with our discussion about protocol low-downs. I have answered the above question a few times, and I think it is time to document it once and for all.

To the Google searcher, the short answer to the above question: make your browser operate the FTP connections in passive mode. Consult your friendly browser documentation for further help. (If you are the server administrator, I suggest that you read on into the details because that is not a good enough answer for your users).

To the curious and to the readers, you are probably wondering why FTP simply just does not work. Logically, allowing access to port 21 and confirming connection via a telnet command should suffice, yet an FTP client is still unable to establish a connection!

Most FTP clients, by default, will connect to FTP servers by the Active mode.

Active FTP Mode

On a very high level view, the following list is the steps that the client and server will establish an Active FTP connection.

active mode detail

  1. Client opens up a command channel from a random port to the server at port 21.
  2. The client will then send a command to the server that the client has created a random port X for data communication.
  3. The server will then establish a connection from their port 20 (by convention, but not guaranteed) to the client random port X to establish the data communication channel.
  4. When the server establishes the data communication channel, the client will acknowledge.
  5. Further communications would occur on the data communication channel.

To the astute reader, they would recognize that the failure points could be on steps (2) and (3). The potential reason for the failure on step (2) where the client who is initiating the connection could be behind a dumb NAT device, which makes it almost impossible for the server to get in contact with the client’s port.

And the possible cause for step (3) failing? Simply that port 20 may not be on the allow list for incoming connections towards the client.

So why does Passive FTP connections get over these issues?

Passive FTP Mode

Unlike the Active FTP mode, in Passive mode, the client initiates all the connections. This would be a lot friendlier to NAT and firewall configurations. The following describes the algorithm.

passive FTP mode detail

  1. Client opens up a command channel from a random port to the server at port 21.
  2. The client will then issue a PASV command to the server over the command channel.
  3. The server will set up a random port X for the data communication channel, and inform the client of the port number over the command channel.
  4. The client then initiates a new connection to the newly created data communication server port.
  5. The server will then acknowledge the connection on the data communication channel.
  6. Further communications would occur on the data communication channel.

There still exists a failure point for the modern network. Sometimes, an internal FTP server will be exposed via a PAT and port 21 is routed to the internal server. When a random port number is generated on the internal server, the PAT’ing device may not be configured for mapping the randomly generated port X to the internal FTP server.

FTP is Fundamentally Broken

In a nutshell, FTP is not designed for the modern network which needs to utilize NAT and PAT as methods to mitigate the limitations of IPv4. The design of FTP has not scaled well into the post-2010 world.

Furthermore, with the mixture of browsers being designed to connect via Active FTP mode by default (the server has no way to state that they only support Passive mode), and the likelihood of the client being behind a NAT device with restricted firewall policies, FTP is not intuitive technology for the everyday user.

Alternative for Transferring Files

Is there a viable alternative which could transfer very large files? Yes, HTTP is more than capable of handling the task. The improvements that browser vendors and HTTP server vendors have made over the past decade, HTTP is a mature choice to make.

Downloads are handled via byte-serving which ensures that neither the server or client are overwhelmed by the amount of data on the wire.

Uploads can be achieved by multiple means. However, if your application needs to upload very large files, consider following the Valet Key pattern, or similar principled algorithm.

blog comments powered by Disqus