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:
- Try to ftp in to the external IP from the server
- 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.
The problem seems to be related to a bug as said in the comment. However, for those who are still having trouble to get the logging of firewall denial packets, the following approach worked for me:
The following worked with firewalld + rsyslogd
Edit /etc/sysconfig/firewalld and update the value for LogDenied to all (or as required)
LogDenied=all
restart firewalld
sudo systemctl restart firewalld
Alternatively, using the command line, one can execute the following command:
sudo firewall-cmd --set-log-denied all
This typically adds logging rules just before reject/drop rules in the firewall, something like:
LOG all -- anywhere anywhere LOG level warning prefix "IN_drop_DROP: "
LOG all -- anywhere anywhere LOG level warning prefix "FINAL_REJECT: "
Create a file named /etc/rsyslog.d/custom_iptables.conf and add the following statements to it:
:msg,contains,"_DROP" /var/log/iptables.log
& stop
:msg,contains,"_REJECT" /var/log/iptables.log
& stop
restart rsyslog
sudo systemctl restart rsyslog
Now the dropped and rejected packets will be logged to /var/log/iptables.log
Best Answer
Add virbrX to a trusted zone and try again:
firewall-cmd --add-interface=virbr0 --zone=trusted.