Bug 769674
| Summary: | libvirt adds iptables rules for bridge device of network with <forward mode='bridge'> | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | RHEL Program Management <pm-rhel> |
| Component: | libvirt | Assignee: | Laine Stump <laine> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.2 | CC: | acathrow, ajia, dallan, djasa, jpallich, kreilly, laine, msvoboda, mzhan, pm-eus, rwu, whuang, xhu, yupzhang |
| Target Milestone: | rc | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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".
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-17 10:25:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 760442 | ||
| Bug Blocks: | 765964 | ||
|
Description
RHEL Program Management
2011-12-21 17:17:04 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 *** Bug 770964 has been marked as a duplicate of this bug. *** 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 .
(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 . 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
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
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".
The effects of the erroneously added rules were improperly described in the Technical Notes. I modified it accordingly.
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".
|