I can connect to ftp server but the listing fails if firewalld and iptables services are running. Turning them off would make it work just fine?
Was able to save the iptables config file and after going thru it found the line that is causing the issue on line 138?
-A INPUT -j REJECT --reject-with icmp-host-prohibited
If I comment out that line, and restart the iptables, the ftp connection and list would work just fine. I'm not clear on what would be adding this line to the iptables? Not sure if that rule should be there, and if so, why would it reject the ftp listing? Had been working before I had upgraded lab machines to Fedora 24?
Thanks.
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS ABC 16613838.513356 | EINSTEIN 114625025.788695 ROSETTA 49468446.751024 | SETI 92870386.897682
On 10/01/2016 04:37 PM, Michael D. Setzer II wrote:
I can connect to ftp server but the listing fails if firewalld and iptables services are running. Turning them off would make it work just fine?
Both firewalld and iptables? That doesn't sound right.
Was able to save the iptables config file and after going thru it found the line that is causing the issue on line 138?
-A INPUT -j REJECT --reject-with icmp-host-prohibited
If I comment out that line, and restart the iptables, the ftp connection and list would work just fine. I'm not clear on what would be adding this line to the iptables? Not sure if that rule should be there, and if so, why would it reject the ftp listing? Had been working before I had upgraded lab machines to Fedora 24?
If that's the whole line, then it must the final line that rejects anything not specifically allowed. You need to add something to allow ftp which should be done through firewalld.
On 1 Oct 2016 at 17:34, Samuel Sieb wrote:
Subject: Re: Problem with firewalld/iptables and ftp access list? To: Community support for Fedora users users@lists.fedoraproject.org From: Samuel Sieb samuel@sieb.net Date sent: Sat, 1 Oct 2016 17:34:13 -0700 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On 10/01/2016 04:37 PM, Michael D. Setzer II wrote:
I can connect to ftp server but the listing fails if firewalld and iptables services are running. Turning them off would make it work just fine?
Both firewalld and iptables? That doesn't sound right.
Was able to save the iptables config file and after going thru it found the line that is causing the issue on line 138?
-A INPUT -j REJECT --reject-with icmp-host-prohibited
If I comment out that line, and restart the iptables, the ftp connection and list would work just fine. I'm not clear on what would be adding this line to the iptables? Not sure if that rule should be there, and if so, why would it reject the ftp listing? Had been working before I had upgraded lab machines to Fedora 24?
If that's the whole line, then it must the final line that rejects anything not specifically allowed. You need to add something to allow ftp which should be done through firewalld.
The ftp option is selected in the firewall-config. The connection to the ftp server and login process also works just fine. It is just the ls that fails with this line?
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS ABC 16613838.513356 | EINSTEIN 114625025.788695 ROSETTA 49468446.751024 | SETI 92870386.897682
On 10/02/16 07:37, Michael D. Setzer II wrote:
I can connect to ftp server but the listing fails if firewalld and iptables services are running. Turning them off would make it work just fine?
Was able to save the iptables config file and after going thru it found the line that is causing the issue on line 138?
-A INPUT -j REJECT --reject-with icmp-host-prohibited
If I comment out that line, and restart the iptables, the ftp connection and list would work just fine. I'm not clear on what would be adding this line to the iptables? Not sure if that rule should be there, and if so, why would it reject the ftp listing? Had been working before I had upgraded lab machines to Fedora 24?
Don't have an answer, but may try to duplicate the issue.
Which ftp server are you running? AFAIK, there are at least 2 supplied with Fedora.
FWIW, that line exists without an ftp server installed on my systems.
[root@acer ~]# iptables-save | grep icmp-host -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited
On 10/02/16 14:51, Gordon Messmer wrote:
On 10/01/2016 04:37 PM, Michael D. Setzer II wrote:
I can connect to ftp server but the listing fails if firewalld and iptables services are running.
Does the problem go away if you "modprobe nf_conntrack_ftp" as root, and leave firewalld up?
FWIW, /usr/lib/firewalld/services/ftp.xml suggests that enabling ftp via firewalld will also load nf_conntrack_ftp.
On 10/02/16 15:17, Ed Greshko wrote:
On 10/02/16 14:51, Gordon Messmer wrote:
On 10/01/2016 04:37 PM, Michael D. Setzer II wrote:
I can connect to ftp server but the listing fails if firewalld and iptables services are running.
Does the problem go away if you "modprobe nf_conntrack_ftp" as root, and leave firewalld up?
FWIW, /usr/lib/firewalld/services/ftp.xml suggests that enabling ftp via firewalld will also load nf_conntrack_ftp.
I have found that indeed nf_conntrack_ftp is "enabled" by selecting ftp in firewalld. However, that isn't dynamic like opening the ports. It is loaded on the next reboot.
On 2 Oct 2016 at 16:14, Ed Greshko wrote:
From: Ed Greshko ed.greshko@greshko.com Subject: Re: Problem with firewalld/iptables and ftp access list? To: Fedora users@lists.fedoraproject.org Date sent: Sun, 2 Oct 2016 16:14:48 +0800 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On 10/02/16 15:17, Ed Greshko wrote:
On 10/02/16 14:51, Gordon Messmer wrote:
On 10/01/2016 04:37 PM, Michael D. Setzer II wrote:
I can connect to ftp server but the listing fails if firewalld and iptables services are running.
Does the problem go away if you "modprobe nf_conntrack_ftp" as root, and leave firewalld up?
FWIW, /usr/lib/firewalld/services/ftp.xml suggests that enabling ftp via firewalld will also load nf_conntrack_ftp.
I have found that indeed nf_conntrack_ftp is "enabled" by selecting ftp in firewalld. However, that isn't dynamic like opening the ports. It is loaded on the next reboot.
The modeprobe nf_conntrack_ftp doesn't output any messge or error? Not sure what it is suppose to output.
I did a test from a machine to the server running the vsftp server and using ncftp or ncftpls, but in the past have also used ftp with the same results.
With the line disabled everything seems to work, but without it seems to fail, but in one section changed passive mode, back it seemed to continue??
These machines are in the same 192.168.7.x network connected to the same switch? All are running Fedora 24, upgraded via dnf from 23 over the summer. With the 23, never had any issues.
test-iptables results [msetzerii@d7t ~]$ ncftpls ftp://192.168.7.101/verne.png verne.png Test from other machine with line disabled.
[root@d7t sysconfig]# ncftp 192.168.7.101 NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/). Connecting to 192.168.7.101... (vsFTPd 3.0.3) Logging in... Login successful. Logged in to 192.168.7.101. ncftp / > ls verne.png verne.png ncftp / > passive passive on ncftp / > ls verne.png verne.png ncftp / > passive passive off ncftp / > ls verne.png verne.png ncftp / >
Reenabled the line in iptables and rebooted server machine [root@d7t sysconfig]# ncftp 192.168.7.101 NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/). Connecting to 192.168.7.101... (vsFTPd 3.0.3) Logging in... Login successful. Logged in to 192.168.7.101. ncftp / > ls verne.png connect failed: No route to host. connect failed: No route to host. connect failed: No route to host. List failed. ncftp / > get verne.png connect failed: No route to host. connect failed: No route to host. connect failed: No route to host. get verne.png: could not connect data socket. ncftp / > passive passive off ncftp / > ls verne.png verne.png ncftp / > get verne.png verne.png: 2.81 MB 50.15 MB/s ncftp / > ncftp / > passive passive on ncftp / > ls verne.png verne.png ncftp / > get verne.png get verne.png: local file appears to be the same as the remote file, download is not necessary. ncftp / >
As a test, after a reboot with the line enabled, I had 19 machines attempt to ls the verne.png and all failed with connection error. I then commented out the line, and stopped, and then started iptables and all machines had no issues with listing?
The iptables-save listing (line 138 with the ### is bolded) # Generated by iptables-save v1.4.21 on Sat Oct 1 16:13:53 2016 *security :INPUT ACCEPT [41:2655] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [47:3628] :FORWARD_direct - [0:0] :INPUT_direct - [0:0] :OUTPUT_direct - [0:0] -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct COMMIT # Completed on Sat Oct 1 16:13:53 2016 # Generated by iptables-save v1.4.21 on Sat Oct 1 16:13:53 2016 *nat :PREROUTING ACCEPT [5:268] :INPUT ACCEPT [1:60] :OUTPUT ACCEPT [9:617] :POSTROUTING ACCEPT [9:617] :OUTPUT_direct - [0:0] :POSTROUTING_ZONES - [0:0] :POSTROUTING_ZONES_SOURCE - [0:0] :POSTROUTING_direct - [0:0] :POST_public - [0:0] :POST_public_allow - [0:0] :POST_public_deny - [0:0] :POST_public_log - [0:0] :PREROUTING_ZONES - [0:0] :PREROUTING_ZONES_SOURCE - [0:0] :PREROUTING_direct - [0:0] :PRE_public - [0:0] :PRE_public_allow - [0:0] :PRE_public_deny - [0:0] :PRE_public_log - [0:0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A OUTPUT -j OUTPUT_direct -A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN -A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -A POSTROUTING_ZONES -o enp2s0 -g POST_public -A POSTROUTING_ZONES -g POST_public -A POST_public -j POST_public_log -A POST_public -j POST_public_deny -A POST_public -j POST_public_allow -A PREROUTING_ZONES -i enp2s0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMIT # Completed on Sat Oct 1 16:13:53 2016 # Generated by iptables-save v1.4.21 on Sat Oct 1 16:13:53 2016 *mangle :PREROUTING ACCEPT [46:2903] :INPUT ACCEPT [46:2903] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [47:3628] :POSTROUTING ACCEPT [47:3628] :FORWARD_direct - [0:0] :INPUT_direct - [0:0] :OUTPUT_direct - [0:0] :POSTROUTING_direct - [0:0] :PREROUTING_ZONES - [0:0] :PREROUTING_ZONES_SOURCE - [0:0] :PREROUTING_direct - [0:0] :PRE_public - [0:0] :PRE_public_allow - [0:0] :PRE_public_deny - [0:0] :PRE_public_log - [0:0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A POSTROUTING -j POSTROUTING_direct -A PREROUTING_ZONES -i enp2s0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMIT # Completed on Sat Oct 1 16:13:53 2016 # Generated by iptables-save v1.4.21 on Sat Oct 1 16:13:53 2016 *raw :PREROUTING ACCEPT [46:2903] :OUTPUT ACCEPT [47:3628] :OUTPUT_direct - [0:0] :PREROUTING_direct - [0:0] -A PREROUTING -j PREROUTING_direct -A OUTPUT -j OUTPUT_direct COMMIT # Completed on Sat Oct 1 16:13:53 2016 # Generated by iptables-save v1.4.21 on Sat Oct 1 16:13:53 2016 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [47:3628] :FORWARD_IN_ZONES - [0:0] :FORWARD_IN_ZONES_SOURCE - [0:0] :FORWARD_OUT_ZONES - [0:0] :FORWARD_OUT_ZONES_SOURCE - [0:0] :FORWARD_direct - [0:0] :FWDI_public - [0:0] :FWDI_public_allow - [0:0] :FWDI_public_deny - [0:0] :FWDI_public_log - [0:0] :FWDO_public - [0:0] :FWDO_public_allow - [0:0] :FWDO_public_deny - [0:0] :FWDO_public_log - [0:0] :INPUT_ZONES - [0:0] :INPUT_ZONES_SOURCE - [0:0] :INPUT_direct - [0:0] :IN_public - [0:0] :IN_public_allow - [0:0] :IN_public_deny - [0:0] :IN_public_log - [0:0] :OUTPUT_direct - [0:0] -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP ### -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i enp2s0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o enp2s0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCEPT -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A INPUT_ZONES -i enp2s0 -g IN_public -A INPUT_ZONES -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 9001 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p udp -m udp --dport 20 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p udp -m udp --dport 9000 -m conntrack --ctstate NEW -j ACCEPT -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 -A IN_public_allow -p tcp -m tcp --dport 9000 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p udp -m udp --dport 21 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 5979 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p udp -m udp --dport 9001 -m conntrack --ctstate NEW -j ACCEPT -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 5900:5979 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW -j ACCEPT COMMIT # Completed on Sat Oct 1 16:13:53 2016
-- You're Welcome Zachary Quinto _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 10/02/16 19:48, Michael D. Setzer II wrote:
The modeprobe nf_conntrack_ftp doesn't output any messge or error? Not sure what it is suppose to output.
No, it probably won't. Before issuing the modprobe, it would have been a good idea to use lsmod to see if it was already loaded.
FWIW, as I mentioned the module doesn't get loaded when initially making changes to the firewall with the GUI. But you could use the GUI to reload and it does get loaded. Once loaded, it stays loaded unless you issue an rmmod command and the module is not in use.
I did a test from a machine to the server running the vsftp server and using ncftp or ncftpls, but in the past have also used ftp with the same results.
With the line disabled everything seems to work, but without it seems to fail, but in one section changed passive mode, back it seemed to continue??
These machines are in the same 192.168.7.x network connected to the same switch? All are running Fedora 24, upgraded via dnf from 23 over the summer. With the 23, never had any issues.
I fired up an F22 system and did an iptables-save and found it also has the line
-A INPUT -j REJECT --reject-with icmp-host-prohibited
That's about all I can say this my evening. If I have time tomorrow I'll put up a vsftpd on a system and see if I can recreate the issue.
I have no idea why I'd suggest this, other than the active/passive comments you made, but I guess you can also try to open port 20 and with that line active in iptables see if the results are the same.
On 10/02/16 20:04, Ed Greshko wrote:
That's about all I can say this my evening. If I have time tomorrow I'll put up a vsftpd on a system and see if I can recreate the issue.
I have installed vsftpd on an F24 and F23 system and verified that F24 fails as described by Michael while F23 succeeds.
I've found this problem to have been recently reported in https://bugzilla.redhat.com/show_bug.cgi?id=1380168.
On 10/02/2016 04:48 AM, Michael D. Setzer II wrote:
The modeprobe nf_conntrack_ftp doesn't output any messge or error? Not sure what it is suppose to output.
It shouldn't output anything. In your iptables rules you find these:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
When an FTP client connects to your server, it connects to port 21 which is allowed by the second rule quoted above. The purpose of the nf_conntrack_ftp module is to examine FTP traffic to determine which new connections should be allowed by the former rule. When a client makes a PASV mode connection, it will make additional connections to high numbered ports for data transfers (including retrieving the output of commands like "LIST"). That connection should be RELATED, and so allowed by the former rule. It seems that for some reason, your system isn't allowing such connections.
I'll note several things.
First, I'm unable to reproduce the problem on a mostly up-to-date Fedora 24 system (still running kernel 4.7.4-200.fc24.x86_64 until I reboot).
Second, your iptables rules are a mess. For some reason, there are multiple rules allowing connections to TCP ports 21 and 22 in the IN_public_allow chain. I don't know any reason that would be a problem per se, but it probably indicates that something else is wrong with the system.
Third, you definitely should not be running both the iptables and firewalld services, simultaneously.
Fourth, the reason that removing "-A INPUT -j REJECT --reject-with icmp-host-prohibited " from your rules fixes the problem is that removing that rule allows all traffic. firewalld rules, generally, allow traffic indicated by policy first, and then REJECT everything else. When you remove the rule that REJECTS everything else, you're allowing the traffic that's allowed by policy and all other traffic hits the policy which is ACCEPT. Removing that rule is the same as turning off the firewall, except that you still spend the CPU time examining traffic for not reason.
The problem has been confirmed by Ed and by Alfonso, who opened the bug report, but it isn't universal, since it doesn't affect the one system I tested. More details are needed. If it's actually a problem with nf_conntrack_ftp, your kernel version would be helpful, for one. It may also be helpful to get a network capture. I used "ngrep" to capture the following FTP sessions, one PASV and the other PORT.
#### T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 220 (vsFTPd 3.0.3).. ## T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] FEAT.. ## T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 211-Features:.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] EPRT.. EPSV.. MDTM.. PASV.. REST STREAM.. SIZE.. TVFS.. UTF8..211 End.. ## T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] OPTS UTF8 ON.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 200 Always in UTF8 mode... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] USER ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 331 Please specify the password... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] PASS ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 230 Login successful... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] PWD.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 257 "/" is the current directory.. # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] PASV.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 227 Entering Passive Mode (10,1,10,94,114,151)... #### T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] LIST.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 150 Here comes the directory listing... # T 10.1.10.94:29335 -> 10.1.10.50:49489 [AP] -rw-r--r-- 1 0 00 Oct 02 21:07 test.. ##### T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 226 Directory send OK... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] QUIT.. ## T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 221 Goodbye... ## T 10.1.10.50:39498 -> 10.1.10.94:21 [R] ...... # T 10.1.10.50:39498 -> 10.1.10.94:21 [R] ......
#### T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 220 (vsFTPd 3.0.3).. ## T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] FEAT.. ## T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 211-Features:.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] EPRT.. EPSV.. MDTM.. PASV.. REST STREAM.. SIZE.. TVFS.. UTF8..211 End.. ## T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] OPTS UTF8 ON.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 200 Always in UTF8 mode... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] USER ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 331 Please specify the password... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] PASS ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 230 Login successful... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] PWD.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 257 "/" is the current directory.. # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] PORT 10,1,10,50,142,235.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 200 PORT command successful. Consider using PASV... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] LIST.. #### T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 150 Here comes the directory listing... # T 10.1.10.94:20 -> 10.1.10.50:36587 [AP] -rw-r--r-- 1 0 00 Oct 02 21:07 test.. ##### T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 226 Directory send OK... ## T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] QUIT.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 221 Goodbye... #### T 10.1.10.50:39500 -> 10.1.10.94:21 [R] ...... # T 10.1.10.50:39500 -> 10.1.10.94:21 [R] ...... # T 10.1.10.50:39500 -> 10.1.10.94:21 [R] ......
On 2 Oct 2016 at 14:45, Gordon Messmer wrote:
Subject: Re: Problem with firewalld/iptables and ftp access list? To: Community support for Fedora users users@lists.fedoraproject.org From: Gordon Messmer gordon.messmer@gmail.com Date sent: Sun, 2 Oct 2016 14:45:23 -0700 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On 10/02/2016 04:48 AM, Michael D. Setzer II wrote:
The modeprobe nf_conntrack_ftp doesn't output any messge or error? Not sure what it is suppose to output.
It shouldn't output anything. In your iptables rules you find these:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A IN_public_allow -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
When an FTP client connects to your server, it connects to port 21 which is allowed by the second rule quoted above. The purpose of the nf_conntrack_ftp module is to examine FTP traffic to determine which new connections should be allowed by the former rule. When a client makes a PASV mode connection, it will make additional connections to high numbered ports for data transfers (including retrieving the output of commands like "LIST"). That connection should be RELATED, and so allowed by the former rule. It seems that for some reason, your system isn't allowing such connections.
I'll note several things.
First, I'm unable to reproduce the problem on a mostly up-to-date Fedora 24 system (still running kernel 4.7.4-200.fc24.x86_64 until I reboot).
Don't know when it exactly started, since I was off-Island for the summer and had remotely upgraded the systems from Fedora 23 to 24. Think I noticed the ftp issue originally in late August or Early September. I generally update machines often, so are currently running the latest kernels with all updates. On main machine, I have a script that uses plink to connect to the other systems and run the updates to keep all machines updated. Some of its options use ftp to download updated files to other systems.
Second, your iptables rules are a mess. For some reason, there are multiple rules allowing connections to TCP ports 21 and 22 in the IN_public_allow chain. I don't know any reason that would be a problem per se, but it probably indicates that something else is wrong with the system.
After I noticed the ftp wasn't working, I tried manually adding the ports to see if it was an issue with the ftp option not doing something, but it made no difference, and just didn't undo it? I had also tried on another system to activate vsftpd and got the same results, so it wasn't something on the main machine?
Third, you definitely should not be running both the iptables and firewalld services, simultaneously.
I was thought that firewalld was actually a front-end to iptables?? When I checked status they are generally both running, but sometimes I seen one listed as dead, but don't recall which one it was or if it may have been both at times.
Fourth, the reason that removing "-A INPUT -j REJECT --reject-with icmp-host-prohibited " from your rules fixes the problem is that removing that rule allows all traffic. firewalld rules, generally, allow traffic indicated by policy first, and then REJECT everything else. When you remove the rule that REJECTS everything else, you're allowing the traffic that's allowed by policy and all other traffic hits the policy which is ACCEPT. Removing that rule is the same as turning off the firewall, except that you still spend the CPU time examining traffic for not reason.
The systems are I7 machine with quad cores and hyperthreading and 8G of Ram running on a 1G ethernet in classroom.
The problem has been confirmed by Ed and by Alfonso, who opened the bug report, but it isn't universal, since it doesn't affect the one system I tested. More details are needed. If it's actually a problem with nf_conntrack_ftp, your kernel version would be helpful, for one. It may also be helpful to get a network capture. I used "ngrep" to capture the following FTP sessions, one PASV and the other PORT.
#### T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 220 (vsFTPd 3.0.3).. ## T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] FEAT.. ## T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 211-Features:.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] EPRT.. EPSV.. MDTM.. PASV.. REST STREAM.. SIZE.. TVFS.. UTF8..211 End.. ## T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] OPTS UTF8 ON.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 200 Always in UTF8 mode... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] USER ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 331 Please specify the password... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] PASS ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 230 Login successful... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] PWD.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 257 "/" is the current directory.. # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] PASV.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 227 Entering Passive Mode (10,1,10,94,114,151)... #### T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] LIST.. # T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 150 Here comes the directory listing... # T 10.1.10.94:29335 -> 10.1.10.50:49489 [AP] -rw-r--r-- 1 0 00 Oct 02 21:07 test.. ##### T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 226 Directory send OK... # T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] QUIT.. ## T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] 221 Goodbye... ## T 10.1.10.50:39498 -> 10.1.10.94:21 [R] ...... # T 10.1.10.50:39498 -> 10.1.10.94:21 [R] ......
#### T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 220 (vsFTPd 3.0.3).. ## T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] FEAT.. ## T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 211-Features:.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] EPRT.. EPSV.. MDTM.. PASV.. REST STREAM.. SIZE.. TVFS.. UTF8..211 End.. ## T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] OPTS UTF8 ON.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 200 Always in UTF8 mode... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] USER ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 331 Please specify the password... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] PASS ftpuser.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 230 Login successful... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] PWD.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 257 "/" is the current directory.. # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] PORT 10,1,10,50,142,235.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 200 PORT command successful. Consider using PASV... # T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] LIST.. #### T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 150 Here comes the directory listing... # T 10.1.10.94:20 -> 10.1.10.50:36587 [AP] -rw-r--r-- 1 0 00 Oct 02 21:07 test.. ##### T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 226 Directory send OK... ## T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] QUIT.. # T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] 221 Goodbye... #### T 10.1.10.50:39500 -> 10.1.10.94:21 [R] ...... # T 10.1.10.50:39500 -> 10.1.10.94:21 [R] ...... # T 10.1.10.50:39500 -> 10.1.10.94:21 [R] ......
I had used wireshark to monitor while doing the connection, but wasn't seeing any traffic between the ls command and the failure. What process were you using to capture the above information??
Again, Thanks for the time. I'm assuming, that this isn't a 100% problem, but might be some specific combinations of things that are causing the issue. I was originally using UnixWare long ago, at the college, and then started with Redhat 9, and have gone thru versions to the latest Fedora 24.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS ABC 16613838.513356 | EINSTEIN 114625025.788695 ROSETTA 49527492.658188 | SETI 92927032.772384
Cleaned up the firewall-config extra port options, and tried it on another machine as well. Did note that after a reboot, it shows nf_conntract_ftp as being loaded, but not being used by anything. If I stop firewalld and start iptables it then shows that it is being used??
firewall-config services checked? dhcpv6-client ftp mdns ssh vnc-server
ports 5979 tcp (used for vnc) 9000 tcp (used by udpcast) 9000 udp 9001 tcp 9001 udp
lsmod | grep nf
nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE nf_conntrack_ftp 16384 0 nf_reject_ipv6 16384 1 ip6t_REJECT nf_conntrack_ipv6 20480 15 nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 nf_nat_ipv6 16384 1 ip6table_nat nf_conntrack_ipv4 16384 15 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv4 16384 1 iptable_nat nf_nat 28672 3 nf_nat_ipv4,nf_nat_ipv6,nf_nat_masquerade_ipv4 nf_conntrack 102400 8 nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_nat_masquerade_ipv4,nf_co nntrack_ftp,nf_conntrack_ipv4,nf_conntrack_ipv6 nfnetlink 16384 1 ip_set binfmt_misc 20480 1 ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-10-03 16:46:13 ChST; 3min 45s ago Docs: man:firewalld(1) Main PID: 5198 (firewalld) Tasks: 3 (limit: 512) CGroup: /system.slice/firewalld.service └─5198 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid
Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete FORWARD --destination 192.168.122.0/24 --out-interface virbr0 --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete FORWARD --source 192.168.122.0/24 --in-interface virbr0 --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete FORWARD --in-interface virbr0 --out-interface virbr0 --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 53 --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 53 --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete OUTPUT --out-interface virbr0 --protocol udp --destination-port 68 --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 67 --jump ACCEPT' failed: Oct 03 16:46:14 d7aa.guamcc.net /firewalld[5198]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: ● iptables.service - IPv4 firewall with iptables Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; vendor preset: disabled) Active: inactive (dead) since Mon 2016-10-03 16:40:51 ChST; 9min ago Process: 4717 ExecStop=/usr/libexec/iptables/iptables.init stop (code=exited, status=0/SUCCESS) Process: 3640 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited, status=0/SUCCESS) Main PID: 3640 (code=exited, status=0/SUCCESS)
Oct 02 21:33:20 d7aa.guamcc.net systemd[1]: Starting IPv4 firewall with iptables... Oct 02 21:33:20 d7aa.guamcc.net iptables.init[3640]: iptables: Applying firewall rules: [ OK ] Oct 02 21:33:20 d7aa.guamcc.net iptables.init[3640]: iptables: Loading additional modules: ip_nat_ftp [ OK ] Oct 02 21:33:20 d7aa.guamcc.net systemd[1]: Started IPv4 firewall with iptables. Oct 03 16:40:50 d7aa.guamcc.net systemd[1]: Stopping IPv4 firewall with iptables... Oct 03 16:40:51 d7aa.guamcc.net iptables.init[4717]: iptables: Setting chains to policy ACCEPT: security mangle raw nat filter [FAILED] Oct 03 16:40:51 d7aa.guamcc.net iptables.init[4717]: iptables: Flushing firewall rules: [ OK ] Oct 03 16:40:51 d7aa.guamcc.net iptables.init[4717]: iptables: Unloading modules: [ OK ] Oct 03 16:40:51 d7aa.guamcc.net systemd[1]: Stopped IPv4 firewall with iptables.
On 10/03/16 15:32, Michael D. Setzer II wrote:
Cleaned up the firewall-config extra port options, and tried it on another machine as well. Did note that after a reboot, it shows nf_conntract_ftp as being loaded, but not being used by anything. If I stop firewalld and start iptables it then shows that it is being used??
FWIW, I think it is now best to simply let the bugzilla process play out.
I say this because I have updated my F23 VM today and after the update it too fails in the same manner as an F24 system. And booting to a previous kernel works.
4.7.5-100.fc23.x86_64 = Fails 4.5.7-202.fc23.x86_64 = Works
It isn't clear that, to me at least, that nf_conntract_ftp is to blame/involved since in all cases that I've tried it shows up as being unused. Additionally, doing an "rmmod nf_conntract_ftp" doesn't change the behavior of either a working case or failing case.
On 3 Oct 2016 at 18:39, Ed Greshko wrote:
From: Ed Greshko ed.greshko@greshko.com Subject: Re: Problem with firewalld/iptables and ftp access list? To: users@lists.fedoraproject.org Date sent: Mon, 3 Oct 2016 18:39:44 +0800 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On 10/03/16 15:32, Michael D. Setzer II wrote:
Cleaned up the firewall-config extra port options, and tried it on another machine as well. Did note that after a reboot, it shows nf_conntract_ftp as being loaded, but not being used by anything. If I stop firewalld and start iptables it then shows that it is being used??
FWIW, I think it is now best to simply let the bugzilla process play out.
I say this because I have updated my F23 VM today and after the update it too fails in the same manner as an F24 system. And booting to a previous kernel works.
4.7.5-100.fc23.x86_64 = Fails 4.5.7-202.fc23.x86_64 = Works
It isn't clear that, to me at least, that nf_conntract_ftp is to blame/involved since in all cases that I've tried it shows up as being unused. Additionally, doing an "rmmod nf_conntract_ftp" doesn't change the behavior of either a working case or failing case.
I had seen the comment on the bugzilla about proftpd and setting up pasv ports, and did the equivalent for vsftpd, and that seems to make it work. Here is what I commented after your comment.
I had gotten the email on comment 4, and tried the same thing with vsftp.
Added to the end of /etc/vsftpd/vsftpd.conf
pasv_min_port=60000 pasv_max_prot=60100
Went into firewall-config and opened those ports as well
Then restarted vsftpd and then restarted machine.
That seems to make it work fine, but not sure what changed from it working before in earlier versions or kernels and now not working? Comment 5 seems to have some more info, but don't know if this is a bug, or a new feature (one must specify passive ports in the server and firewall?).
-- You're Welcome Zachary Quinto _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+
http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
BOINC@HOME CREDITS ABC 16613838.513356 | EINSTEIN 114625025.788695 ROSETTA 49527492.658188 | SETI 92927032.772384
On 10/03/16 19:40, Michael D. Setzer II wrote:
That seems to make it work fine, but not sure what changed from it working before in earlier versions or kernels and now not working? Comment 5 seems to have some more info, but don't know if this is a bug, or a new feature (one must specify passive ports in the server and firewall?).
For sure it is a bug. Going from one kernel to a new one should not break things. The average user or admin shouldn't have to know a magical incantation on a server to make things work though a firewall. Especially when the firewall GUI is implicitly telling you to check a box to make ftp work though the firewall.
-
Ed Greshko -
Gordon Messmer -
Michael D. Setzer II -
Samuel Sieb