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

i'm trying to connect linux ftp server in window command prompt it works fine when ftp port is default (20, 21)

it's not working after i changed the default port of FTP , FTP-DATA

yes i did checked firewall ( it's the same when even stop the firewall), and yes i did checked vsftpd.conf file

is there a something else to check if port are changes ? i thought only vsftpd.conf is the one what effected to FTP and FTP-DATA port

• works fine when the port is default (20, 21)

• 425 Failed to establish connection. when i changed the port

and this is my /etc/vsftpd/vsftpd.conf file

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
listen_port=39021 # add this
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=NO
ftp_data_port=39020  # add this
xferlog_std_format=YES
ftpd_banner=Welcome to blah FTP service.
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list
listen=YES
port_enable=YES
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=NO
pasv_enable=YES       # add this
pasv_min_port=60019   # add this
pasv_max_port=60020   # add this 
pasv_address=[My IP]  # add this 
allow_writeable_chroot=YES
port_promiscuous=YES  # add this 

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).