Centos7 cannot connect to FTP server , 200 PORT command successful. Consider using PASV. 425 Failed to establish connection

Solution 1:

It is not enough information to have a complete answer. But you have to always remember that FTP is not a simple protocol. In the simplest case, the active FTP works like this:

1. You make a control connection to port 21 (FTP server), through which
2. You authenticate
3. You tell the server where to make a connection (IP and port)
4. You command the server to start transfer
5. The server makes another connection to the IP and port you told it and sends or receives data.

Usually in step 3 you tell the server your IP and the port your FTP client is listening at, so another connection in the step 5 is being made in reverse direction, from the server to you.

What it would be in the presence of the firewall in between? Let's assume you enabled accepting packets on the port 21 (or whichever you use) on the server. You are able to make a control connection. Now, what about the reverse data connection the server makes? How to enable that?

There are two cases: you either statically allow some port (or range) and configure your FTP client to always use that port, or you have very smart firewall, which actively eavesdrops on the control connection, extracts the IP and port and dynamically creates the temporary rule that permit the reverse connection. This is called ALG which stands for Application-level gateway.

How does the firewall know which connections to eavesdrop? It knows the FTP works over TCP/21, so it simply looks for any traffic on that port. What if you change the control port? You probably have guessed that: the ALG won't work. Firewall won't add the additional dynamic rule so the reverse data connection attempt won't succeed.

There is a hope that if you configure "the ALG" to work with non-default port, the problem will be solved. However, this is not always the case. Ask first, which firewall we are talking about? Modern world uses firewalls heavily, on both ends and in between, and also there is a heavy use of NAT (including CGN which is employed by ISPs). Any NAT needs ALG too: it needs to create a dynamic translation rule towards the client which is behind the NAT and who started the transaction. You only may succeed this way if you were able to configure every ALG along the path the way you want. See where I am going?

There are two common solutions. First, simple: rely on ALGs, which reqiures you to never change the default FTP control port (honestly, 20 years of managing servers and I still don't understand the point of using non-default ports. This creates more problems than solves). Second, simple too: use a passive FTP mode.

The passive FTP works like this:

1. You make a connection to port 21 (FTP server), through which
2. You authenticate
3. You enter the passive mode, and the server replies with IP and port
4. You command the server to start transfer
5. You make another connection to the IP and port the server told you and receive or send the data.

Notice the only changed steps are 3 and 5. They avoid reverse connections.

This partially solves the problem with non-default port and non-controlled ALGs. It also enables the use of the encryption on the control connection (which inherently breaks ALGs).