Bug 1322856

Summary: invalid_zone error on malfunctioning iptables
Product: [Fedora] Fedora Reporter: Tomas Dolezal <todoleza>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED EOL QA Contact: Tomas Dolezal <todoleza>
Severity: medium Docs Contact:
Priority: high    
Version: 23CC: bblaskov, jpopelka, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-20 19:44:30 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:

Description Tomas Dolezal 2016-03-31 13:04:59 UTC
Description of problem:
malfunctioning iptables/-restore leads to strange behaviour of firewall-cmd. on --list-all invalid_zone error occurs, on --get-zones/--get-services nothing gets printed out.

Version-Release number of selected component (if applicable):
firewalld-0.4.0-2.fc23.noarch with deps on fc22
(previously tested on up-to-date fc22 released 3.x version with same results)

How reproducible:
openvz (vpsfree.cz provider) without "iptables feature fix"

Steps to Reproduce:
firewall-cmd --list-all
firewall-cmd --get-zones

Actual results:
2016-03-31 14:29:22 ERROR: ebtables not usable, disabling ethernet bridge firewall.
2016-03-31 14:29:26 ERROR: INVALID_ZONE
2016-03-31 14:38:21 ERROR: ipset not usable, disabling ipset usage in firewall.
2016-03-31 14:38:21 ERROR: ebtables not usable, disabling ethernet bridge firewall.
2016-03-31 14:39:04 ERROR: ipset not usable, disabling ipset usage in firewall.
2016-03-31 14:39:04 ERROR: ebtables not usable, disabling ethernet bridge firewall.
2016-03-31 14:39:24 ERROR: INVALID_ZONE
2016-03-31 14:39:41 DEBUG1: ipv4 table 'security' does not exist (or not enough permission to check).
2016-03-31 14:39:41 DEBUG1: ipv4 table 'nat' does not exist (or not enough permission to check).
2016-03-31 14:39:41 DEBUG1: ipv6 table 'security' does not exist (or not enough permission to check).
2016-03-31 14:39:41 DEBUG1: ipv6 table 'nat' does not exist (or not enough permission to check).
2016-03-31 14:39:41 DEBUG1: ebtables table 'filter' does not exist.
2016-03-31 14:39:41 DEBUG1: ebtables table 'broute' does not exist.
2016-03-31 14:39:41 DEBUG1: ebtables table 'nat' does not exist.
2016-03-31 14:39:41 DEBUG1: start()
2016-03-31 14:39:41 ERROR: ipset not usable, disabling ipset usage in firewall.
2016-03-31 14:39:41 ERROR: ebtables not usable, disabling ethernet bridge firewall.
2016-03-31 14:39:41 DEBUG1: Loading firewalld config file '/etc/firewalld/firewalld.conf'
2016-03-31 14:39:41 DEBUG1: IPv6 rpfilter is enabled
2016-03-31 14:39:41 DEBUG1: LogDenied is set to 'off'
2016-03-31 14:39:41 DEBUG1: ebtables-restore is not supporting the --noflush option, will therefore not be used
2016-03-31 14:39:41 Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/firewall/server/decorators.py", line 44, in handle_exceptions
    return func(*args, **kwargs)
  File "/usr/lib/python3.4/site-packages/firewall/server/firewalld.py", line 79, in start
    return self.fw.start()
  File "/usr/lib/python3.4/site-packages/firewall/core/fw.py", line 286, in start
    self._start()
  File "/usr/lib/python3.4/site-packages/firewall/core/fw.py", line 191, in _start
    self._apply_default_rules()
  File "/usr/lib/python3.4/site-packages/firewall/core/fw.py", line 601, in _apply_default_rules
    self.__apply_default_rules(ipv)
  File "/usr/lib/python3.4/site-packages/firewall/core/fw.py", line 597, in __apply_default_rules
    self.rules(ipv, rules[ipv])
  File "/usr/lib/python3.4/site-packages/firewall/core/fw.py", line 772, in rules
    return self._ip4tables.set_rules(_rules)
  File "/usr/lib/python3.4/site-packages/firewall/core/ipXtables.py", line 220, in set_rules
    " ".join(args), ret))
ValueError: '/usr/sbin/iptables-restore -n' failed: iptables-restore: line 30 failed

2016-03-31 14:39:45 DEBUG1: getDefaultZone()
2016-03-31 14:39:45 DEBUG1: zone.getActiveZones()
2016-03-31 14:39:45 DEBUG1: getDefaultZone()
2016-03-31 14:39:45 DEBUG1: getZoneSettings()
2016-03-31 14:39:45 ERROR: INVALID_ZONE
2016-03-31 14:52:16 DEBUG1: zone.getZones()
2016-03-31 14:52:35 DEBUG1: getDefaultZone()
2016-03-31 14:52:35 DEBUG1: zone.getActiveZones()
2016-03-31 14:52:35 DEBUG1: getDefaultZone()
2016-03-31 14:52:35 DEBUG1: getZoneSettings()
2016-03-31 14:52:35 ERROR: INVALID_ZONE
2016-03-31 14:52:43 DEBUG1: zone.getZones()
2016-03-31 14:52:46 DEBUG1: listServices()

systemctl status firewalld -l
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: active (running) since Čt 2016-03-31 14:39:41 CEST; 24min ago
 Main PID: 518 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─518 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid --debug

bře 31 14:39:40 todo systemd[1]: Starting firewalld - dynamic firewall daemon...
bře 31 14:39:41 todo systemd[1]: Started firewalld - dynamic firewall daemon.
bře 31 14:39:41 todo /firewalld[518]: ERROR: ipset not usable, disabling ipset usage in firewall.
bře 31 14:39:41 todo /firewalld[518]: ERROR: ebtables not usable, disabling ethernet bridge firewall.
bře 31 14:39:45 todo /firewalld[518]: ERROR: INVALID_ZONE
bře 31 14:52:35 todo /firewalld[518]: ERROR: INVALID_ZONE

Expected results:
1. valid error, e.g. internal, not invalid_zone
2. appropriate error/debug hint in journalctl
3. other commands either working or failing, not doing nothing (--get-*)
3detail: I can imagine printing some status error and loud failing on any command with notification about possible resolution or more info sources.

Additional info:
[root@todo ~]# iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.

Comment 2 Thomas Woerner 2016-03-31 15:29:53 UTC
# iptables -t filter -I INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

is also failing. The system is using a rather old kernel (2.6.32) together with a Fedora-22. The use of the old kernel will require an iptables rebuild. But even then it is not clear that it will be completely usable.

I agree, that firewalld should do additional tests to detect the issue.

Comment 3 Branislav Blaškovič 2016-03-31 15:40:18 UTC
Yes, the kernel version is old but it has almost all new necessary features - they are just backported to this kernel because host is running Scientific Linux 6.

If you have questions about kernel, I can get you answers by asking vpsfree provider.

Comment 4 Fedora End Of Life 2016-11-24 16:19:00 UTC
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.

Comment 5 Fedora End Of Life 2016-12-20 19:44:30 UTC
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.