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`.
Are there any errors reported by firewalld? Please add the output of "systemctl status firewalld -l"
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.
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.
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)
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".
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.
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
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!
firewalld-0.4.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7
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
firewalld-0.4.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7
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
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.