View Issue Details

IDProjectCategoryView StatusLast Update
0007526CentOS-7firewalldpublic2020-07-18 16:00
Reportererickj Assigned To 
Status newResolutionopen 
OScentosOS Version7 
Product Version7.0-1406 
Summary0007526: permanent firewalld interface zone assignments not preserved across ifdown/ifup cycles
DescriptionI originally posted this as a question to

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 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.




2014-08-23 16:48

reporter   ~0020732

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.


2014-08-23 22:18

reporter   ~0020733

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.


2014-08-24 09:50

reporter   ~0020734

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.


2014-09-13 19:32

reporter   ~0020907

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


2014-09-13 19:37

reporter   ~0020908

This appears to be a duplicate of 0007407:


2017-01-13 17:15

reporter   ~0028346

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:


2017-01-24 11:38

reporter   ~0028464

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.


2017-02-15 06:26

reporter   ~0028576

Looks like this has been reported in rhel:

And a patch has been made to firewalld upstream:


2020-07-18 16:00

reporter   ~0037379

I know this subject is old, but I had the same problem with Centos 8 with the kernel 4.18.0-193.6.3.el8_2.x86_64.

Initially I thought I had done some wrong configuration on the firewalld, so I remade the VM from 0 and the same problem.

I will list the procedures I performed:

1- deleted * .old in / etc / firewalld / zones
2- I made the command nmcli conn modify enp0s3 external, however I received the following information: "unknown connection", but it was impossible not to have this connection.
3- I typed nmcli connection modify again and hit <TAB>, to my surprise I didn't have the enp0s3 interface but "wired connection 1"
4- then rename the interface with the same name as the device with the command nmcli connection modify Connection \ wired \ 1 connection.interface-name enp0s3
5- I tried again to change the enp0s3 interface to the external zone, but using "wired connection 1", nmcli connection modify Connection \ wired \ 1 external
6- restarted the NetworkManager service and the firewalld, luckily the interface was in the correct zone
7- I restarted the server to be sure and this time it was.

Conclusion: In my opinion it is not FirewallD that is having a problem, but NetworkManager, because after networking.service was replaced by NetworkManager it was a struggle to configure the network interfaces both in Centos and in Ubuntu or Debian.

I hope this can help someone.

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
2020-07-18 16:00 luciferatus Note Added: 0037379