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@xxxxxxxxxx> 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
