This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 796479 - firewalld conflicts with libvirt's default network
firewalld conflicts with libvirt's default network
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Laine Stump
Fedora Extras Quality Assurance
Depends On:
Blocks: F18Beta/F18BetaBlocker
  Show dependency treegraph
Reported: 2012-02-22 19:53 EST by Dave Allan
Modified: 2016-04-26 18:21 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-14 02:29:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cat /var/log/messages | grep virbr0 (56.64 KB, text/plain)
2013-03-25 04:21 EDT, Frank Murphy
no flags Details

  None (edit)
Description Dave Allan 2012-02-22 19:53:51 EST
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.
Comment 1 Adam Williamson 2012-04-10 15:29:27 EDT
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
Comment 2 Cole Robinson 2012-04-18 11:17:14 EDT
(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.
Comment 3 Adam Williamson 2012-04-20 16:28:39 EDT
Discussed at 2012-04-20 blocker review meeting: . 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.
Comment 4 Daniel Berrange 2012-04-24 12:14:38 EDT
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
Comment 5 Tim Flink 2012-05-01 18:16:42 EDT
Since firewalld is not going to be on by default for F17 [1] this bug is no longer a blocker - moving to rejected.

Comment 6 Adam Williamson 2012-05-16 02:17:55 EDT

Fedora Bugzappers volunteer triage team
Comment 7 Matthew Woehlke 2012-08-06 16:23:36 EDT
(In reply to comment #5)
> Since firewalld is not going to be on by default for F17 [1] 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?
Comment 8 Adam Williamson 2012-08-07 01:56:55 EDT
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.
Comment 9 Matthew Woehlke 2012-08-07 14:28:03 EDT
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.)
Comment 10 Adam Williamson 2012-08-07 19:56:36 EDT
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.
Comment 11 Adam Williamson 2012-08-07 19:58:22 EDT
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...
Comment 12 Adam Williamson 2012-08-16 12:12:03 EDT
Discussed at 2012-08-10 blocker review meeting. Agreed that we needed more time to evaluate this one.
Comment 13 Adam Williamson 2012-08-16 14:54:33 EDT
Discussed at 2012-08-16 blocker review meeting - . 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.
Comment 14 Laine Stump 2012-08-16 22:20:15 EDT
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.
Comment 15 Adam Williamson 2012-08-20 19:23:20 EDT
Discussed at 2012-08-20 QA meeting, acting as a blocker review meeting: . 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.
Comment 16 Laine Stump 2012-08-22 11:16:39 EDT
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.

commit bf156385a031c0cafa8a068f6fbfc41fc9823a99
Author: Thomas Woerner <>
Date:   Tue Aug 14 20:59:52 2012 +0200

    network: use firewalld instead of iptables, when available

commit 4efde75fab4633d35e70b96cb540e9a903eae1b9
Author: Stefan Berger <>
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
Comment 17 Frank Murphy 2013-03-25 04:18:39 EDT
Thought Closed: Have I got this bug?
Thread here:
Comment 18 Frank Murphy 2013-03-25 04:19:34 EDT
(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
Comment 19 Frank Murphy 2013-03-25 04:21:17 EDT
Created attachment 715899 [details]
cat /var/log/messages | grep virbr0

Note You need to log in before you can comment on or make changes to this bug.