> 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/html/virtualization_deployment_and_administration_guide/sect-virtual_networking-applying_network_filtering
_______________________________________________
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
