On Tue, Nov 15, 2022 at 01:33:28PM -0500, Laine Stump wrote: > On 11/15/22 12:55 PM, Daniel P. Berrangé wrote: > > On Thu, Nov 10, 2022 at 11:31:44AM -0500, Eric Garver wrote: > > > This series further improves the firewalld backend by converting to a > > > fully native implementation for NAT and routed networks. That is, there > > > are no iptables rules added by libvirt when the running firewalld is > > > 0.9.0 or later. > > > > > > The major advantage is that firewalld users can use firewall-cmd to > > > filter the VM traffic and apply their own policies. > > > > > > When firewalld < 0.9.0 is present only the "libvirt" zone will be used. > > > The new "libvirt-nat" and "libvirt-routed" zones are not used. This > > > maintains compatibility for older distributions (e.g. Ubuntu 20.04). > > > > Testing this I'm noticing problematic behaviour even with the > > existing iptables impl. > > > > Specifically, if you have 2 different virtual networks, VMs on > > the distinct virtual networks are not supposed to be able to > > talk to each other. And yet, even with the existing iptables > > impl this is not blocked, and I'm wondering if this is a > > consequence of the 'iptables' impl being switched to nft. > > Between two routed networks it should allow traffic, but not between two > NATed networks, or from routed to NAT. Unless I crossed a wire in my testing > setup, I had tested this before pushing Eric's last patches (which fixed > incoming traffic to routed networks). > > I'll check it again. If it's not currently being blocked then it can be, e.g. adding a policy to reject "libvirt-nat" --> "libvirt-routed". > > With this pure firewalld impl, I'm not sure how we can stop this > > cross-network traffic, given that all the virtual network sget > > put in the same zone. > > Interesting point. Yeah, can't have that.
