Bug 1239326

Summary: DefaultZone of firewalld.conf is not honored by firewalld service
Product: [Fedora] Fedora Reporter: Alexey Pakseykin <uvsmtid>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: jpopelka, twoerner, uvsmtid, wdh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: firewalld-0.4.0-2.fc23 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-21 16:30:48 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:
Attachments:
Description Flags
/var/log/firewalld
none
/etc/firewalld/firewalld.conf none

Description Alexey Pakseykin 2015-07-05 18:35:24 UTC
Description of problem:

Every time `firewalld` restarts its zone switches to `public`
regardless of what `DefaultZone` says in `firewall.conf` file.

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

```
rpm -qi firewalld
Name        : firewalld
Version     : 0.3.14.2
Release     : 2.fc22
Architecture: noarch
Install Date: Wed 24 Jun 2015 03:09:10 AM SGT
Group       : Unspecified
Size        : 1423952
License     : GPLv2+
Signature   : RSA/SHA256, Fri 19 Jun 2015 03:29:52 AM SGT, Key ID 11adc0948e1431d5
Source RPM  : firewalld-0.3.14.2-2.fc22.src.rpm
Build Date  : Thu 18 Jun 2015 11:56:14 PM SGT
Build Host  : buildhw-02.phx2.fedoraproject.org
...
```

Steps to Reproduce:

1. Set `DefaultZone` in `/etc/firewalld/firewalld.conf` file to `trusted`:
```
grep -r DefaultZone /etc/firewalld/firewalld.conf
DefaultZone=trusted
```

2. Restart `firewalld` service.
```
systemctl restart firewalld
```

3. Check current default zone.
```
firewall-cmd --get-default-zone
```

Actual results:

Default zone is always public after `firewalld` restart.

Expected results:

Default zone after `firewalld` restart should match `DefaultZone` parameter in configuration file.

Additional info:

Note that there doesn't seem to exist any interface which sets its own firewall ZONE environment variable:
```
grep -r ZONE /etc/sysconfig/network-scripts/
/etc/sysconfig/network-scripts/ifup-eth:    /usr/bin/firewall-cmd --zone="${ZONE}" --change-interface="${DEVICE}" > /dev/null 2>&1
/etc/sysconfig/network-scripts/ifup-post:    /usr/bin/firewall-cmd --zone="${ZONE}" --change-interface="${DEVICE}" > /dev/null 2>&1
```

The test can be repeated with visual configuration using `firewall-config`.
- Set `Configuration` to `Permanent` for configuration to survive restart.
- Set `Options` -> `Change Default Zone` to `work`, for example.
  Notice how current zone in `Zone` list switches to `work`.
- Set `Options` -> `Reload Firewall`.
  Notice how current zone in `Zone` list switches back to `public`.

Comment 1 Thomas Woerner 2015-07-06 11:23:26 UTC
Are there any errors reported by firewalld?

Please add the output of "systemctl status firewalld -l"

Comment 2 Alexey Pakseykin 2015-07-06 14:34:53 UTC
Yes, indeed (see below).
I have several machines which consistently report these errors.
But I haven't digged into reason. The `virbr0` is created by Vagrant/libvirt plugin.

Command:
systemctl status firewalld -l

Output:
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2015-07-06 21:14:40 SGT; 6min ago
 Main PID: 25135 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─25135 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 ERROR: COMMAND_FAILED: '/sbin/iptables -w --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 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?).
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 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?).
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 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?).
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 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?).
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 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?).
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 ERROR: COMMAND_FAILED: '/sbin/ip6tables -w --table filter --delete FORWARD --in-interface virbr0 --out-interface virbr0 --jump ACCEPT' failed: ip6tables: Bad rule (does a matching rule exist in that chain?).
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 ERROR: COMMAND_FAILED: '/sbin/ip6tables -w --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: ip6tables: No chain/target/match by that name.
Jul 06 21:14:41 projector firewalld[25135]: 2015-07-06 21:14:41 ERROR: COMMAND_FAILED: '/sbin/ip6tables -w --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: ip6tables: No chain/target/match by that name.

Comment 3 Thomas Woerner 2015-07-06 15:13:11 UTC
Please add FIREWALLD_ARGS=--debug in /etc/sysconfig/firewalld
Reboot and attach /var/log/firewalld

The firewalld config file seems to be ignored somehow. There might be an error in the file or it is not accessible, which results in the fallback settings if the config file is missing.

Comment 4 Alexey Pakseykin 2015-07-06 15:54:08 UTC
Created attachment 1048874 [details]
/var/log/firewalld


> cat /etc/sysconfig/firewalld
# firewalld command line args
# possible values: --debug
FIREWALLD_ARGS='--debug'

> reboot # ~ 2015-07-06 23:42:18

> # /var/log/firewalld attached (head truncated to 2015-07-06)

Comment 5 Thomas Woerner 2015-07-06 16:05:40 UTC
There is an error in your config file: 

2015-07-06 21:14:40 ERROR: IPv6_rpfilter '' is not valid, using default value True
2015-07-06 21:14:40 WARNING: Using fallback firewalld configuration settings.

Please use one of "yes", "true", "no", "false".

Comment 6 Alexey Pakseykin 2015-07-06 17:24:19 UTC
Created attachment 1048893 [details]
/etc/firewalld/firewalld.conf

Hmm... In short, the issue does not go away.

I noticed that none of the config files actually contain _uncommented_ setting of `IPv6_rpfilter` variable to nothing.

grep -r IPv6_rpfilter /etc/firewalld/
/etc/firewalld/firewalld.conf:# IPv6_rpfilter
/etc/firewalld/firewalld.conf:#   ERROR: Invalid option: 'IPv6_rpfilter=yes'
/etc/firewalld/firewalld.conf:#IPv6_rpfilter=yes
/etc/firewalld/firewalld-workstation.conf:# IPv6_rpfilter
/etc/firewalld/firewalld-workstation.conf:#   ERROR: Invalid option: 'IPv6_rpfilter=yes'
/etc/firewalld/firewalld-workstation.conf:#IPv6_rpfilter=yes
/etc/firewalld/firewalld-server.conf:# IPv6_rpfilter
/etc/firewalld/firewalld-server.conf:IPv6_rpfilter=yes
/etc/firewalld/firewalld-standard.conf:# IPv6_rpfilter
/etc/firewalld/firewalld-standard.conf:IPv6_rpfilter=yes

So, at least warnings in in the `/var/log/firewalld` are groundless - they should not exist. :/

I removed all seemingly valid setting to `yes` from every file
under `/etc/firewalld` file (including comments as well to make it clean):
> grep -r IPv6_rpfilter /etc/firewalld/
# no output

> systemctl restart firewalld

> firewall-cmd --get-default-zone
public

After restart it still complains (!) about this setting in `/var/log/firewalld` even though there is no such :
2015-07-07 00:55:48 DEBUG1: start()                                             
2015-07-07 00:55:48 DEBUG1: Loading firewalld config file '/etc/firewalld/firewalld.conf'
2015-07-07 00:55:48 ERROR: IPv6_rpfilter '' is not valid, using default value True
2015-07-07 00:55:48 WARNING: Using fallback firewalld configuration settings.

I tried to hunt for location of any `IPv6_rpfilter` - there is none in `/etc` directory:
> grep -r IPv6_rpfilter /etc/
# no output

Attaching `/etc/firewalld/firewalld.conf` - nothing seems wrong (!).

My `/etc/firewalld/zones/trusted.xml`:
> cat /etc/firewalld/zones/trusted.xml
<?xml version="1.0" encoding="utf-8"?>
<zone target="ACCEPT">
  <short>Trusted</short>
  <description>All network connections are accepted.</description>
  <masquerade/>
</zone>


The last suspicious thing I see in the log (it can also be seen inside `/var/lib/firewalld` file attached before in comment 4):
2015-07-07 00:59:56 DEBUG1: Loading zone file '/etc/firewalld/zones/public.xml' 
2015-07-07 00:59:56 DEBUG1:   Overloads zone 'public' ('/usr/lib/firewalld/zones/public.xml')
2015-07-07 00:59:56 DEBUG1: Loading zone file '/etc/firewalld/zones/trusted.xml'
2015-07-07 00:59:56 DEBUG1:   Overloads zone 'trusted' ('/usr/lib/firewalld/zones/trusted.xml')
2015-07-07 00:59:56 WARNING: FedoraServer: INVALID_SERVICE: cockpit             
2015-07-07 00:59:56 DEBUG1: Using default zone 'public'                         

I'm not sure what "Overloads zone" mean, but the next thing it does is switching to 'public'.
Why does it need to look into configuration files under `/usr/lib/firewalld/zones/` when `/etc/firewalld/zones/` override them (AFAIU)?
Especially, what `public.xml` has to do with my `/etc/firewalld/firewalld.conf` (attached)?

Given my `firewalld.conf` and `trusted.xml`, can it be reproduced by somebody else?
Two my currently accessible machines show this issue.

Comment 7 Thomas Woerner 2015-07-06 17:52:19 UTC
Ok, this is a parser issue. The handling of the bool fallbacks was not correct for missing settings.

Here is the upstream patch to fix it: https://github.com/t-woerner/firewalld/commit/26b54a8a9b0a20f8c78c62b60e734b55d9a15fed

Comment 8 Alexey Pakseykin 2015-07-06 18:03:57 UTC
Thomas, thanks for your time and prompt response!

So, the workaround for now is to actually set `IPv6_rpfilter` to something valid explicitly (do not remove or comment it out).

> grep -r IPv6_rpfilter /etc/firewalld/
/etc/firewalld/firewalld.conf:IPv6_rpfilter=yes

> systemctl restart firewalld

> firewall-cmd --get-default-zone
trusted

DONE!

Comment 9 Fedora Update System 2016-02-04 15:41:16 UTC
firewalld-0.4.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7

Comment 10 Fedora Update System 2016-02-05 01:23:41 UTC
firewalld-0.4.0-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-fc0691e6a7

Comment 11 Fedora Update System 2016-02-08 13:29:05 UTC
firewalld-0.4.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7

Comment 12 Fedora Update System 2016-02-09 22:27:50 UTC
firewalld-0.4.0-2.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-fc0691e6a7

Comment 13 Fedora Update System 2016-02-21 16:30:19 UTC
firewalld-0.4.0-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.