Am Donnerstag, den 30.05.2019, 21:44 -0400 schrieb Joshua Kramer:

...

Hello All-

I've looked in several places and haven't found an answer to this question: is it possible to have libvirt add custom rules to iptables for virtual network interfaces? I took a look at the "Firewall and Network Filtering in Libvirt" page and it seems overly complicated for what I want to do.

Given an interface virbr2 and its network 192.168.4.0/24, libvirt installs the following rules in iptables. Essentially, these rules will drop any packets for the interface virbr2 where the source or destination is not on the 192.168.4.0/24 network.

-P FORWARD ACCEPT -A FORWARD -d 192.168.4.0/24 -o virbr2 -j ACCEPT -A FORWARD -s 192.168.4.0/24 -i virbr2 -j ACCEPT -A FORWARD -i virbr2 -o virbr2 -j ACCEPT -A FORWARD -o virbr2 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr2 -j REJECT --reject-with icmp-port-unreachable

I have a VPN server on the 4/24 network- and it hands out addresses in the 8/24 network. So I would like libvirt to also create the following rules in iptables:

-A FORWARD -d 192.168.8.0/24 -o virbr2 -j ACCEPT -A FORWARD -s 192.168.8.0/24 -i virbr2 -j ACCEPT

I've tried creating direct rules in firewalld for the FORWARD_direct chain. Firewalld happily creates those rules, but they are never reached, because they fall AFTER the libvirt rules. I've also tried creating an IP address on the virbr2 interface in the 8/24 network, but that doesn't work either. How can I get this done?

On 5/31/19 10:42 AM, nakata wrote:

Hi,

libvirts nwfilter module can achieve that.

In general it is true that nwfilter can add iptables (or more commonly ebtables) rules. But I don't think it can do what is being requested by Joshua since those rules are not only specific to the guest interface, but also are applied *in addition to* the iptables rules added by the libvirt network, not *instead of*. Much of what nwfilter does is via the ebtables "nat" table, not input/output/forward. So any rules you added using nwfilter would only be traversed by traffic going in or out of a particular guest's tap interface, and even after it passed that, it would *still* be subject to the iptables rules added by the network (which may be more restrictive - in this case, even though the packets with the source address on the VPN would be able to get past the guest's tap device onto the bridge, they would then be subject to the iptables rules when trying to leave the bridge).

I'm currently working on opt-out patches to disable that functionality if wished. I also don't use firewalld.

What are you trying to "opt out" of? If your libvirt network has <forward mode='open'/> then there will be no iptables rules created at all. (Similarly, if you don't like the DHCP service that is setup for a libvirt virtual network, remove the <dhcp> section from the network's config before you start it, and if you don't like the provided DNS server, add <dns enable='no'/> to the network config). (<forward mode='open'/> and <dns enable='no'/> have been in libvirt since v2.2.0. It has always been possible to disable the auto-configured dhcp server by removing the <dhcp> section).

It's both paternalizing and annoying and takes away user flexilibity in exchange for nothing.

libvirt's virtual networks aren't taking away flexibility for nothing. They are a convenience that was added specifically to make it as simple as possible to set up a usable network connection that fits the needs of 95% of users. In order to make it as foolproof as possible, by design it has just a few presets with limited configuration (although the amount of configuation possible has grown a bit over the years as various things have shown themselves to be commonly needed). Anyone with needs more complex than what can be satisfied by libvirt's few preset modes and configuration knobs can easily setup their own bridge device, iptables rules, and dnsmasq instance outside of libvirt in the host system config (or you can turn various parts of it off, using the options described above, and still use the rest of what libvirt creates. So, if you just need flexibility for iptables rules, use <forward mode='open'/>. If you need full flexibility, then don't use a libvirt virtual network - setup your own bridge, and configure the guest interfaces with <interface type='bridge'>.

anyways Check the nwfilter page to write own filters for the beginning: https://libvirt.org/formatnwfilter.html#nwfwrite

some more info: https://www.redhat.com/archives/libvir-list/2010-June/msg00762.html

This is a very informative and useful email. For that reason, it was formatted and put into libvirt's official documentation here: https://libvirt.org/firewall.html There have been a few changes/additions over the years (although not many!) so that is a better reference document. (if that email is referenced somewhere in the wiki or something, we should change it to point to the docs page)

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...