5

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 

6 Answers 6

3

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?

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.

0

If everything is OK localy, it looks like network connection is aborted. Try to use packet sniffer on both sides of connection to check, does every side get all packets sent to it.

Also try to enable verbose logging on server and check what happens.

0

It looks a bit as if your server was exposing LAN IP address (as opposed to WAN IP).

You could try to confirm this using active mode client (be aware this requires your client to be world accessible, so you cannot be hidden behind a firewall).

try adding a line pasv_address=<external ip address> to your vsftpd.conf. Check manual for more details.

2
  • the server doesnt even go out the WAN, the remote pc im saying is part of the ftp network, same subnet. May 6, 2013 at 14:29
  • so, by locally and remotely you don't mean LAN and WAN, is that right?
    – Tomasz W
    May 8, 2013 at 16:47
0

I had the same issue with winscp. It was caused by a firewall rule that was blocking inbound traffic for winscp. Check the firewall inbound rules for the FTP client on your remote computer.

-2

Go to firewall configuration of your server and put TCP/15104 as allowed TCP_IN and TCP_OUT port

1
  • 2
    How is this different from the other answers, posted three years ago, suggesting allowing port 15104? Jul 5, 2016 at 17:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .