[libvirt-users] Easy solution for custom firewall rules- is it possible?

Laine Stump laine at redhat.com
Mon Jun 3 16:53:13 UTC 2019

 > 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, 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 network.
 >> -A FORWARD -d -o virbr2 -j ACCEPT
 >> -A FORWARD -s -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 -o virbr2 -j ACCEPT
 >> -A FORWARD -s -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 

> 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:


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/html/virtualization_deployment_and_administration_guide/sect-virtual_networking-applying_network_filtering

More information about the libvirt-users mailing list