View Issue Details

IDProjectCategoryView StatusLast Update
0007407CentOS-7firewalldpublic2017-02-07 21:59
Reporterbierdybard 
PrioritynormalSeveritymajorReproducibilityalways
Status feedbackResolutionopen 
Product Version7.0-1406 
Target VersionFixed in Version 
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.
abrt_hash
URL

Activities

rmb938

rmb938

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

bierdybard

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

bierdybard

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

rmb938

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

nelsonjr

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:

internal
  sources: 10.0.2.0/24 192.168.1.0/24
external
  interfaces: inter0
public
  interfaces: intra0
  sources: 10.0.3.0/24

However the correct setting should be:

internal
  sources: 10.0.2.0/24 192.168.1.0/24
external
  interfaces: inter0
public
  sources: 10.0.3.0/24
toracat

toracat

2014-08-12 17:41

manager   ~0020666

Is this upstream BZ related?

https://bugzilla.redhat.com/show_bug.cgi?id=1112742
bierdybard

bierdybard

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

SheepReaper

2014-09-13 19:40

reporter   ~0020909

A duplicate bug was opened recently with more helpful information: 0007526: https://bugs.centos.org/view.php?id=7526

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

<quote>
I 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
fi

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.
</quote>
Techlectica

Techlectica

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"?>
<direct>
  <rule ipv="ipv4" table="filter" chain="IN_public_allow" priority="0">-m udp -p udp --sport 161 -j ACCEPT</rule>
</direct>

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
oxygenius

oxygenius

2015-01-30 10:28

reporter   ~0022269

Confirming the issue. Even with kernel 3.10.0.123-20.1

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

oxygenius

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!!!
oxygenius

oxygenius

2015-01-30 10:46

reporter   ~0022271

The previous does work on:

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

oxygenius

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!
anothernerd

anothernerd

2015-02-20 21:26

reporter   ~0022382

Hi,

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

spuk

2015-05-22 17:20

reporter   ~0023164

To me this does seem the same as upstream https://bugzilla.redhat.com/show_bug.cgi?id=1112742, as pointed out by toracat.

I have firewalld-0.3.9-11.el7, which should correspond to the package released issued for https://rhn.redhat.com/errata/RHBA-2015-0520.html (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> connection.zone <zone>

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

toracat

2015-05-22 17:30

manager   ~0023165

@spuk

Thanks for the report.

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

spuk

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 firewalld.zone(5) manual pages), as stated in the RHBA-2015:0520-2 bug fix advisory.
tiangolo

tiangolo

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:

/etc/sysconfig/network-scripts/ifcfg-*

* Files in:

/etc/firewalld/zones/*.xml

* 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
msanabria

msanabria

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: https://github.com/t-woerner/firewalld/issues/195
ezplanet

ezplanet

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

NetworkManager-1.4.0-14.el7_3.x86_64

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

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