Bug 433484 - libvirt: provide a way to disable automatic iptables configuration modification
libvirt: provide a way to disable automatic iptables configuration modification
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-19 11:19 EST by Tomas Hoger
Modified: 2016-09-05 13:00 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:39:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-02-19 11:19:36 EST
Description of problem:
libvirt automatically creates iptables rules for each started qemu network. 
Those rules are quite simple (read: either too open or too restrictive,
according to my experiments) and may not fit well with other (manually) created
firewall rules.

libvirt should provide a way to disable automatic creation of said rules
(ideally on per-network basis, but globally for all networks may be sufficient
too).  This is somewhat related / opposite of what's requested in bug #240924.

Version-Release number of selected component (if applicable):
libvirt-0.4.0-4.fc8

Steps to Reproduce:
1. Define some qemu network
2. Restart libvirtd
3. Check iptables -nvL
  
Actual results:
libvirt added some rules to a very top of INPUT and FORWARD chains.

Expected results:
iptables rules are not modified.
Comment 1 Daniel Berrange 2008-02-19 11:24:35 EST
First, it is already possible to avoid the iptables rules - simply do not
request a NAT based virtual network. The 'default' virtual network is
intentionally NAT based. You are free to remove this & default one which doesn't
provide NAT.

Second, if there are specific flaws you can enumerate with the current iptables
rules then file bugs about them. They are intended to allow only traffic from
guests attached to the network's associated bridge defautl (eg 'virbr0') & its
configured ip address range. So if this isn't working in some scenarios then we
need to know what those scenarios are so we can fix them.
Comment 2 Tomas Hoger 2008-02-19 11:54:39 EST
(In reply to comment #1)
> First, it is already possible to avoid the iptables rules - simply do not
> request a NAT based virtual network. The 'default' virtual network is
> intentionally NAT based. You are free to remove this & default one which
> doesn't provide NAT.

By not requesting NAT based virtual network you mean choosing "Isolated virtual
network" in virt-manager configuration wizard?  Or I there anything I'm missing?

When I create such isolated network, following rules are automatically created:

INPUT - allow dhcp and dns from that network
FORWARD
  FORWARD -i vnet0 -o vnet0 -j ACCEPT
  FORWARD -i vnet0 -j REJECT
  FORWARD -o vnet0 -j REJECT

So even if I want to allow some outgoing traffic from virtual network via my
default iptables rules, they are overridden by the rules above.

For NAT networks, all outgoing communication is permitted and again, I can't do
anything with my default rules to block it.

> Second, if there are specific flaws you can enumerate with the current
> iptables rules then file bugs about them. They are intended to allow only
> traffic from guests attached to the network's associated bridge defautl
> (eg 'virbr0') & its configured ip address range. So if this isn't working
> in some scenarios then we need to know what those scenarios are so we can
> fix them.

My scenario is simple - have an isolated network for virtual machines, from
where only connections to few selected ports are permitted.

And all I'm requesting is an option for user (that thinks (s)he) knows (s)he's
doing to use own iptables rules, or have some way to influence / work around
automatically generated rules.
Comment 3 Tomas Hoger 2008-02-24 06:02:41 EST
Thanks to hint from Eric Goirand, I managed to work around this problem with bit
of manual setup by creating bridge device using system network startup scripts:

/etc/sysconfig/network-scripts/ifcfg-br0
  DEVICE=br0
  TYPE=bridge
  STP=off
  ONBOOT=yes
  BOOTPROTO=dhcp / static
  ...

And changing network type in each virtual machine definition xml to bridge:

/etc/libvirt/qemu/<machine>.xml
  <interface type='bridge'>
    <source bridge='br0'/>
  </interface>


Daniel, is that the kind of setup you have mentioned in comment #1 or is
"Isolated virtual network" expected not to add any iptables rules?
Comment 4 Bug Zapper 2008-11-26 04:52:10 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Tomas Hoger 2008-11-26 05:16:46 EST
Ah, super annoying and fairly useless BugZapper auto-comments again...

As for this bug, I do not care about this much any more.  As noted in comment #3, there's a way to work around automatic netfilter rules handling done by libvirt.  I'm not sure whether interface type='bridge' can be specified via virt-manager gui, but it is possible with tools like virt-install and that works fine for me.  Feel free to re-close wontfix if you don't think libvirt should allow greater control over network filtering rules used for libvirt networks.
Comment 6 Bug Zapper 2009-01-09 02:39:58 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 7 Kent Tong 2011-10-19 11:04:29 EDT
Please reopen this bug. The problem with using a bridge for this case is that it 
is simply conceptually incorrect, not to mention the performance and security 
issues.

The fact is that the core task of virtual networking should be to operate the
virtual switch; what the host as a router does is not the main task. Currently
libvirt is imposing too much assumption/restriction on the routing behavior of 
the host and thus preventing other use cases such as:
a) NAT network (routing doing masquerading) can't support DNAT.
b) Isolated network can't support any kind of routing.

Both are perfectly fine use cases.
Comment 8 ArcFi 2013-01-08 23:58:10 EST
I need to allow access guests for determined IP-addresses over routed network.
But libvirtd.service automatically adds rules that allow access from any host:
-A FORWARD -d 10.0.0.0/24 -o virbr0 -j ACCEPT
-A FORWARD -s 10.0.0.0/24 -i virbr0 -j ACCEPT
This is unacceptable.
Comment 9 Vincent Gerris 2013-02-13 16:50:52 EST
Not sure if this what you want, but it may at least help:
http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
look at the forward incoming connections part.
A hook script is mentioned, which I now use to forward ports, because that was messed up by libvirtd as well.

You can use the same script to get the job done, by adding rules that prevent the mentioned ones from working.
It's a hack, but it works for me.
Perhaps that helps.
Agreed that the current situation is not ideal.
No clue why this has not been somehow improved, for example in a way fail2ban does.
Seems like a hard design decision?
Comment 10 Jamie Nguyen 2015-12-14 11:07:42 EST
For anyone who arrived here from a Google search (trying to disable the automatic iptables rules), check out my libvirt Networking Handbook [0]. You can create a Custom NAT-based network [1], which acts like the default network but puts you fully in control of your firewall.

[0]: https://jamielinux.com/docs/libvirt-networking-handbook/
[1]: https://jamielinux.com/docs/libvirt-networking-handbook/custom-nat-based-network.html
Comment 11 Niccolò Belli 2016-09-05 13:00:51 EDT
Hi Jamie, I'm here from a Google search as you expected :)
Is there any way to achieve the same for a routed networking?
I want to prevent tap interfaces from being added to the virtual bridge in routed networking. Getting rid of the virtual bridge would be even better. I want real routed networking because for security reasons I want strict control over communications between VMs. A bridging firewall is not a solution because it will have to rely on the IP set by the user.

Note You need to log in before you can comment on or make changes to this bug.