Created attachment 1287007 [details] Network Manager log with level=TRACE Description of problem: Version-Release number of selected component (if applicable): NetworkManager 1.8.0-4.fc26 How reproducible: 100% Steps to Reproduce: 1. Configure virbr0 (aka libvirt bridge) to be put in trusted zone: # firewall-cmd --permanent --zone=trusted --add-interface=virbr0 2. Reboot 3. Check if virbr0 is in trusted zone: # firewallctl info zone trusted Actual results: # firewallctl info zone trusted trusted target: ACCEPT icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: Expected results: # firewallctl info zone trusted trusted (active) target: ACCEPT icmp-block-inversion: no interfaces: virbr0 sources: services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: Additional info: tredaell@graphite ~ % cat /etc/sysconfig/network-scripts/ifcfg-virbr0 DEVICE=virbr0 STP=yes DELAY=2 BRIDGING_OPTS=priority=32768 TYPE=Bridge PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=192.168.122.1 PREFIX=24 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV4_DNS_PRIORITY=100 IPV6INIT=no NAME=virbr0 UUID=793e6eb3-4108-4549-8149-73b069a55e5d ONBOOT=no ZONE=trusted tredaell@graphite ~ % tredaell@graphite ~ % nmcli connection show NAME UUID TYPE DEVICE enp0s31f6 25b35999-0e7a-3204-bd33-9dcc7b85ce6a 802-3-ethernet enp0s31f6 virbr0 8b54b519-0a4e-42e4-9a04-c7dd1bfdc428 bridge virbr0 [...] virbr0 793e6eb3-4108-4549-8149-73b069a55e5d bridge -- tredaell@graphite ~ % As workaround you can do: "nmcli con up virbr0" and it will work.
virbr0 is managed by libvirt. Usually, you don't want NetworkManager to interfere with it. The virbr0 interface is not explicitly configured to be unmanaged for NetworkManager. Still, NetworkManager notices that somebody else (libvirt) creates and configures the bridge. In this case, NM generates an in-memory connection that reflects the state on the device. It also means, NM will/should not configure the interface nor touch it. You can modify the in-memory connection, which causes it to be persisted to disk (as you did). When you issue `nmcli con up $NAME`, NM will activate the profile and fully manage the interface. But likely you don't want to do that, because libvirt is not expecting that. Since firewallctl --persist basically configures the zone in the NetworkManager interface, ... this is not going to work for interfaces not actively managed by NM. Thomas, what do you think how this should be solved?
Is is possible to identify this in-memory only state of a connection? Then firewalld might save the zone assignment itself. But this then also results in different zone settings in the NM and firewalld configuration and could also result in unexpected behaviour at some point. What is the NM proposed way to handle these connections? There should be only place to set and gather information about connections in my opinion. If this is not NetworkManager, what to use then? I think libvirt should use NM to create and handle connections if NM is active. This is the way it is handling the firewall: If firewalld is active, then it uses firewalld, otherwise it is using ip*tables.
(In reply to Thomas Woerner from comment #2) > Is is possible to identify this in-memory only state of a connection? Then > firewalld might save the zone assignment itself. No, it's currently not possible. We should add that. > But this then also results > in different zone settings in the NM and firewalld configuration and could > also result in unexpected behaviour at some point. > > What is the NM proposed way to handle these connections? Leave them alone :) I think it was a wrong decision to expose and generate these connections. It's only confusing. Probably we cannot change that now. > There should be only place to set and gather information about connections > in my opinion. If this is not NetworkManager, what to use then? We maintain that NetworkManager is this place. If libvirt doesn't use it, there is no other place. > I think libvirt should use NM to create and handle connections if NM is > active. I agree with that, we want NetworkManager to be the ubiquitous API to configure networking. > This is the way it is handling the firewall: If firewalld is active, > then it uses firewalld, otherwise it is using ip*tables.
On Fedora 25 (NetworkManager 1.4.4-5.fc25) it has the "correct" behavior (for an user point of view), but on Fedora 26 (NetworkManager 1.8.0-5.fc26) it doesn't work anymore (without touching anything, just updated Fedora 25 to Fedora 26). This could be seen as a "regression" since the behavior is changed. I have a little Vagrantfile that show the different behaviors: https://gist.github.com/drizzt/cd3aae896854eec7986c947b6d09fa25 Just start the 2 vagrant profiles with `vagrant up` Then you may show how the zone are shown after a reboot by using: # vagrant reload f25 --provision-with show_zone # vagrant reload f26 --provision-with show_zone or by entering a machine with `vagrant ssh` and by running `sudo firewallctl info zone trusted` by hand
Created attachment 1288311 [details] [logfile] for f26 and f25 Logfiles using f25/f26 with the vagrant file from comment 4
The issue is, that libvirt manages network devices on it's own. It is a very bad idea to have two managing deamon fighting over the same interface. That will end up in unpredictable behavior. When NM sees that a device is managed by somebody else, it creates these external, in-memory connections, with the intend not to mess with the device (because clearly, NM isn't in charge). When somebody modifies that connection, NM will persist the connection to disk and take over the interface [1]. It does so, because changing such a connection is taken as user decision to take over the interface. Later, after restart, NM has indeed the previously persisted connection on disk. However, NM again sees that somebody else (libvirt) messes with the interface, and will not take over the interface. Again, NM creates an in-memory connection, despite having the previously stored connection on disk. I don't think this is solvable, and I don't see how NM can do better here. This is not restricted to firewall. The exact same thing happens, when the user tries to add an IP address: nmcli connection modify virbr0 +ipv4.addresses 192.168.7.4/24 at that moment [1], NM will indeed take over the interface. But after restart, it will not (and for good reasons). @Thomas, what would you suggest to do about this? I think, either `firewallctl --persist` also grows support to talk to libvirt, or it just says: if the device is not managed by NM, it cannot persist the setting (like, NM also only supports firewalld, and no other implementations). Firewalld could see that "unsaved" flag and fail the --persist command. "unsaved" is not exactly the same as those externally-managed interfaces, because you can create regular in-memory connections with nmcli connection add save no type ... but an externally-managed connection is always unsaved, so it's probably good enough. A --persist on an in-memory connection doesn't make much sense anyway. The same issues are in rhel-7.4 [1] actually, it will not, that is a bug that needs fixing. I will clone this bug to do that.
(In reply to Thomas Haller from comment #6) [...] > > @Thomas, what would you suggest to do about this? I think, either > `firewallctl --persist` also grows support to talk to libvirt, or it just > says: if the device is not managed by NM, it cannot persist the setting > (like, NM also only supports firewalld, and no other implementations). > > Firewalld could see that "unsaved" flag and fail the --persist command. > "unsaved" is not exactly the same as those externally-managed interfaces, > because you can create regular in-memory connections with > nmcli connection add save no type ... > but an externally-managed connection is always unsaved, so it's probably > good enough. A --persist on an in-memory connection doesn't make much sense > anyway. I think it's fair to reject the configuration if --persist is requested and NM tells firewalld that the interface is "unsaved". Of course this should give an intelligible error message of the "go fix it in NM first" variety. In the case that NM is not running firewalld will happily accept --persist. I'll move this over to firewalld component then.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.