2017-02-27 11:22 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0007526CentOS-7firewalldpublic2017-02-15 06:26
PlatformOScentosOS Version7
Product Version7.0-1406 
Target VersionFixed in Version 
Summary0007526: permanent firewalld interface zone assignments not preserved across ifdown/ifup cycles
DescriptionI originally posted this as a question to www.centos.org/forums: https://www.centos.org/forums/viewtopic.php?f=50&t=48045&sid=289e316d99bc8a55489bb0f79983222c#p204247

I've been trying to learn new centos 7 systemd and firewalld concepts over the past few days and came across this issue today when rebooting my server.

I had previously setup firewalld to place eth0 and eth1 in the dmz and internal zones respectively w/ the following commands:

sudo firewall-cmd --permanent --zone=public --remove-interface=eth1
sudo firewall-cmd --permanent --zone=internal --add-interface=eth1

on reboot I looked at the active zones and saw both devices were back in the public zone. after digging for a while I realized it was due to the following lines in the /etc/sysconfig/network-scripts/ifup-eth and ifup-post scripts:

# Inform firewall which network zone (empty means default) this interface belongs to
if [ -x /usr/bin/firewall-cmd -a "${REALDEVICE}" != "lo" ]; then
    /usr/bin/firewall-cmd --zone="${ZONE}" --change-interface="${DEVICE}" > /dev/null 2>&1

so this effectively makes any "permanent" zone changes like the one I made above permanent only across firewalld restarts, but not machine restarts or interface up/down cycles.

I added the ZONE setting to each device's config to fix my issue for now...

but my question is, why is this done at all? the "default" ZONE value blows away the permanently set value. it seems like the script should at least check the current value of `firewall-cmd --get-zone-of-interface=eth0` and use that over ZONE?

please let me know if I should report this upstream to bugzilla.redhat.com instead.
Steps To Reproduce1. change the firewalld zone of a network interface using --permanent, e.g:

sudo firewall-cmd --permanent --zone=public --remove-interface=eth1
sudo firewall-cmd --permanent --zone=internal --add-interface=eth1

2. reboot the machine (or just call ifdown eth1/ifup eth1)
3. check firewall-cmd --get-active-zones

expect to see eth1 in zone internal.

actually see the interface in public (or whatever $ZONE resolves to in /etc/sysconfig/network-scripts/ifup-eth
TagsNo tags attached.
Attached Files




karma (reporter)

I noticed this same erratic behaviour when building load-balancer in a VM with ens192 and ens224 interfaces using zoned internal and external.
I have not much to add to original reporter, except confirming this bug is real and requires a fix.


erickj (reporter)

I actually meant to mark this as 'major', unfortunately I can't seem to edit the severity.

A reboot unknowingly resetting a hosts firewall rules is a recipe for disaster.


karma (reporter)

After "kicking more tyres", I agree this is a major bug in firewalld.
Firewall/Load-balancer using firewalld can not be brought to production as of now.

I added into /etc/rc.local the following two lines, which would have worked OK in pre-systemd-era:

firewall-cmd --change-interface=ens192 --zone=external
firewall-cmd --change-interface=ens224 --zone=internal

Due to services starting when they see fit (or something), this does not work on every reboot.


SheepReaper (reporter)

Confirm, also affected by this issue. Steps to reproduce are exactly as outlined previously.


SheepReaper (reporter)

This appears to be a duplicate of 0007407: https://bugs.centos.org/view.php?id=7407


tiangolo (reporter)

I think I came across the same or a similar issue.

The problem seemed to be that FirewallD is misbehaving while communicating with NetworkManager, specially during boot time.

FirewallD reads configurations from 3 places:

* Files in:


* Files in:


* Messages from NetworkManager via D-Bus

And FirewallD writes those ifcfg files if NetworkManager is running, but otherwise it writes the other zone *.xml files.

And at boot time, it seems like FirewallD is being unable to communicate with NetworkManager (maybe by that time NetworkManager has not yet published the D-Bus messages).

My current workaround ends up in having *.xml files AND ifcfg files for the same configuration.

I reported the full issue with all the details and a workaround in the FirewallD repo: https://github.com/t-woerner/firewalld/issues/195


ezplanet (reporter)

I configure a network interface manually using ifcfg-br0, in the configuration file I assign the interface to a firewall ZONE=trusted.
At next reboot the ifcfg-br0 file is changed automatically and the ZONE directive is changed to blank as follows:

At this point the interface is no longer assigned to the original zone.
Configuring the firewall using the command line as follows:

firewall-cmd --permanent --zone=trusted --add-interface=br0

succeeds, but it has only a temporary effect. When the system is rebooted the ZONE gets blanked again and thus no effect.
Steps To Reproduce Configure a network interface as follows:


and /etc/firewalld/zones/trusted.xml as follows:
<?xml version="1.0" encoding="utf-8"?>
<zone target="ACCEPT">
  <description>All network connections are accepted.</description>
  <interface name="br0"/>

At next reboot /etc/sysconfig/ifcfg-br0 gets somehow updated and the ZONE set to blank. This is not wanted. ifcfg-br0 should not be changed automatically

Unfortunately this can be reproduced reliably only when the system is rebooted. Simply restarting the "network" and "firewall" does not trigger the issue which makes it time consuming to debug.

Severity should be upgraded to major
The priority should be upgraded to very high.


sunnz (reporter)

Looks like this has been reported in rhel:


And a patch has been made to firewalld upstream:


-Issue History
Date Modified Username Field Change
2014-08-22 09:49 erickj New Issue
2014-08-23 16:48 karma Note Added: 0020732
2014-08-23 22:18 erickj Note Added: 0020733
2014-08-24 09:50 karma Note Added: 0020734
2014-09-13 19:32 SheepReaper Note Added: 0020907
2014-09-13 19:37 SheepReaper Note Added: 0020908
2017-01-13 17:15 tiangolo Note Added: 0028346
2017-01-24 11:38 ezplanet Note Added: 0028464
2017-02-15 06:26 sunnz Note Added: 0028576
+Issue History