On Thu, Jan 31, 2019 at 08:24:55PM -0500, Laine Stump wrote:
In the past (when both libvirt and firewalld used iptables), if either libvirt's rules *OR* firewalld's rules accepted a packet, it would be accepted. This was because libvirt and firewalld rules were processed during the same kernel hook, and a single ACCEPT result would terminate the rule traversal and cause the packet to be accepted.
But now firewalld can use nftables for its backend, while libvirt's firewall rules are still using iptables; iptables rules are still processed, but at a different time during packet processing (i.e. during a different hook) than the firewalld nftables rules. The result is that a packet must be accepted by *BOTH* the libvirt iptables rules *AND* the firewalld nftable rules in order to be accepted.
This causes pain because
1) libvirt always adds rules to permit DNS and DHCP (and sometimes TFTP) from guests to the host network's bridge interface. But libvirt's bridges are in firewalld's "default" zone (which is usually the zone called "public"). The public zone allows ssh, but doesn't allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the DHCP and DNS traffic, the firewalld rules (now processed during a different hook) dont, thus guests connected to libvirt's bridges can't acquire an IP address from DHCP, nor can they make DNS queries to the DNS server libvirt has setup on the host. (This could be solved by modifying the default firewalld zone to allow DNS and DHCP, but that would open *all* interfaces in the default zone to those services, which is most likely not what the host's admin wants.)
2) Even though libvirt adds iptables rules to allow forwarded traffic to pass the iptables hook, firewalld's higher level "rich rules" don't yet have the ability to configure the acceptance of forwarded traffic (traffic that is going somewhere beyond the host), so any traffic that needs to be forwarded from guests to the network beyond the host is rejected during the nftables hook by the default zone's "default reject" policy (which rejects all traffic in the zone not specifically allowed by the rules in the zone, whether that traffic is destined to be forwarded or locally received by the host).
libvirt can't send "direct" nftables rules (firewalld only supports direct/passthrough rules for iptables), so we can't solve this problem by just sending explicit nftables rules instead of explicit iptables rules (which, if it could be done, would place libvirt's rules in the same hook as firewalld's native rules, and thus eliminate the need for packets to be accepted by both libvirt's and firewalld's own rules).
However, we can take advantage of a quirk in firewalld zones that have a default policy of "accept" (meaning any packet that doesn't match a specific rule in the zone will be *accepted*) - this default accept will also accept forwarded traffic (not just traffic destined for the host).
Of course we don't want to modify firewalld's default zone in that way, because that would affect the filtering of traffic coming into the host from other interfaces using that zone. Instead, we will create a new zone called "libvirt". The libvirt zone will have a default policy of accept so that forwarded traffic can pass andn list
s/andn/and/
specific services that will be allowed into the host from guests (DNS, DHCP, SSH, and TFTP).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|