FTP Issue: Connection Refused
Hello,
I have installed and configured vsftpd according to this tutorial:
http://www.debianaddict.org/article47.html
I am using RedHat and I would like to set up an FTP on a local network
When I run vsftpd start it's fine
restart, it shows failed to stop.
And when I run ftp localhost
ftp: connect: Connection refused
I am lost, there are discussions in various forums about telnet port 21 etc.
and despite all that, I can't solve my problem.
Thank you in advance (I have been using Linux for a short time)
I have installed and configured vsftpd according to this tutorial:
http://www.debianaddict.org/article47.html
I am using RedHat and I would like to set up an FTP on a local network
When I run vsftpd start it's fine
restart, it shows failed to stop.
And when I run ftp localhost
ftp: connect: Connection refused
I am lost, there are discussions in various forums about telnet port 21 etc.
and despite all that, I can't solve my problem.
Thank you in advance (I have been using Linux for a short time)
Configuration: Windows XP Firefox 3.0.4
1 answer
Ftp is a protocol where the server listens by default on port 21. I remind you that a machine hosting several servers (for example, an http server, an ssh server, an ftp server) opens several ports. It listens with one port per server (80 for http, 22 for ssh, and 21 for ftp by default) in order to welcome connections from potential clients. Once the connection is established, communication between the two machines can begin.
In the case of ftp, a client attempts to connect to server:21 to access shared data. Telnet allows you to test a connection on any port and verify that communication is established between the client and the server. Furthermore, if a firewall blocks communication, it will fail.
We will now try to find the cause of the problem. I feel that your issue is likely to be at steps C or D since your message is "connection refused." To be sure everything is okay, I invite you to check that A and B are fine. For example, if you are on a corporate network, an ftp server may refuse ftp connections from the outside but allow those that are internal. If you go through your gateway instead of directly connecting, the server may reject you thinking you are an external request.
A) The first thing to do is to check if you can route your traffic to the server. If you use its hostname instead of its domain name, you need to see if you can resolve it (otherwise move on to B). For example, you can use the host or nslookup commands:
B) Next, you need to check if you have a route to access this destination from the client. I believe this is likely the case, but it doesn’t hurt to verify. You can check this with the command:
Example:
In this example, all addresses in the form of 192.168.1.* are routed by the first route, and all others by the second route (here called the default route, since it captures all destinations not already handled by the first).
C) Next, you need to check if port 21 is open. In my opinion, the issue likely comes from there. Instead of using telnet, it’s simpler to use nmap from the client. By replacing x.x.x.x with the name or IP address of the ftp server, run an nmap:
In this example, port 21 is not open, so it is impossible to connect via ftp (if the server is indeed listening on port 21).
If the port is closed, there’s no need to look further; it’s a cause of the problem. Either you are going through an intermediary device that filters ftp (a proxy or a gateway with a firewall, for example), or the firewall of the client or server is filtering the ftp request. Otherwise, we continue!
D) If the port is open, the issue lies either in the server configuration (blacklist, firewall) or the client (wrong authentication, wrong login, wrong password…). Try to see if you can connect to your server via lftp (especially if your server expects an SSL connection and your current client doesn’t handle it, that might explain your problem).
Generally speaking, I find that ftp is not very practical and not necessarily very secure. I recommend using ssh, which is straightforwardly secure and much easier to configure. Note that ssh clients exist for both Linux (konqueror under KDE, nautilus under gnome + the ssh and scp commands) and Windows (winscp, for example).
Good luck!
In the case of ftp, a client attempts to connect to server:21 to access shared data. Telnet allows you to test a connection on any port and verify that communication is established between the client and the server. Furthermore, if a firewall blocks communication, it will fail.
We will now try to find the cause of the problem. I feel that your issue is likely to be at steps C or D since your message is "connection refused." To be sure everything is okay, I invite you to check that A and B are fine. For example, if you are on a corporate network, an ftp server may refuse ftp connections from the outside but allow those that are internal. If you go through your gateway instead of directly connecting, the server may reject you thinking you are an external request.
A) The first thing to do is to check if you can route your traffic to the server. If you use its hostname instead of its domain name, you need to see if you can resolve it (otherwise move on to B). For example, you can use the host or nslookup commands:
(mando@aldur) (~) $ nslookup www.google.fr Server: 80.10.246.130 Address: 80.10.246.130#53 Non-authoritative answer: www.google.fr canonical name = www.google.com. www.google.com canonical name = www.l.google.com. Name: www.l.google.com Address: 74.125.43.104 Name: www.l.google.com Address: 74.125.43.147 Name: www.l.google.com Address: 74.125.43.103 Name: www.l.google.com Address: 74.125.43.99Here I can successfully resolve www.google.fr. Your server should do the same.
B) Next, you need to check if you have a route to access this destination from the client. I believe this is likely the case, but it doesn’t hurt to verify. You can check this with the command:
/sbin/route -n
Example:
(mando@aldur) (~) $ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
In this example, all addresses in the form of 192.168.1.* are routed by the first route, and all others by the second route (here called the default route, since it captures all destinations not already handled by the first).
C) Next, you need to check if port 21 is open. In my opinion, the issue likely comes from there. Instead of using telnet, it’s simpler to use nmap from the client. By replacing x.x.x.x with the name or IP address of the ftp server, run an nmap:
(mando@aldur) (~) $ nmap x.x.x.x Starting Nmap 4.62 ( https://nmap.org/ ) at 2008-11-17 14:36 CET Interesting ports on ...... (x.x.x.x): Not shown: 1708 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind 113/tcp open auth 631/tcp open ipp 797/tcp open unknown 7634/tcp open hddtemp Nmap done: 1 IP address (1 host up) scanned in 0.235 seconds
In this example, port 21 is not open, so it is impossible to connect via ftp (if the server is indeed listening on port 21).
If the port is closed, there’s no need to look further; it’s a cause of the problem. Either you are going through an intermediary device that filters ftp (a proxy or a gateway with a firewall, for example), or the firewall of the client or server is filtering the ftp request. Otherwise, we continue!
D) If the port is open, the issue lies either in the server configuration (blacklist, firewall) or the client (wrong authentication, wrong login, wrong password…). Try to see if you can connect to your server via lftp (especially if your server expects an SSL connection and your current client doesn’t handle it, that might explain your problem).
Generally speaking, I find that ftp is not very practical and not necessarily very secure. I recommend using ssh, which is straightforwardly secure and much easier to configure. Note that ssh clients exist for both Linux (konqueror under KDE, nautilus under gnome + the ssh and scp commands) and Windows (winscp, for example).
Good luck!