View Issue Details

IDProjectCategoryView StatusLast Update
0007407CentOS-7firewalldpublic2020-07-18 15:59
Reporterbierdybard Assigned To 
Status feedbackResolutionopen 
Product Version7.0-1406 
Summary0007407: Firewalld not loading permanent rules at boot
DescriptionWhen using CentOS 7, firewalld is not loading permanent rules at boot.

Permanent rules have been added using firewall-cmd --permanent. I have verified the updates exist in /etc/firewalld/zones. I have also verified firewalld is enabled on boot.

Upon reboot, firewalld does load. firewall-cmd --state returns "running." However, all interfaces are in the default zone.

Reloading firewalld via firewall-cmd --reload loads the permanent rules as expected.
Steps To Reproduce1. Set permanent rules with firewall-cmd --permanent
2. Verify existence of rule changes /etc/firewalld
3. Reboot machine
4. Verify state of firewalld
5. Verify permanent rules not loaded with firewalld --list-all-zones
6. Reload firewalld with firewall-cmd --reload
7. Verify correct rules loaded with firewalld --list-all-zones
TagsNo tags attached.




2014-07-24 11:01

reporter   ~0020513

I can confirm this issue however if my case firewall-cmd --reload does not fix the issue. The latest kernel 3.10.0-123.4.2.el7 seems to be the issue as 3.10.0-123.el7 worked perfectly fine.


2014-07-24 13:21

reporter   ~0020514

confirming rmb938's first statement, I mistyped the reproduction steps. Step 6 should be "systemctl restart firewalld", not "firewall-cmd --reload".


2014-07-24 13:35

reporter   ~0020515

Unfortunately I cannot confirm the kernel version has an effect at this point. I tried downgrading my kernel to 3.10.0-123.el7 with no change; in my particular case, firewalld still puts eth0 in the default (public) zone on boot, rather than the desired (external) zone.


2014-07-24 13:39

reporter   ~0020516

Well for me even doing "systemctl restart firewalld" does not load in the changes. I have not tried downgrading my kernel but before I updated my kernel it was not an issue.


2014-08-11 03:48

reporter   ~0020654

Confirmed the bug as well. Restarting the firewall with "systemctl restart firewalld" fixed, but any attempt to change network settings, e.g. "systemctl restart network" brings the configuration back to broken state (which a subsequent firewall restart fixes).

For example, when I restart the network, I get:

  interfaces: inter0
  interfaces: intra0

However the correct setting should be:

  interfaces: inter0


2014-08-12 17:41

manager   ~0020666

Is this upstream BZ related?


2014-08-12 18:12

reporter   ~0020667

I can verify that. Adding ZONE="desiredZone" to the ifcfg-XXX file for the interface causes the network service and firewall to launch with the interface in the correct zone.

I got hung up on the zones and hadn't actually tried adding services to a zone. I can verify that services added to zones with --permanent do in fact stick.


2014-09-13 19:40

reporter   ~0020909

A duplicate bug was opened recently with more helpful information: 0007526:

To save time, here is the description which includes the suspect code:

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


2015-01-14 01:14

reporter   ~0022123

This may have been fixed for zones, however the startup load of direct rules is still broken. Even though /etc/firewalld/direct.xml shows that a permanent rule has been saved

<?xml version="1.0" encoding="utf-8"?>
  <rule ipv="ipv4" table="filter" chain="IN_public_allow" priority="0">-m udp -p udp --sport 161 -j ACCEPT</rule>

after rebooting or restarting the firewalld service, firewall-cmd --direct --get-all-rules shows no rules are loaded.

There are no errors in /var/log/secure and /var/log/messages shows what appears to be a successful restart with only one error:
Jan 13 17:10:20 DC1-ONMS NetworkManager[1108]: nm_connection_get_setting_connection: assertion `NM_IS_CONNECTION (connection)' failed


2015-01-30 10:28

reporter   ~0022269

Confirming the issue. Even with kernel

firewalld is loosing all settings with reload, restart or reboot.


2015-01-30 10:37

reporter   ~0022270

I checked the firewalld status after restarting with:

systemctl restart firewalld
systemctl status firewalld

It showed ZONE_CONFLICT's.

I found /etc/firewalld/zones/ contained some files with extention .old
I removed them and the problem was over!!!


2015-01-30 10:46

reporter   ~0022271

The previous does work on:

ONE original system(VM)
ANOTHER system (cloned original VM)


2015-01-30 20:59

reporter   ~0022274

Found it out.
Since the system is using NetworkManager.
firewall-cmd is --permanent is not working.
You have to do this in this way:
place the following in the ifcfg-ens192 or whatever device you have:
ZONE=internal (or any other zone)
Good Luck!


2015-02-20 21:26

reporter   ~0022382


I can confirm this behaviour.
I have tried to remove the xxx.old zone files with no success.
Setting the zone manually in the ifcfg-xxx interface files fixed it across reboots.

Many Thanks.


2015-05-22 17:20

reporter   ~0023164

To me this does seem the same as upstream, as pointed out by toracat.

I have firewalld-0.3.9-11.el7, which should correspond to the package released issued for (pointed to in the upstream bugzilla), and it does mention zones are managed by NM except for connections not managed by NM.

NetworkManager CLI command to set the zone for a connection:
nmcli conn modify <iface> <zone>

After that, firewall-cmd --reload worked for me.


2015-05-22 17:30

manager   ~0023165


Thanks for the report.

Could others also check to see if the updated firewalld fixes the issue?


2015-05-22 17:47

reporter   ~0023166

Just to put it clearly: the fix in this case was just to documentation (firewall-cmd(1) and manual pages), as stated in the RHBA-2015:0520-2 bug fix advisory.


2017-01-13 17:17

reporter   ~0028347

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-17 04:52

reporter   ~0028377

I confirmed this behavior on CentOS 7.2.1511 and CentOS 7.3.1611.

Also commented my workaround in the aforementioned URL:


2017-01-24 11:52

reporter   ~0028465

I had previously managed to work around this issue by manually configuring both myzone.xml and ifcfg-myinterface.

After the latested update to


The issue reappeared again and now it is impossible to fix even with manual reconfiguration.


2020-07-18 15:59

reporter   ~0037378

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-07-21 02:40 bierdybard New Issue
2014-07-24 11:01 rmb938 Note Added: 0020513
2014-07-24 13:21 bierdybard Note Added: 0020514
2014-07-24 13:35 bierdybard Note Added: 0020515
2014-07-24 13:39 rmb938 Note Added: 0020516
2014-08-11 03:48 nelsonjr Note Added: 0020654
2014-08-12 17:41 toracat Note Added: 0020666
2014-08-12 18:12 bierdybard Note Added: 0020667
2014-09-13 19:40 SheepReaper Note Added: 0020909
2015-01-14 01:14 Techlectica Note Added: 0022123
2015-01-30 10:28 oxygenius Note Added: 0022269
2015-01-30 10:37 oxygenius Note Added: 0022270
2015-01-30 10:46 oxygenius Note Added: 0022271
2015-01-30 20:59 oxygenius Note Added: 0022274
2015-02-20 21:26 anothernerd Note Added: 0022382
2015-05-22 17:20 spuk Note Added: 0023164
2015-05-22 17:30 toracat Note Added: 0023165
2015-05-22 17:31 toracat Status new => feedback
2015-05-22 17:47 spuk Note Added: 0023166
2017-01-13 17:17 tiangolo Note Added: 0028347
2017-01-17 04:52 msanabria Note Added: 0028377
2017-01-24 11:52 ezplanet Note Added: 0028465
2020-07-18 15:59 luciferatus Note Added: 0037378