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: | firewalld | Assignee: | Thomas Woerner <twoerner> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 24 | CC: | 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
the correct module name is nf_conntrack_ftp 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> 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 / > 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. 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. 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?). 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. 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. (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? 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 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 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 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 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. (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. I would like to test the /etc/modprobe.d/ method but I can't seem to figure out the proper incantation. Suggestion? (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 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 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 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 (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??? 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. (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 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?? (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 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 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. Please have a look at firewalld version 0.4.4.1. This will be available in testing soon and should fix this issue. firewalld-0.4.4.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d2828a4793 firewalld-0.4.4.1-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8d90406113 firewalld-0.4.4.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c57b0ba2d4 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 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 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 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 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. Tested on a fully updated F24 system. Problem noted in "comment 35" also exists. 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 firewalld-0.4.4.2-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dd8b5f4e1 firewalld-0.4.4.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b566ecf579 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 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 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. 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 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 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. 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. |