RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 769674 - libvirt adds iptables rules for bridge device of network with <forward mode='bridge'>
Summary: libvirt adds iptables rules for bridge device of network with <forward mode='...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 770964 (view as bug list)
Depends On: 760442
Blocks: CVE-2011-4600
TreeView+ depends on / blocked
 
Reported: 2011-12-21 17:17 UTC by RHEL Program Management
Modified: 2012-05-28 07:11 UTC (History)
14 users (show)

Fixed In Version: libvirt-0.9.4-23.el6_2.2
Doc Type: Bug Fix
Doc Text:
Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. While most of the erroneously added rules were of no significance, two of the rules could allow outside sources access to a private DNS server on the host (if the dns server was configured to listen on all interfaces). With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".
Clone Of:
Environment:
Last Closed: 2012-01-17 10:25:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0013 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2012-08-03 13:29:55 UTC

Description RHEL Program Management 2011-12-21 17:17:04 UTC 
This bug has been copied from bug #760442 and has been proposed
to be backported to 6.2 z-stream (EUS).
Comment 4 Laine Stump 2011-12-21 19:45:03 UTC 
A backport of the upstream fix has been posted to rhvirt-patches:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-December/msg00430.html
Comment 5 Daniel Veillard 2011-12-31 03:25:06 UTC 
*** Bug 770964 has been marked as a duplicate of this bug. ***
Comment 6 Huang Wenlong 2011-12-31 09:08:20 UTC 
Verify this bug with libvirt-0.9.4-23.el6_2.2.x86_64

1) save original iptables list
#iptables -v -n -L FORWARD >before.table
2) define a network via libvirt

    virsh net-dumpxml bridge-test
    <network>
    <name>bridge-test</name>
    <uuid>4277dd53-d0b8-4f14-bf00-133c172833ee</uuid>
    <forward mode='bridge'/>
    <bridge name='breth0' />
    <mac address='52:54:00:7D:A8:30'/>
    </network>

3) start "bridge-test" then restart libvirtd
#virsh net-start bridge-test

#service libvirtd restart

4) save new iptables list
#iptables -v -n -L FORWARD >after.table

5) diff iptables list there are some rules for breth0
#diff -uNr before.table after.table
#rpm -q libvirt
libvirt-0.9.9-0rc1.el6.x86_64

no new policy add for bridge .
Comment 7 Huang Wenlong 2011-12-31 09:10:44 UTC 
(In reply to comment #6)
> Verify this bug with libvirt-0.9.4-23.el6_2.2.x86_64
> 
> 1) save original iptables list
> #iptables -v -n -L FORWARD >before.table
> 2) define a network via libvirt
> 
>     virsh net-dumpxml bridge-test
>     <network>
>     <name>bridge-test</name>
>     <uuid>4277dd53-d0b8-4f14-bf00-133c172833ee</uuid>
>     <forward mode='bridge'/>
>     <bridge name='breth0' />
>     <mac address='52:54:00:7D:A8:30'/>
>     </network>
> 
> 3) start "bridge-test" then restart libvirtd
> #virsh net-start bridge-test
> 
> #service libvirtd restart
> 
> 4) save new iptables list
> #iptables -v -n -L FORWARD >after.table
> 
> 5) diff iptables list there are some rules for breth0
> #diff -uNr before.table after.table
> #rpm -q libvirt
> libvirt-0.9.9-0rc1.el6.x86_64

libvirt version is 0.9.4-23.el6_2.2.x86_64 not 0.9.9-0rc1.el6.x86_64

> no new policy add for bridge .
Comment 9 Huang Wenlong 2012-01-09 05:58:03 UTC 
As Comment 6   this bug is verified .
Comment 10 yuping zhang 2012-01-09 06:50:57 UTC 
Verified this issue with:
libvirt-client-0.9.4-23.el6_2.4.x86_64
libvirt-0.9.4-23.el6_2.4.x86_64
libvirt-python-0.9.4-23.el6_2.4.x86_64

Steps
1.# iptables -v -n -L FORWARD 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0   
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibited 

# cat bridge-test.xml 
  <network>
    <name>bridge-test</name>
    <uuid>4277dd53-d0b8-4f14-bf00-133c172833ee</uuid>
    <forward mode='bridge'/>
    <bridge name='rhevm' />
    <mac address='52:54:00:7D:A8:30'/>
  </network>

# virsh net-define bridge-test.xml 
Network bridge-test defined from bridge-test.xml

# virsh net-start bridge-test
Network bridge-test started

# /etc/init.d/libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

# iptables -v -n -L FORWARD 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0   
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibited
Comment 11 errata-xmlrpc 2012-01-17 10:25:31 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0013.html
Comment 12 Miroslav Svoboda 2012-01-17 11:50:22 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. This could cause the network to become unaccessible. With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".
Comment 13 Laine Stump 2012-01-20 04:14:35 UTC 
The effects of the erroneously added rules were improperly described in the Technical Notes. I modified it accordingly.
Comment 14 Laine Stump 2012-01-20 04:14:35 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. This could cause the network to become unaccessible. With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".+Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. While most of the erroneously added rules were of no significance, two of the rules could allow outside sources access to a private DNS server on the host (if the dns server was configured to listen on all interfaces). With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".
Note You need to log in before you can comment on or make changes to this bug.