Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1380168

Summary: Firewalld cause any ftp client to get "host unknown" when go in passive mode connecting with ip address
Product: [Fedora] Fedora Reporter: Alfonso Savio <info>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 24CC: bgvaughan, ed.greshko, fwestpha, mikes, samuel-rhbugs, twoerner
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: firewalld-0.4.4.1-1.fc24 firewalld-0.4.4.2-1.fc25 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-08 17:39:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alfonso Savio 2016-09-28 20:29:04 UTC
Description of problem: ftp clients get "host unknown" when go in passive mode.


Version-Release number of selected component (if applicable):

 
How reproducible:install fedora 24 server. Update. Install prpftpd/vsftpd. Add ftp service to firewalld. Connect with ip address with ftpclient and ask the DIR command....you get "host unknown".


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
The same procedure in Fedora server 23 works. Seems relates to comntrack_ftp module

Comment 1 Alfonso Savio 2016-09-29 07:44:28 UTC
the correct module name is nf_conntrack_ftp

Comment 2 Alfonso Savio 2016-09-29 07:47:42 UTC
the ftpclient dump:

ftp> open 10.104.0.97
Connected to 10.104.0.97 (10.104.0.97).
220 FTP Server ready.
Name (10.104.0.97:alfonso): 
331 Password richiesta per alfonso
Password:
230 Utente alfonso collegato
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
227 Entering Passive Mode (10,104,0,97,166,39).
ftp: connect: No route to host
ftp> 

after stop firewalld

ftp> open 10.104.0.97
Connected to 10.104.0.97 (10.104.0.97).
220 FTP Server ready.
Name (10.104.0.97:alfonso): 
331 Password richiesta per alfonso
Password:
230 Utente alfonso collegato
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
227 Entering Passive Mode (10,104,0,97,136,173).
150 Apertura della connessione dati in modalità ASCII per file list 
drwxrwxr-x   3 alfonso  alfonso        28 Sep 27 12:26 railsprj
226 Trasferimento completato
ftp>

Comment 3 Michael Setzer II 2016-10-02 14:05:29 UTC
I had a similar situation. I had been using ftp with Fedora 23 and earlier, but never had an issue. After upgrading to Fedora 24, I've had an issue with the connection working, but listing not. I had found that stopping the firewalld and iptables did get it to work fine, but the other day was able to isolate the line in the iptables that is causing the issue, but don't know why it works with the line commented out, but not with it.

The line is number 138 in my iptables file. 

### -A INPUT -j REJECT --reject-with icmp-host-prohibited 

[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 / >

Comment 4 Alfonso Savio 2016-10-03 09:04:05 UTC
I solved this iussue by specifing the passive port range in the ftp server configuration file and adding port 21 and the port range in the firewalld configuration.

add in etc/proftpd.conf

PassivePorts 60000 65535

then 

firewall-cmd --add-port=21/tcp
firewall-cmd --add-port=60000-65535/tcp

Now ftp clients works fine

So adding the ftp service in the firewalld configuration is not more enough to let the ftpserver works.

Comment 5 Ed Greshko 2016-10-03 10:54:38 UTC
That is, of course, a workaround.

Some minor testing on an F23 VM and vsftpd as the server and an F24 ftp client.

The kernel version is, maybe obviously, an important clue.

4.7.5-100.fc23.x86_64  =  Fails
4.5.7-202.fc23.x86_64  =  Works

And, for the record, in the failing case the server is sending back an icmp type 3 (destination unreachable), code 10 (host administratively prohibited) packet in response to the "ls" command from the client.

Comment 6 Michael Setzer II 2016-10-03 11:31:37 UTC
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?).

Comment 7 Alfonso Savio 2016-10-03 12:30:31 UTC
It seems like Fedora 24 is more secure: in Fedora 23 you do not have to specify ports after adding the ftp service in firewalld, in Fedora 24 you have to  specify ports for passive mode.
However the bug was opened for ftp servers on Fedora 24.
Fedora 23 is just for comparison with same configuration.

Comment 8 poma 2016-10-03 12:39:48 UTC
WORKSFORME:
https://bugzilla.redhat.com/show_bug.cgi?id=1376378

Fascinating, it works even without "ftp contractor":
/etc/modprobe.d/bl_conntrack.conf
blacklist nf_conntrack_ftp
blacklist nf_conntrack_ipv4
blacklist nf_defrag_ipv4
blacklist xt_conntrack
blacklist nf_conntrack
blacklist xt_state

Tested with various FTP servers/clients, iptables/netfilter utilities,
and kernels.

Comment 9 Thomas Woerner 2016-10-04 12:00:56 UTC
(In reply to Alfonso Savio from comment #4)
> I solved this iussue by specifing the passive port range in the ftp server
> configuration file and adding port 21 and the port range in the firewalld
> configuration.
> 
> add in etc/proftpd.conf
> 
> PassivePorts 60000 65535
> 
> then 
> 
> firewall-cmd --add-port=21/tcp
> firewall-cmd --add-port=60000-65535/tcp
> 
> Now ftp clients works fine
> 
> So adding the ftp service in the firewalld configuration is not more enough
> to let the ftpserver works.

Is nf_conntrack_ftp loaded?

Comment 10 Michael Setzer II 2016-10-04 13:10:23 UTC
On my system with the changes made for vsftpd it shows it is loaded, but used by 0?

Module                  Size  Used by
cfg80211              569344  0
rfkill                 24576  2 cfg80211
fuse                  102400  5
xt_CHECKSUM            16384  1
ipt_MASQUERADE         16384  3
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
tun                    28672  1
nf_conntrack_ftp       16384  0
ip6t_REJECT            16384  2
nf_reject_ipv6         16384  1 ip6t_REJECT
ip6t_rpfilter          16384  1
xt_conntrack           16384  30
ip_set                 36864  0
nfnetlink              16384  1 ip_set
ebtable_broute         16384  1
bridge                131072  1 ebtable_broute
stp                    16384  1 bridge
llc                    16384  2 stp,bridge
ebtable_nat            16384  1
ip6table_security      16384  1
ip6table_nat           16384  1
nf_conntrack_ipv6      20480  16
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
nf_nat_ipv6            16384  1 ip6table_nat
ip6table_raw           16384  1
ip6table_mangle        16384  1
iptable_security       16384  1
iptable_nat            16384  1
nf_conntrack_ipv4      16384  16
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_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_raw            16384  1
iptable_mangle         16384  1
ebtable_filter         16384  1
ebtables               32768  3 ebtable_broute,ebtable_nat,ebtable_filter
ip6table_filter        16384  1
ip6_tables             28672  5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw
snd_hda_codec_realtek    86016  1
snd_hda_codec_generic    73728  1 snd_hda_codec_realtek
snd_hda_codec_hdmi     45056  1
snd_hda_intel          36864  7
snd_hda_codec         126976  4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
snd_hda_core           81920  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep              16384  1 snd_hda_codec
intel_rapl             20480  0
x86_pkg_temp_thermal    16384  0
intel_powerclamp       16384  0
coretemp               16384  0
kvm_intel             188416  0
snd_seq                69632  0
snd_seq_device         16384  1 snd_seq
snd_pcm               118784  4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
kvm                   573440  1 kvm_intel
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt
irqbypass              16384  1 kvm
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
ghash_clmulni_intel    16384  0
intel_cstate           16384  0
intel_uncore          110592  0
snd_timer              32768  2 snd_pcm,snd_seq
snd                    77824  24 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
intel_rapl_perf        16384  0
lpc_ich                24576  0
ppdev                  20480  0
i2c_i801               20480  0
soundcore              16384  1 snd
mei_me                 32768  0
mei                    98304  1 mei_me
shpchp                 36864  0
tpm_tis                20480  0
tpm                    40960  1 tpm_tis
parport_pc             28672  0
parport                49152  2 ppdev,parport_pc
wmi                    16384  0
vboxpci                24576  0
vboxnetadp             28672  0
vboxnetflt             28672  0
vboxdrv               434176  3 vboxnetadp,vboxnetflt,vboxpci
binfmt_misc            20480  1
i915                 1306624  6
i2c_algo_bit           16384  1 i915
drm_kms_helper        143360  1 i915
drm                   344064  7 i915,drm_kms_helper
crc32c_intel           24576  0
serio_raw              16384  0
r8169                  81920  0
mii                    16384  1 r8169
fjes                   28672  0
video                  40960  1 i915

Comment 11 Alfonso Savio 2016-10-04 13:15:57 UTC
dump of modules:

cat /proc/modules | grep conntrack
nf_conntrack_ftp 16384 0 - Live 0xffffffffc041d000
xt_conntrack 16384 22 - Live 0xffffffffc0409000
nf_conntrack_ipv6 20480 12 - Live 0xffffffffc039c000
nf_defrag_ipv6 36864 1 nf_conntrack_ipv6, Live 0xffffffffc038e000
nf_conntrack_ipv4 16384 12 - Live 0xffffffffc035a000
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4, Live 0xffffffffc0375000
nf_conntrack 102400 7 nf_conntrack_ftp,xt_conntrack,nf_conntrack_ipv6,nf_nat_ipv6,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat, Live 0xffffffffc0340000

Yes 
nf_conntrack_ftp 16384 0 - Live 0xffffffffc041d000
is loaded

Comment 12 Ed Greshko 2016-10-04 13:25:12 UTC
Same here, it is loaded.

[egreshko@f24 ~]$ lsmod | grep ftp
nf_conntrack_ftp       16384  0
nf_conntrack          102400  7 nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_ipv6

Comment 13 Florian Westphal 2016-10-08 08:32:27 UTC
Note that kernel 4.7 disabled helper auto-assignment:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3bb398d925ec73e42b778cf823c8f4aecae359ea

explicit assign rule (on ftp servers):

iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp

... or load nf_conntrack module with nf_conntrack_helper arg set to 1

Comment 14 Ed Greshko 2016-10-09 03:34:50 UTC
After reading comment #13 and https://bugzilla.redhat.com/show_bug.cgi?id=1369489 I entered:

net.netfilter.nf_conntrack_helper = 1

into /etc/sysctl.conf and executed "sysctl -p".  This then allow "ls" and "dir" commands to work.

One oddity.  Even though with the entry in /etc/sysctl.conf a reboot failed to set the kernel parameter.  I had to execute "sysctl -p". after booting.  I don't know if this is a failure (designed?) in systemd-sysctl.service or something else.

Comment 15 Florian Westphal 2016-10-10 08:56:07 UTC
(In reply to Ed Greshko from comment #14)
> After reading comment #13 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1369489 I entered:
> 
> net.netfilter.nf_conntrack_helper = 1
> 
> into /etc/sysctl.conf and executed "sysctl -p".  This then allow "ls" and
> "dir" commands to work.
> 
> One oddity.  Even though with the entry in /etc/sysctl.conf a reboot failed
> to set the kernel parameter.  I had to execute "sysctl -p". after booting.

This sysctl gets registered when the conntrack module is loaded, setting the option in a /etc/modprobe.d/ file should work.

Longterm explicit config via ruleset will be needed.

Comment 16 Ed Greshko 2016-10-10 14:09:16 UTC
I would like to test the /etc/modprobe.d/ method but I can't seem to figure out the proper incantation.  Suggestion?

Comment 17 Florian Westphal 2016-10-10 14:31:49 UTC
(In reply to Ed Greshko from comment #16)
> I would like to test the /etc/modprobe.d/ method but I can't seem to figure
> out the proper incantation.  Suggestion?

Untested, create file nf_conntrack.conf in /etc/modprobe.d with content:

options nf_conntrack nf_conntrack_helper=1

Comment 18 Ed Greshko 2016-10-10 14:59:49 UTC
Does not seem to work....

[root@acer netfilter]# rmmod nf_conntrack_ftp
[root@acer netfilter]# cat /etc/modprobe.d/nf_conntrack_ftp.conf
options nf_conntrack nf_conntrack_helper=1
[root@acer netfilter]# modprobe nf_conntrack_ftp

[egreshko@meimei ~]$ ftp acer
Connected to acer (192.168.1.143).
220 (vsFTPd 3.0.3)
Name (acer:egreshko): 
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (192,168,1,143,50,24).
ftp: connect: No route to host

[root@acer ~]# cat /proc/sys/net/netfilter/nf_conntrack_helper
0

Comment 19 poma 2016-10-10 18:38:17 UTC
For the record;

# grep conntrack /etc/sysconfig/iptables-config
IPTABLES_MODULES="nf_conntrack_ftp"

# cat /etc/modprobe.d/nf_conntrack_ftp.conf
options nf_conntrack nf_conntrack_helper=1

$ dmesg -t | grep conntrack
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.


A few related links, mentioned herein:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1556419

- netfilter: nf_ct_helper: allow to disable automatic helper assignment
  https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a900689

- Secure use of iptables and connection tracking helpers
  http://www.netfilter.org/news.html#2012-04-03
  https://home.regit.org/netfilter-en/secure-use-of-helpers

- iptables connection tracking helpers
  http://www.odi.ch/weblog/posting.php?posting=663

Comment 20 poma 2016-10-10 20:35:45 UTC
Beside https://github.com/t-woerner/firewalld/blob/master/TODO#L10

Furthermore, firewalld already defines the aforementioned kernel module
i.e. nf_conntrack_ftp
https://github.com/t-woerner/firewalld/blob/master/config/services/ftp.xml#L6

such as it can be defined in the iptables utility example.

In my tests it works, in both cases,
therefore 2nd WORKSFORME ;)

Bye

Comment 21 Michael Setzer II 2016-10-10 21:09:29 UTC
(In reply to poma from comment #20)
> Beside https://github.com/t-woerner/firewalld/blob/master/TODO#L10
> 
> Furthermore, firewalld already defines the aforementioned kernel module
> i.e. nf_conntrack_ftp
> https://github.com/t-woerner/firewalld/blob/master/config/services/ftp.xml#L6
> 
> such as it can be defined in the iptables utility example.
> 
> In my tests it works, in both cases,
> therefore 2nd WORKSFORME ;)
> 
> Bye

What Kernel are you running?? It was working for all of use before, but seems to be the latest 4.7.x kernels that have caused the issue? 

Are you running an older kernel? 
Is it perhaps that a later kernel update may have fixed issue?

It also, does seem to work, if one has assigned specific passive ports for the ftp server, and opened those exact ports in firewall? Have you done that?

It was working without that requirement before, so is that a new requirement that needs to be manually done by all users that wasn't required before???

Comment 22 Ed Greshko 2016-10-11 00:26:33 UTC
FWIW, my procedure of "rmmod, modprobe" was ineffective as I noted above.  However, I just updated my system and rebooted and sure enough the additional option added to the module was successful.

So, the addition of /etc/modprobe.d/nf_conntrack_ftp.conf is an acceptable workaround at this time.

Comment 23 poma 2016-10-11 15:35:31 UTC
(In reply to Michael Setzer II from comment #21)
> (In reply to poma from comment #20)
[...]
> What Kernel are you running?? It was working for all of use before, but
> seems to be the latest 4.7.x kernels that have caused the issue? 
> 

Various, stock and patched kernels.

> Are you running an older kernel? 
> Is it perhaps that a later kernel update may have fixed issue?
> 

From Fedora's kernel POV,
automatic conntrack helper assignment works(Out of the box) with:
...
4.6.7-300.fc24.x86_64
...
4.7.0-0.rc0.git2.2.fc25

and it's gone, starting with:
4.7.0-0.rc0.git3.1.fc25

> It also, does seem to work, if one has assigned specific passive ports for
> the ftp server, and opened those exact ports in firewall? Have you done that?
> 

That's right, with specified a narrow port range to assist firewalling for PASV style data connections, it should work by itself.

> It was working without that requirement before, so is that a new requirement
> that needs to be manually done by all users that wasn't required before???

You can consider this issue as security related enhancement (upstream), and work to do on implementation (downstream - firewalld).

If you need to regress:
/etc/modprobe.d/nf_conntrack_ftp.conf
options nf_conntrack nf_conntrack_helper=1


p.s.
Also related:
- https://bugzilla.redhat.com/show_bug.cgi?id=906156
- https://github.com/t-woerner/firewalld/issues/5
- https://bugzilla.redhat.com/show_bug.cgi?id=892801

Comment 24 Michael Setzer II 2016-10-11 15:57:02 UTC
But the question is why did it always work for many many years with no issues, and now it is failing? Something had to change to make something that was always working, to become flaky??  So the current latest kernel is 4.7.6-200 on my classroom systems. Is that kernel fixed??

Comment 25 poma 2016-10-11 16:44:14 UTC
(In reply to Michael Setzer II from comment #24)
> But the question is why did it always work for many many years with no
> issues, and now it is failing? Something had to change to make something
> that was always working, to become flaky??  So the current latest kernel is
> 4.7.6-200 on my classroom systems. Is that kernel fixed??

Please take into account that I am here only the user, the same as you. ;)

You can draw your own conclusion after already written, and repeated here

- netfilter: nf_ct_helper: allow to disable automatic helper assignment
  https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a900689
  2012-05-08
  <quote>
  ...
  There are good reasons to stop supporting automatic helper assignment, for further information, please read: http://www.netfilter.org/news.html#2012-04-03
  ...
  </quote>

- netfilter: nf_ct_helper: disable automatic helper assignment
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3bb398d
  2016-04-25
  <quote>
  ...
  Give the time we have waited for this, let's turn off this by default now, worse case users still have a chance to recover the former behaviour by explicitly enabling this back through sysctl.
  </quote>

If you have questions, you can try to contact the authors-developers,
Eric Leblond and Pablo Neira Ayuso.

The netfilter user mailinglist
http://www.netfilter.org/mailinglists.html#ml-user

The netfilter bug tracking system
http://www.netfilter.org/contact.html#bugzilla

Comment 26 poma 2016-10-11 19:53:37 UTC
This should be emphasized:
- conntrack helpers in kernel 4.7
  https://marc.info/?l=netfilter&m=147091528621183&w=2
  <quote>
  You can still recover the old automagic behaviour [...]
  [...]
  But that will go away too at some point given this behaviour is
  unsecure as the document above describes, so please don't give up on
  upgrading your ruleset.
  </quote>

I hope this feature will be implemented within the firewalld, on time.

Addio ragazzi

Comment 27 Thomas Woerner 2016-10-12 10:55:52 UTC
I am working on this for firewalld already. I already have a patch to make this work for tests and am working on a real solution that can be used for all conntrack helpers - even those that are not used in services at the moment.

Comment 28 Thomas Woerner 2016-11-10 17:36:29 UTC
Please have a look at firewalld version 0.4.4.1. This will be available in testing soon and should fix this issue.

Comment 29 Fedora Update System 2016-11-10 17:42:43 UTC
firewalld-0.4.4.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2828a4793

Comment 30 Fedora Update System 2016-11-10 17:43:15 UTC
firewalld-0.4.4.1-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8d90406113

Comment 31 Fedora Update System 2016-11-10 17:43:28 UTC
firewalld-0.4.4.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c57b0ba2d4

Comment 32 Fedora Update System 2016-11-11 04:23:43 UTC
firewalld-0.4.4.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2828a4793

Comment 33 Fedora Update System 2016-11-11 05:03:19 UTC
firewalld-0.4.4.1-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c57b0ba2d4

Comment 34 Fedora Update System 2016-11-11 16:56:27 UTC
firewalld-0.4.4.1-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8d90406113

Comment 35 Ed Greshko 2016-11-12 01:05:02 UTC
I installed 

firewall-applet-0.4.4.1-1.fc25.noarch.rpm
firewall-config-0.4.4.1-1.fc25.noarch.rpm
firewalld-0.4.4.1-1.fc25.noarch.rpm
firewalld-filesystem-0.4.4.1-1.fc25.noarch.rpm
python3-firewall-0.4.4.1-1.fc25.noarch.rpm
python-firewall-0.4.4.1-1.fc25.noarch.rpm

on a system with 

[root@acer ~]# uname -r
4.8.6-300.fc25.x86_64

I am unable to ftp to this system.

[egreshko@meimei ~]$ ftp acer
ftp: connect: No route to host
ftp> quit

Bringing up firewall-config and trying to unset/set the ftp service I get the error message.

INVALID_HELPER: 'nf_conntrack_ftp' not available in kernel

Comment 36 Fedora Update System 2016-11-12 23:55:42 UTC
firewalld-0.4.4.1-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 37 Ed Greshko 2016-11-13 03:10:34 UTC
Tested on a fully updated F24 system.  Problem noted in "comment 35" also exists.

Comment 38 Brian Vaughan 2016-11-14 22:01:01 UTC
Similarly, following full update and reboot, with firewalld 0.4.4.1,

root@n0113:0:~
# firewall-cmd --add-service=ftp
Error: INVALID_HELPER: 'nf_conntrack_ftp' not available in kernel

Comment 39 Fedora Update System 2016-12-01 14:53:29 UTC
firewalld-0.4.4.2-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dd8b5f4e1

Comment 40 Fedora Update System 2016-12-01 14:54:25 UTC
firewalld-0.4.4.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b566ecf579

Comment 41 Fedora Update System 2016-12-03 04:28:56 UTC
firewalld-0.4.4.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b566ecf579

Comment 42 Fedora Update System 2016-12-03 04:35:09 UTC
firewalld-0.4.4.2-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dd8b5f4e1

Comment 43 Fedora Update System 2016-12-04 02:27:37 UTC
firewalld-0.4.4.2-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 44 Fedora Update System 2016-12-05 17:37:58 UTC
firewalld-0.4.4.2-2.fc23 selinux-policy-3.13.1-158.25.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8a0533d057

Comment 45 Fedora Update System 2016-12-13 05:25:14 UTC
firewalld-0.4.4.2-2.fc23, selinux-policy-3.13.1-158.25.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8a0533d057

Comment 46 Fedora End Of Life 2017-07-25 23:16:19 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 47 Fedora End Of Life 2017-08-08 17:39:41 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.