Red Hat Bugzilla – Full Text Bug Listing
|Summary:||libvirt: provide a way to disable automatic iptables configuration modification|
|Product:||[Fedora] Fedora||Reporter:||Tomas Hoger <thoger>|
|Component:||libvirt||Assignee:||Daniel Veillard <veillard>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||8||CC:||berrange, darkbasic, fschwarz, icon, jamielinux, kent, vg.aetera, vgerris|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-01-09 02:39:58 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 Vladislav Grigoryev 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 . You can create a Custom NAT-based network , which acts like the default network but puts you fully in control of your firewall. : https://jamielinux.com/docs/libvirt-networking-handbook/ : 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.