6:37 p.m.
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
7:34 p.m.
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.
7:53 p.m.
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(a)lists.fedoraproject.org>
From: Samuel Sieb <samuel(a)sieb.net>
Date sent: Sat, 1 Oct 2016 17:34:13 -0700
Send reply to: Community support for Fedora users
<users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
11:55 p.m.
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
--
You're Welcome Zachary Quinto
2:17 a.m.
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.
--
You're Welcome Zachary Quinto
3:14 a.m.
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.
--
You're Welcome Zachary Quinto
6:48 a.m.
On 2 Oct 2016 at 16:14, Ed Greshko wrote:
From: Ed Greshko <ed.greshko(a)greshko.com>
Subject: Re: Problem with firewalld/iptables and ftp access list?
To: Fedora <users(a)lists.fedoraproject.org>
Date sent: Sun, 2 Oct 2016 16:14:48 +0800
Send reply to: Community support for Fedora users
<users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
7:04 a.m.
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.
--
You're Welcome Zachary Quinto
9:11 a.m.
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.
--
You're Welcome Zachary Quinto
4:45 p.m.
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]
......
7:18 p.m.
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(a)lists.fedoraproject.org>
From: Gordon Messmer <gordon.messmer(a)gmail.com>
Date sent: Sun, 2 Oct 2016 14:45:23 -0700
Send reply to: Community support for Fedora users
<users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
2:32 a.m.
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.
5:39 a.m.
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.
--
You're Welcome Zachary Quinto
6:40 a.m.
On 3 Oct 2016 at 18:39, Ed Greshko wrote:
From: Ed Greshko <ed.greshko(a)greshko.com>
Subject: Re: Problem with firewalld/iptables and ftp access list?
To: users(a)lists.fedoraproject.org
Date sent: Mon, 3 Oct 2016 18:39:44 +0800
Send reply to: Community support for Fedora users
<users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
6:48 a.m.
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.
--
You're Welcome Zachary Quinto
2755
days inactive
2757
days old
15 comments
4 participants
participants (4)
-
Ed Greshko -
Gordon Messmer -
Michael D. Setzer II -
Samuel Sieb