Bug 1638342 - libvirt NAT'ed gues cannot access internet when firewalld is active [regression]
Summary: libvirt NAT'ed gues cannot access internet when firewalld is active [regression]
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-11 11:09 UTC by post+redhat
Modified: 2019-04-08 15:51 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description post+redhat 2018-10-11 11:09:06 UTC
Description of problem:
I have a guest whose network is set to "default", which is a NAT network. This used to work fine (the guest could access the internet), but sometime within the last few weeks an update must have broken it: Now, the guest has no internet connection. I can do "systemctl disable firewalld" to fix that, but that's not a proper solution obviously.


Version-Release number of selected component (if applicable): libvirt 4.7.0 (Debian testing)
The update to 4.7 happened recently, so that fits with the regression, but I don't know which version I had installed when it last worked (likely 4.5 or 4.6).


Steps to Reproduce:
1. Have a NAT'ed guest
2. Have firewalld configured
3. (Might be relevant) Have a firewalld zone configure to be used for all traffic from the NAT IP range. (This is because I want the guests to be able to access a server on the host that should not be accessible on the external network my host is connected to.)

Actual results:
The guest has no internet connectivity. It does not even get DHCP unless I have "dhcp" enabled in firewalld (which also was not necessary before).


Expected results:
Internet should work fine in the guest.


Additional info:
The firewalld configuration applet says the virtual network interface is in the "public" zone. I tried switching them to a different zone (the one that 192.168.122.0/24 automatically gets put into), and enabled "dhcp", which fixed DHCP for the guest -- but there does not seem to be a way to allow forwarding in the firewalld applet. And anyway this should not be needed. I also do not remember even seeing the virtual network interfaces in the firewalld configuration, so the fact that they show up there at all now might be related to the fact that internet does not work any more in the guest.

Comment 1 Cole Robinson 2018-10-11 13:50:00 UTC
What distro are you on? What firewalld version?

Comment 2 post+redhat 2018-10-11 14:14:38 UTC
Debian testing, firewalld 0.6.2.

Comment 3 Cole Robinson 2018-10-11 14:26:10 UTC
If you add FirewallBackend=iptables to /etc/firewalld/firewalld.conf and restart firewalld, libvirtd, and the default network, (or maybe just reboot, the ordering may be weird), does that fix things?

Comment 4 Cole Robinson 2018-10-11 14:28:59 UTC
Fedora's firewalld package overwrites the default to be iptables, because the new nftables default backend breaks libvirt NAT, so maybe debian should do the same. 

https://bugzilla.redhat.com/show_bug.cgi?id=1623868

Comment 5 Laine Stump 2018-10-12 17:00:32 UTC
libvirt and firewalld developers are currently discussing how to make libvirt+firewalld+nftables work together properly. Doing so will take effort/code in both libvirt and firewalld. In the meantime, all distros should be keeping FirewallBackend=iptables in /etc/firewalld/firewalld.conf.

(BTW, just restarting firewalld.service should be enough to get the change to take effect - libvirtd watches for restarts of firewalld, and reloads all of its firewall rules whenever it detects that event.)

You should file a bug against the firewalld package on the downstream bugtracker for debian (bugs.debian.org), since the change required is something that should be made only to the downstream build of firewalld on debian.

Comment 7 post+redhat 2018-11-10 14:42:30 UTC
Confirmed, setting FirewallBackend=iptables fixes the problem.

I will report a bug in Debian, but of course fixing this in every distribution one-by-one is not going to scale...

Comment 8 ilmostro7 2019-04-06 01:26:08 UTC
Same issue observed in Archlinux.  Since Arch tends to follow upstream, I suspect the approach taken will be to wait for the libvirt and/or firewalld maintainers to address this.

In the meantime, there is an open bug that follows the developments here.

Comment 9 Laine Stump 2019-04-08 15:51:52 UTC
It was addressed upstream several months ago. It's now just waiting on firewalld to release firewalld-0.7.0 which contains support for rule priorities (a requirement for the fix).


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