cannot list directory when accessing ftp server remotely
I installed vsftpdand everything is working fine when accessing it locally, but I cannot view the folders when accessing it remotely.
Using FileZilla in my remote PC, I get this:
status: connecting to 192.x.x.x
status: connection established, waiting for welcome message
response: welcome
command: user admin
response: specify pass
command: pass ****
response: 230 login successful
command: opts utf8 on
response: 200 always in utf8 mode
status: connected
status: retrieving directory listing..
command: pwd
response: 257 "/var/ftp"
command: type I
response: 200 switching to binary mode
command: PASV
response: 227 entering passive mode (192.168.8.5,59,0).
command: list
and it stops right there, then connection timeout. I cannot view the folders or the directories on the FTP server.
On my iptables -L -n
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
My /etc/vsftp/vsftp.conf
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
#chown_uploads=YES
#chown_username=whoever
#xferlog_file=/var/log/xferlog
xferlog_std_format=YES
idle_session_timeout=120
#data_connection_timeout=120
#nopriv_user=ftpsecure
#async_abor_enable=YES
#ascii_upload_enable=YES
#ascii_download_enable=YES
ftpd_banner= Welcome
#deny_email_enable=YES
#chroot_local_user=YES
#chroot_list_enable=YES
#chroot_list_file=/etc/vsftpd/chroot_list
#ls_recurse_enable=YES
listen=YES
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
Solution 1:
The problem is very likely that you've asked for passive mode - where the client is required to open a new data connection to the server, on the specified port - but you haven't permitted those ports through your firewall. For example, the data connection above is expected on port TCP/15104 (59*256+0), but you've only allowed inbound TCP/21 and TCP/20 (or, at least, that's all you've told us about).
We can't know this for sure until we see the whole firewall ruleset; could you amend the question to include the entire output of iptables -L -n -v?
Solution 2:
At this point the FTP server is expecting the client to open a new connection to transfer the data by connecting via TCP on port 15014 (59*256+0) - either the firewall on the server or the client (or somewhere between) is likely to be rejecting this connection.
IIRC wsftp has a couple of configuration settings that control the range of ports it might expect data connections on. Check what thee are (or set them explicitly to a range of your choice) and then open those ports in your firewall rules as you already have for the FTP control connections.
If you were not using passive mode there would be a similar problem in the other direction: the server would need to be able to open a connection to the client on a port specified be earlier commands.
This splitting of the control and data connections often causes firewall problems. If you don't have a specific requirement for FTP (compatibility with an existing service you can not change, or users who only have access to an FTP client, or similar) I strongly recommend usnig SFTP/SCP as provided by most SSH daemons - this removes the multiple arbitrary connections problem (everything is done over one duplex TCP connection, usually on port 22), and is significantly more secure too.
Update
The settings for controlling the data connection ports are pasv_min_port and pasv_max_port, though that may not be needed. If you load the ip_conntrack_ftp module then it may track the FTP control connections and mark incoming data connections as "related" - so you can add an iptables rule to allow packets from "related" connections on ports 1024 or above as well as accepting those for "established" connections. See http://www.cyberciti.biz/faq/iptables-passive-ftp-is-not-working/#comments for one example of this.
I would still recommend SFPT/SCP via OpenSSH or similar though - it is more secure and easier to manage.