Description of problem: If I start the firewall gui (i.e. firewall-config) and select Options->Reload Firewall a dialogue box pops up with the message 'NoneType' object has no attribute 'query_rule'. This is bad for several reasons: 1) As a user, what am I supposed to do with that information? 2) Did the firewall reload or not? 3) What state is my firewall in now? So, as well as this needing fixing, I think there's a bigger problem in general with how errors are being reported to the user. Version-Release number of selected component (if applicable): firewalld-0.3.14.2-4.fc22.noarch firewall-config-0.3.14.2-4.fc22.noarch How reproducible: Everytime
Do you see this in the firewalld log file in /var/log/firewalld? Please attach the log to this bugzilla.
This is what I see in the log when I do a reload: 2015-10-26 13:41:31 WARNING: FedoraServer: INVALID_SERVICE: cockpit 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table mangle --delete POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' failed: iptables: No chain/target/match by that name. 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table nat --delete POSTROUTING --source 192.168.122.0/24 --destination 224.0.0.0/24 --jump RETURN' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table nat --delete POSTROUTING --source 192.168.122.0/24 --destination 255.255.255.255/32 --jump RETURN' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table nat --delete POSTROUTING --source 192.168.122.0/24 -p tcp ! --destination 192.168.122.0/24 --jump MASQUERADE --to-ports 1024-65535' failed: iptables: No chain/target/match by that name. 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table nat --delete POSTROUTING --source 192.168.122.0/24 -p udp ! --destination 192.168.122.0/24 --jump MASQUERADE --to-ports 1024-65535' failed: iptables: No chain/target/match by that name. 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table nat --delete POSTROUTING --source 192.168.122.0/24 ! --destination 192.168.122.0/24 --jump MASQUERADE' failed: iptables: No chain/target/match by that name. 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --destination 192.168.122.0/24 --out-interface virbr0 --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --source 192.168.122.0/24 --in-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --in-interface virbr0 --out-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name. 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name. 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete OUTPUT --out-interface virbr0 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:32 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). 2015-10-26 13:41:37 ERROR: NOT_ENABLED: rule '('-p', 'tcp', '-m', 'multiport', '--dports', 'ssh', '-m', 'set', '--match-set', 'fail2ban-sshd', 'src', '-j', 'REJECT', '--reject-with', 'icmp-port-unreachable')' is not in 'ipv4:filter:INPUT'
The reported errors in the log are the clean up calls of libvirt that are expected to fail while reloading. libvirt is not checking if rules exist, it is simply trying to delete them, which then fails if the rules are not there. Also there is in a failed rule of fail2ban, which is a bit unexpected. Is it possible to attach your configuration from /etc/firewalld to this bugzilla for verification? I do not see this error if libvirt and also fail2ban is enabled. Please also add the output of 'rpm -qa "*firewall*"' and 'rpm -Va "*firewall*"'
# rpm -qa "*firewall*" firewalld-filesystem-0.3.14.2-4.fc22.noarch firewall-config-0.3.14.2-4.fc22.noarch python-firewall-0.3.14.2-4.fc22.noarch fail2ban-firewalld-0.9.3-1.fc22.noarch python3-firewall-0.3.14.2-4.fc22.noarch firewalld-0.3.14.2-4.fc22.noarch # rpm -Va "*firewall*" <nothing> This is what's in /etc/firewalld/firewalld.conf: # firewalld config file # default zone # The default zone used if an empty zone string is used. # Default: public DefaultZone=public # Minimal mark # Marks up to this minimum are free for use for example in the direct # interface. If more free marks are needed, increase the minimum # Default: 100 MinimalMark=100 # Clean up on exit # If set to no or false the firewall configuration will not get cleaned up # on exit or stop of firewalld # Default: yes CleanupOnExit=yes # Lockdown # If set to enabled, firewall changes with the D-Bus interface will be limited # to applications that are listed in the lockdown whitelist. # The lockdown whitelist file is lockdown-whitelist.xml # Default: no Lockdown=no # IPv6_rpfilter # Performs a reverse path filter test on a packet for IPv6. If a reply to the # packet would be sent via the same interface that the packet arrived on, the # packet will match and be accepted, otherwise dropped. # The rp_filter for IPv4 is controlled using sysctl. # Default: yes IPv6_rpfilter=yes Did you want all the other files under /etc/firewalld too?
Yes, please add the other files too, as there seems to be the source somewhere.
Created attachment 1088539 [details] /etc/firewalld directory I've attached a tar ball of the /etc/firewalld directory. The only changes I've made to the firewall have been through the GUI.
I'm also experiencing this error from command line: # firewall-cmd --permanent --add-port=9050/tcp success # firewall-cmd --reload Error: 'NoneType' object has no attribute 'query_rule' # firewall-cmd --add-port=9050/tcp success # rpm -q firewalld firewalld-0.3.14.2-4.fc23.noarch
Actually I do not think it is related directly to the content of the configuration files. It seems to be the triggered by some run-time state of some kind. Below is an example where after restarting the service with systemctl the reload command works ok. The content of /etc/firewalld was exactly the same before and after. (Ignore the ERROR log line below, it was just the result of a permanent remove command of a non-permanent service) (root) myhost:/share/root/2016/firewall-config>systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2016-02-04 21:32:12 CET; 1 weeks 5 days ago Main PID: 822 (firewalld) CGroup: /system.slice/firewalld.service └─822 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid Feb 04 21:32:11 myhost.domain systemd[1]: Starting firewalld - dynamic firewall daemon... Feb 04 21:32:12 myhost.domain systemd[1]: Started firewalld - dynamic firewall daemon. Feb 16 22:06:07 myhost.domain firewalld[822]: 2016-02-16 22:06:07 ERROR: NOT_ENABLED: http (root) myhost:/share/root/2016/firewall-config>firewall-cmd --reload Error: 'NoneType' object has no attribute 'query_rule' (root) myhost:/share/root/2016/firewall-config>systemctl restart firewalld (root) myhost:/share/root/2016/firewall-config>systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2016-02-16 22:23:25 CET; 2s ago Main PID: 14608 (firewalld) CGroup: /system.slice/firewalld.service └─14608 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid Feb 16 22:23:25 myhost.domain systemd[1]: Starting firewalld - dynamic firewall daemon... Feb 16 22:23:25 myhost.domain systemd[1]: Started firewalld - dynamic firewall daemon. (root) myhost:/share/root/2016/firewall-config>firewall-cmd --reload success (root) myhost:/share/root/2016/firewall-config>
This condition seems to be triggered once a direct firewall rule is added. I see the same thing on my Fedora 22 server once I add a direct rule via firewall-cmd, for example: # firewall-cmd --reload success # firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m tcp --dport=2379 -j DROP success # firewall-cmd --reload Error: 'NoneType' object has no attribute 'query_rule' Restarting firewalld seems to clear the error in my case (likely because I didn't save the change with the --permanent option)
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.