Bug 433484

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.

(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.

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?

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

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.

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.

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.

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.

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?

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

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.