Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just did a basic yum install vsftpd on a CentOS 5.3 box, I can FTP to the machines IP address from a shell on the box itself, but cannot FTP from any other machine on the same LAN.

$ ftp
ftp: connect: Connection refused

Troubleshooting steps already tried:

  • on local machine A, attempted to FTP to A's IP with valid credentials, succeeded
  • on machine B on same network, attempted to FTP to A's IP, got connection refused as indicated above
  • from same machine B, nmap shows port 21 open
  • from same machine B, can telnet to port 21 and see the vsftpd banner
  • so, seems the daemon is listening, but something about a connection attempt from outside causes it to refuse the connection.

....and while rewriting this question I restarted the vsftpd daemon and it all started working as expected.

share|improve this question
you "missed" to provide is with any information that could actuall help us debug your problem – hop Jun 18 '09 at 12:19
really? what would you suggest I include? – Paul Dixon Jun 18 '09 at 12:31
What is your network setup? Do you have any firewalls (eg, Linksys) between the server and the internet connection? If so have you set up port forwarding? Have you confirmed your hostname resolves to your IP address and not to another host? Since you can telnet to port 21 (and see the banner) this would indicate that FTP is in fact listening on that port. Are you using telnet to the hostname or IP? – Dave Drager Jun 18 '09 at 12:39

Alright, my general debugging guidelines for testing services go something like this:

0) Stick to IPs when testing to eliminate DNS as the problem

1) Test locally
Can you connect to the FTP server from the machine that its running on?

2) Test remotely on the same network
Can you connect from another machine on that subnet?

3) Test from untrusted source
Can you cross firewall boundries to get there?

It sounds like you've done the first one, and it's failing on the 2nd. If you can telnet from a remote box to port 21 on the server and receive an FTP banner, then the FTP server is working.

Update your question to show your troubleshooting steps, if you could please, so that we can more accurately determine where the problem lies.

share|improve this answer

If you can connect to localhost, but you can not to "" from the same machine, then it would suggest that the server is only listening on, rather than all interfaces. You can check this by running:

# netstat -lep --tcp | grep  vsftp

If it says "localhost:ftp" then it is only listening on localhost. Look for a config option that is something like "Listen" or talks about binding to addresses or interfaces. If it says "*:ftp" then it is listening on all interfaces and something else is wrong. Possibly firewall or networking configuration problems.

share|improve this answer
I wasn't testing on localhost, and like I said, the box is listening on port 21, as tested externally by nmap – Paul Dixon Jun 18 '09 at 12:29

With any modern redhat based distro check selinux. I.e. getenable to see if it is turned on (enforcing). If it is setenforce 0 to turn it off and see if that makes a difference. setenforce 1 to turn it back on.

If it was selinux, then you probably need to set on the the booleans.

Try something like: getsebools -a|grep -i ftp to see the state of ftp related booleans. To set them use setsebools.

Are you using iptables host based firewall - if so is the appropriate iptables module enabled I can't recall what it is but it can be enabled in a file called //etc/sysconfig/iptables-config.

Its something like conntrack_ftp.

share|improve this answer
up vote 0 down vote accepted

Thanks for various suggestions. While I'm not sure what actually occurred, a restart of the daemon seemed to resolve the problems.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.