Unable to open ftp port 21 on centos using firewalld

Question

I am trying to install vsftpd on Centos 7. I can connect to the server from localhost, but not connect to it from remote machines. I am somewhat new to the topic of system and network administration.

Here are some places I've looked for answers:
Can not open ftp port via firewalld
Centos does not open port/s after the rule/s are appended
Port 80 filtered nmap

I have the vsftpd service up and running:

> netstat -plnt | grep ':21. '
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      12393/vsftpd

and I can log in using ftp localhost just fine. But when I attempt a remote login, I get "connection timed out" after several seconds. So I'm suspecting a firewall issue.

(Also, from FTP port closed for vsftpd service

lsof -i:21
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
vsftpd  12393 root    3u  IPv4 63746670      0t0  TCP *:ftp (LISTEN)

)

Since this is Centos, I'm using firewalld. Port 21 appears to be open:

> firewall-cmd --list-services
dhcpv6-client ftp https ssh

and:

> firewall-cmd --list-ports
433/tcp 21/tcp 80/tcp 20/tcp

Also:

> firewall-cmd --get-default-zone
public
> firewall-cmd --get-active-zone
public 
  interfaces: enp0s25

and I have reloaded firewalld via firewall-cmd --reload

But if I try nmap from a remote machine, it claims ports 20 and 21 are filtered:

> nmap -p20,21 my.ftp.server.com
Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 13:48 PDT
Nmap scan report for rrcs-xx-xx-xx-xx 
(xx.xx.xx.xx)
Host is up (0.035s latency).
PORT   STATE    SERVICE
20/tcp filtered ftp-data
21/tcp filtered ftp

I even tracked looked through all the iptables rules, following firewalld's various chains, and found these:

> iptables -S IN_public_allow
-N IN_public_allow
-A IN_public_allow -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 20 -m conntrack --ctstate NEW -j ACCEPT

I'm happy to post the entire output of iptables -S if anyone thinks it would help.

Finally, I have switched off SELinux for just long enough to determine that I get the same behavior with it off as with it on.

So my questions are:

Could some other machine possibly be filtering port 21 traffic before it gets to my machine? (There is also a web server on this machine that I can connect to just fine). If so, how might I go about determining that?

Is there some other thing that I can check to debug this issue?

Any and all help are appreciated.

Answer 1

nmap "filtered" in and of itself doesn't mean that your FTP access is blocked -- can just mean that an intermediate firewall detected that you are running an nmap scan & probe and dropped the packets. It's a pretty common "feature". Unfortunately, after the firewall starts dropping your ftp packets, you'll have to wait a bit for the state to clear so that you can legitimately try logging in.

Beyond that, there are other user/port control services besides firewalld and iptables that can interfere. One is /etc/hosts.allow or /etc/hosts.deny , which is provided through tcp_wrappers

Try adding a line to your hosts.allow file that reads:

ALL : YOUR_IP_ADDRESS_HERE : allow

This says "all ports" : IP: allow access.

Another question to ask is if you can log in from the server via it's external interface instead of the localhost loopback alias. ftp MY_IP . localhost is often allowed to log in even when "listen" is turned off e.g. /etc/vsftpd.conf

LISTEN=NO # is this in your vsftpd.conf file?

This is because it is not actually "listening" to the external ipv4 or ipv6 interface.

Also check your /etc/services file, are the following lines commented in or out?

services:ftp-data        20/tcp
services:ftp-data        20/udp

Regarding iptables, if you are worried that the rules are interfering, just flush them:

iptables -F

So I think the order of operations/checks is this:

1. Try to ftp in to the external IP from the server
2. If fail to connect, check netstat -al, and check your /etc/vsftp.conf, /etc/services, /etc/hosts.allow -- try again.

If OK, then intermediate or source-based packet filtering is your enemy 3. If fail, flush iptables, try again 4. If still fail, there's still some other problem preventing your from logging in through the local server.

If at point 2, you could log in, you still want to try flushing your iptables and checking the syslog for error messages. It will usually say that the "connection dropped from source..." for incoming connections that fail tcp_wrappers.

Look also for these lines in vsftpd.conf

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

If you aren't able to narrow down the connection on your server, it'll be time to start looking through the route to server traceroute MY_SERVER_IP from your host, or traceroute MY_CLIENT_IP from the server. This command can also be tracepath. I will say that it is quite unlikely that a near-to-server firewall in a hosting facility is blocking your connections. If it is a corporate environment, it is quite possible, even likely, but if the environment your server is in is either a hosting facility or an educational institution, blocking FTP ports at the router is much less common. It is also uncommon for client ISPs such as Comcast.

How far are the remote machines? e.g. how many network hops? If you are on the same subnet with the server, then obviously it is the server configuration.