On Wed, Jul 03, 2019 at 09:07:10PM +0300, Nikolai Zhubr wrote:

At the moment I'm running a quite outdated version 1.2.9 of libvirt, but because other than this issue it does its job pretty well I'd first consider some patching/backporting rather than totally replacing it with a new one. Anyway, I first need to better understand what is going on and what is wrong with it.

Not too bad an issue - the iptables rules libvirt creates have been almost entirely unchanged since they were first introduced, until I recently did some changes. My recent changes merely moved them down into libvirt chains instead of the root chains, which shouldn't be a functional change.

I've already figured the source of trouble is anyway related to these rules added:

-A POSTROUTING -o br0 -j MASQUERADE -A POSTROUTING -o enp0s25 -j MASQUERADE -A POSTROUTING -o virbr2_nic -j MASQUERADE -A POSTROUTING -o vnet0 -j MASQUERADE

Is that really the full specification of the rules ? AFAIK, libvirt would not create such rules - at very least lbivirt MASQUERADE should always have a source + destination IP mask If I start the libvirt 'default' virtual network the MASQUARADE rules created by libvirt look like: -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE In older libvirt it would be POSTROUTING instead of LIBVIRT_PRT but otherwise the same

Here, virbr2_nic and vnet0 are used by libvirt for arranging NAT-mode network configurations for VMs, unrelated to normal network stuff, so it looks ok. However, br0 (with enp0s25 in it) is a main interface of this host with primary ip address. And enp0s25 is a physical nic of this host, and it is used for all sorts of regular (unrelated to virtualization) communications as well. Also, br0 is used for attaching some bridge-mode (as opposed to NAT-mode) VMs managed by libvirt, but bridge mode is not supposed to employ address translation anyway.

So, clearly, libvirt somehow chooses to set up masquerading for literally all existing network interfaces here (except lo), but I can't see a reason for the first two rules in the list above. Furthermore, they corrupt UDP broadcats coming from outside and reaching this host (through enp0s25/br0) such that source address gets replaced by this hosts primary address (as per masquerading). I've verified this by arranging a hand-crafted UDP listener and printing the respective source addresses as seen by normal userspace. Obviously Samba server can not work correctly under such conditions.

Now I've discovered that I can "eliminate" the problem by e.g.:

1. Removing "-A POSTROUTING -o br0 -j MASQUERADE" (manual brute force) 2. Inserting "-A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.255/32 -j ACCEPT" (Of course correcting rules by hand is not a solution, just a test)

So question is, how the correct rules should ideally look like? And, is this issue known/fixed in most current libvirt?

I'm not convinced that libvirt is actually creating those rules. Is there any other software on your host that could be responsible ? Can you test - Disable all libvirt virtual networks virsh net-destroy NETNAME virsh net-autostart --disable NETNAME - Reboot the host OS Now look at iptables rules. Are the MASQUERADE rules present ? If they are not present then start a network with 'virsh net-start NETNAME' Are the MASQUERADE rules now present ? If so can you show the XML of the network (virsh net-dumpxml NETNAME). Also do you have any hook scripts in /etc/libvirt/hooks that might be doing anything ? 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 :|