 |
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. |
|
|
confirming rmb938's first statement, I mistyped the reproduction steps. Step 6 should be "systemctl restart firewalld", not "firewall-cmd --reload". |
|
|
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. |
|
|
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. |
|
|
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 |
 |
Is this upstream BZ related? https://bugzilla.redhat.com/show_bug.cgi?id=1112742 |
|
|
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. |
|
|
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> |
|
|
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 |
|
|
Confirming the issue. Even with kernel 3.10.0.123-20.1 firewalld is loosing all settings with reload, restart or reboot. |
|
|
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!!! |
|
|
The previous does work on: ONE original system(VM) ANOTHER system (cloned original VM) |
|
|
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! |
|
|
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. |
|
|
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. |
|
|
@spuk Thanks for the report. Could others also check to see if the updated firewalld fixes the issue? |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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 connection.zone 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 connection.zone 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. |
- Anonymous
