FTP server hanging when using "ls" command: "Consider using PASV"

Question

I'm trying to use "ls" command on a anonymous FTP session, but when I'm typing the "ls" command I get:

200 PORT command successfull. Consider using PASV.

And it hangs like this (no return to the ftp prompt).

I restarted the ftp session and entered in passive mode (quote PASV), but I get another problem: "No route to host"

Do you have any suggestion ?

Answer 1

quote PASV doesn't enter passive mode the way you think it does – "PASV" is an immediate command (that precedes each and every transfer) instead of a permanent mode-switch command.

Rather, the client must be told to use PASV instead of PORT whenever ls or a file transfer is requested.

With inetutils-ftp, use the passive command, or run the client as pftp or ftp --passive.

Answer 2

I remember seeing this issue once when I forgot to open up port 20 in the firewall. While the port usually associated with FTP is 21, data is usually sent via port 20.

Ensure that both 20 and 21 are open on both client and server, so that whoever initiates the connection on port 20 can get through.

Answer 3

Do you have any suggestion ?

Yeah, ditch FTP.

I know that probably wasn't the answer you were wanting to hear, but let me explain why it is actually necessary, and then you may be more inclined to do this. I will also give you another alternative.

FTP was written when the Internet was considered to be an experimental project. The major universities and large organizations had rules of conduct, enforced by the respected institutions, and so people on the Internet (actually called the ARPAnet back then) were trusted.

FTP was designed to have the client use a TCP connection to send a request for a file. Then the server received the request, and initiated a separate TCP connection to the client.

This broke when clients started using firewalls to protect their stuff. So FTP clients could make outgoing connections, but incoming connections were blocked.

A way around that was passive mode: The client sends a request using TCP port 21, then the server says it wants another connection using some random TCP port (e.g., 43728), and then the client makes a second connection using the specified random TCP port (e.g., 43728).

That worked if the client had a firewall. Many people started to learn that "passive mode" fixed the FTP problems. However, what "passive mode" actually fixed was just that one specific problem. If the server has a firewall that only allows incoming traffic on specific port numbers, like port 21 for FTP, then even "passive mode" doesn't fix everything that is required to work.

In theory this could be fixed if the FTP server's firewall supports an FTP proxy which monitors traffic and opens up another port if needed. Many people consider that to be a bit hard to set up.

As more organizations cared more about security, and cared less about FTP, people began to learn that FTP was becoming typically broken (meaning that more and more FTP servers were being challenging to use from more and more locations that people might try to use an FTP client at). FTP problems started to become more widespread.

For a while, people learned that "passive mode" seemed to be a magic "cure-all" technique that fixed the FTP problems. (Many people didn't understand why FTP stopped working. They just learned that if FTP started acting weird, "passive mode" seemed to fix that weird problem that FTP experienced. Later, the believe that "passive mode" was magic "cure-all" got commonly replaced with a different belief, which is that FTP just commonly doesn't seem to work anymore (not nearly as well as it used to). Even if many people didn't understand why FTP broke, what they did understand is that life did seem to work more successfully when they tried another technique, which is to just start moving onto using other protocols. As HTTPS uploading began to get more popular, people just stopped using FTP nearly as much.

So your best solution is to actually just ditch the old FTP protocol which doesn't work with modern Internet security measures. FTP just wasn't designed for that. NAT is also used to help multiple devices use one IP address.

NAT is often implemented by a firewall, although it can have purposes other than just security (like increasing the number of supported devices). Whatever the purpose might be for using NAT, the end result is that NAT basically breaks the FTP connection for the same reasons (not allowing the connection to reach the desired device). So, FTP also wasn't designed to support NAT.

Back in the day, FTP was just an experimental effort to try to get file transferring working. FTP accomplished its original goal. So, despite not working well with today's Internet designed, FTP wasn't really designed poorly. Its design really was a good success, at the time. It was just designed for a different style of Internet than one that uses today's common technologies.

HTTP doesn't have as many problems, since it uses one TCP connection instead of multiple. Nor do many secure alternatives: HTTPS, SFTP, FTPS, SCP.

I promised another alternative. It is: make FTP work. Strategies include: * Have your client side firewall run an FTP proxy * Have the FTP server's firewall run an FTP proxy

The problem is that you often don't have control over one side of the connection. So one of those may not be an option for you.

You might want to try just removing your firewall altogether. However, this is likely to introduce security risks that most people consider to be NOT work the benefit. Instead, just scrap the idea of using the old FTP protocol that doesn't work so well with the modern Internet, and get some modern software to use file transfers over HTTPS or FTPS (or SCP). It will typically work better with firewalls, work better with NAT, and give you the benefits of privacy. (You didn't really want to be broadcasting your password, unencrypted, over the Internet, did you?)

Unless you are trying to grab public files, in which case HTTPS or HTTP may be the easier route.