Comment # 37 on bug 1158817 from
Given Michal's statement in comment 34, I'm going to revert this change for
openSUSE. It will take some time until that update hits the distro. In the
meantime, you can use the workaround from comment 2.

Wrt the general analysis and firewalld, I need to correct my own statements
from comment 25. The instructions under 3.) there *don't solve the problem*.

TL;DR: use comment 2.

br_netfilter changes the handling of *forwarded* packets only. Packets
originating from or received by the host itself are *always* subject to
firewall filtering, even if br_netfilter is not active. The same holds for the
sysctl knobs mentioned in comment 4.

Without br_netfilter, the traffic *between VMs* on that virtual network are
unaffected by the firewall settings. 

If br_netfilter is active, firewall rules are applied to forwarded packets. 
But these packets traverse only the FORWARD chain, and firewalld applies the
zone-specific rules only to the INPUT chain. Only the zone's "target" is
applied to both INPUT and FORWARD chains. This is the reason why libvirt sets
up its zone as follows:

libvirt (active)
  target: ACCEPT
  services: dhcp dhcpv6 dns ssh tftp
  rich rules: 
        rule priority="32767" reject

(*doesn't work on Leap 15.1, see below!!*)

If they used a "REJECT" target instead, all forwarded traffic would be
rejected,
and the exceptions defined further down wouldn't take effect (only for packets
destined for the host). 

This explains why libvirt/firewalld integration requires firewalld >= 0.7.0:
libvirt uses firewalld's "priority" attribute, which was added in 0.7.0, and
makes sure that the "services" definition takes priority over the final
"reject" rule.

On Leap, the only alternative to comment 2, or to disabling the firewall
entirely, is adding the bridges to the "trusted" zone. But that allows
everything, so disabling br_netfilter (comment 2) is actually more secure.


You are receiving this mail because: