Red Hat Bugzilla – Bug 796479
firewalld conflicts with libvirt's default network
Last modified: 2016-04-26 18:21:31 EDT
After I installed firewalld, my guests stopped being able to pass traffic on their interfaces connected to the libvirt default network. Stopping firewalld and restarting libvirt resolved the problem.
I _just_ started seeing this on 17, though i'm sure I had firewalld running and guest networking working for a while.
Fedora Bugzappers volunteer triage team
(In reply to comment #1)
> I _just_ started seeing this on 17, though i'm sure I had firewalld running and
> guest networking working for a while.
I think it's racy, not guaranteed to conflict depending on who starts first.
Despite that, firewalld is on by default in f17, so that makes this a pretty serious issue. Requesting F17Blocker.
I understand twoerner has a patch to have libvirt talk to firewalld rather than raw iptables calls. That might be our best bet for f17, unless someone has an alternative or hack that buys us some time.
Discussed at 2012-04-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-20/fedora-bugzappers.2012-04-20-17.01.log.txt . As things stand, we agree this constitutes a blocker of the criterion "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology" and is accepted as a blocker. There is a chance firewalld-as-default feature will be reverted, this is on the agenda for the next FESCo meeting: if this happens, this bug will stop being a blocker. We will revisit in that case.
FYI upstream patch for libvirt to work with firewalld. There are a number of issues we're hitting with it though, not least x8 performance slowdown compared to existing using of iptables/ebtables commands
Since firewalld is not going to be on by default for F17  this bug is no longer a blocker - moving to rejected.
Fedora Bugzappers volunteer triage team
(In reply to comment #5)
> Since firewalld is not going to be on by default for F17  this bug is no
> longer a blocker - moving to rejected.
Eh? I don't recall asking for firewalld, but I have it.
I had to:
# firewall-cmd --add --interface=virbr1
...before my guest could talk to my host. Seems like this bug?
Matthew: depends when you installed F17, to a degree. It got made the default for a while, between Alpha and Final (I forget exactly when), then we went back to s-c-f as the default close to release. But if you happened to install during the period firewalld was set as default, you'll still have it; we didn't put in any package triggers to 'migrate' such systems back to s-c-f.
If you want to go back to s-c-f manually, IIRC, you have to enable the iptables.service and iptables6.service services, run lokkit --enabled, and uninstall firewalld. I _think_ that's it, but that's just from memory.
Ah, yes, that would be what happened... thanks for reminding me :-).
(So... "rejected" just means as a blocker, I take it? Bug is still open, anyway, so I guess 'yes'.)
Anyway, it's unclear from the report if the problem I am having is identical, but it seems likely. Basically, it seems that libvirt and/or firewalld need to interact better such that when libvirt creates a new virtual device (e.g. vnet*, virbr*) it can be automatically registered with firewalld. From doing the registration manually, I believe that would fix at least the problem I am having.
(Note: simply controlling start-up order is insufficient, as virtual devices aren't necessarily created on boot. The user (VM admin) might enable/disable or even create/destroy virtual networks at any time.)
matthew: yes, any stuff you see in bug reports about the blocker bug process just relates specifically to the blocker bug / release validation process; the bug remains open, it just means we aren't holding releases for the bug.
But, now you mention it, let's re-propose this for F18, as firewalld is back to being the default. I'll have to check if this is still affecting out-of-the-box images when booted in virt-manager if I can ever build a bloody image that boots...
Discussed at 2012-08-10 blocker review meeting. Agreed that we needed more time to evaluate this one.
Discussed at 2012-08-16 blocker review meeting - http://meetbot.fedoraproject.org/fedora-bugzappers/2012-08-16/f18-alpha-blocker-review-3.2012-08-16-16.00.html . Again, we didn't get around to re-checking this yet; just needs someone to enable firewalld on an F18 system and check network status in a KVM guest.
It is still problematic; for example, if firewalld is restarted, it tosses out all of libvirt's iptables rules. twoerner and I are working on patches for libvirt to integrate with firewalld. Hopefully those can be pushed before the next upstream release of libvirt, which will likely be the version in F18.
Discussed at 2012-08-20 QA meeting, acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-08-20/fedora-qa.2012-08-20-15.00.html . Accepted as a Beta blocker, as the relevant criterion - "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology" - is Beta, not Alpha.
Yesterday, I pushed patches (from twoerner and stefanb) to upstream libvirt which are at least a first cut at using firewalld for libvirt's iptables/ebtables needs, rather that going directly. There will be a new upstream libvrit release a week from today, and at that time a build will be made for both F18 and rawhide.
This will need some serious testing, but the core code is there now.
Author: Thomas Woerner <email@example.com>
Date: Tue Aug 14 20:59:52 2012 +0200
network: use firewalld instead of iptables, when available
Author: Stefan Berger <firstname.lastname@example.org>
Date: Wed Aug 8 12:00:23 2012 -0400
nwfilter: provide basic support for firewalld
These patches require a new selinux-policy to permit dbus communications by firewall-cmd when run in libvirt's confined environment. That patch is already in selinux-policy-3.11.1-9.fc18.noarch: Bug 848860
Thought Closed: Have I got this bug?
(In reply to comment #17)
> Thought Closed: Have I got this bug?
> Thread here:
~]# firewall-cmd --get-active-zones
public: eth0 eth1 virbr0
~$ rpm -qa | grep firewall
Created attachment 715899 [details]
cat /var/log/messages | grep virbr0