> -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 *None* of those rules were added by libvirt (unless your build of

You can verify my "counter-claim" by running "virsh net-destroy" for all of your libvirt networks, and seeing that the offending rules haven't been removed. In short, you need to look elsewhere for the culprit.

> > Here, virbr2_nic and vnet0 are used by libvirt for arranging network > configurations for VMs, ok. However, br0 is a main interface of this > host with primary ip address, with enp0s25 being a physical nic of > this host, and it is used for all sorts of regular (unrelated to > virtualization) communications. Also, br0 is used for attaching > bridged (as opposed to NATed) VMs managed by libvirt. > > Clearly, libvirt somehow chooses to set up masquerading for literally > all existing network interfaces here (except lo), It's clear that the rules are there. It's not clear that they were added by libvirt. > but I can't see a real 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. > > Now I've discovered that I can "eliminate" the problem by either: > > 1. Removing "-A POSTROUTING -o br0 -j MASQUERADE" (manually) > 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? Except for putting the libvirt-added rules in their own private chains (appearing in libvirt 5.1.0, released on Feb 1, 2019), the iptables rules added by libvirt to support its virtual networks didn't materially change in > 10 years. Your email is the first time I've ever seen such rules attributed to libvirt so, as I said above, I think you need to take a deeper dive into your host system's config. Good luck!