NetworkManager and firewalld - Zone is lost on network restart
Hello,
I have a firewalld config with two interfaces, each assigned to its own zone. One is internal, one is external. This has worked fine for about 6 months, but after the latest patch cycle we have an issue. I have read a couple recent threads/bugs on related topics:
- https://bugzilla.redhat.com/show_bug.cgi?id=1112742
- https://access.redhat.com/discussions/1455033
Here is the issue - replicated with test-cases. First, here is my expected config (before the patch cycle):
# firewall-cmd --get-active-zones my_external_zone interfaces: em1 my_internal_zone interfaces: p1p1
Here is the issue. After the last patch cycle and reboot I have the following:
# firewall-cmd --get-active-zones my_external_zone interfaces: em1 drop interfaces: p1p1
In other words, interface p1p1 lost it's zone (which was configured via nmcli and present in the network-scripts/ifcfg-p1p1 file)
Here is the test case I just ran, which makes me think there is a bug, or perhaps that I am doing something obvious wrong and not seeing my error:
First, I removed the p1p1 interface from the default drop zone:
# firewall-cmd --permanent --zone=drop --remove-interface=p1p1 The interface is under control of NetworkManager and already bound to the default zone The interface is under control of NetworkManager, setting zone to default. success
Then, I added the p1p1 interface to the desired zone:
# firewall-cmd --permanent --zone=my_internal_zone --add-interface=p1p1 The interface is under control of NetworkManager, setting zone to 'my_internal_zone'. success # firewall-cmd --reload # firewall-cmd --get-active-zones my_external_zone interfaces: em1 my_internal_zone interfaces: p1p1
Then, I verified by checking the network-scripts/ifcfg-p1p1 file:
# cat /etc/sysconfig/network-scripts/ifcfg-p1p1 TYPE=Ethernet BOOTPROTO=none DEFROUTE=no IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=p1p1 DEVICE=p1p1 ONBOOT=yes IPADDR=192.168.1.1 PREFIX=24 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes ZONE=my_internal_zone
Looks good! I thought the problem was solved at this point. Nope - I restarted networking and checked again:
# systemctl restart network # firewall-cmd --get-active-zones my_external_zone interfaces: em1 drop interfaces: p1p1 # cat /etc/sysconfig/network-scripts/ifcfg-p1p1 TYPE=Ethernet BOOTPROTO=none DEFROUTE=no IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=p1p1 DEVICE=p1p1 ONBOOT=yes IPADDR=192.168.1.1 PREFIX=24 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes
The interface has lost its zone. I reproduced the same results with a full reboot. Then, I tried the same test using nmcli as opposed to firewall-cmd:
# nmcli connection modify p1p1 connection.zone my_internal_zone # cat /etc/sysconfig/network-scripts/ifcfg-p1p1 TYPE=Ethernet BOOTPROTO=none DEFROUTE=no IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=p1p1 DEVICE=p1p1 ONBOOT=yes IPADDR=192.168.1.1 PREFIX=24 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes ZONE=my_internal_zone
So far so good. Then, I restarted network services and checked again:
# cat /etc/sysconfig/network-scripts/ifcfg-p1p1 TYPE=Ethernet BOOTPROTO=none DEFROUTE=no IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=p1p1 DEVICE=p1p1 ONBOOT=yes IPADDR=192.168.1.1 PREFIX=24 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes
So, again, the interface has lost its zone after it was set via nmcli and added to the network-scripts/ifcfg-p1p1 file.
Does anyone see anything obvious I am doing wrong here? If not, this seems like a pretty significant bug that was introduced in a recent patch. The last thing in the world any of us want is for all these MANY different and inter-operating configuration commands to affect things like our network configuration, which very seldom changes and in most cases (on the server at least) really needs to stay stable and static.
Thanks for any advise you can offer - especially those of you from RedHat monitoring these discussion threads.
Responses