1035336 – iptables rules not properly updated in some cases by net-update

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 1035336 - iptables rules not properly updated in some cases by net-update

Summary: iptables rules not properly updated in some cases by net-update

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	libvirt
Sub Component:
Version:	7.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Laine Stump
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2013-11-27 15:07 UTC by Laine Stump
Modified:	2014-06-18 01:00 UTC (History)
CC List:	6 users (show)
Fixed In Version:	libvirt-1.1.1-15.el7
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2014-06-13 10:43:38 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Laine Stump 2013-11-27 15:07:33 UTC

1) if the change to a network definition causes the dhcp service for the network to be no longer needed (or creates the need for a dhcp service), the mangle rule that fixes up the checksum of DHCP responses will not be added/removed.

2) In general, if any change to the network would create the need for a change in the iptables rules for that network, libvirt attempts to remove the *new* rules, then re-add those same rules (because it is doing its rule removal after updating the network definition. Instead, the old rules should be removed based on the old state of the network definition, then after updating the definition, new rules should be added.


(1) can result in a failure to get dhcp addresses by some older clients. (2) can result in old unwanted iptables rules sticking around on the system. These rules may or may not have an adverse effect.

Comment 1 Laine Stump 2013-12-11 11:19:08 UTC

The following patch was pushed upstream:

commit 54f9492353170b1ffc78a44c06ed3f9ecaab6ccf
Author: Laine Stump <laine>
Date:   Wed Nov 27 17:07:34 2013 +0200

    network: properly update iptables rules during net-update

Comment 4 hongming 2013-12-19 06:43:03 UTC

Verify it as follows. The result is expected.Move its status to VERIFIED.

Versions
libvirt-1.1.1-15.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64
kernel-3.10.0-33.el7.x86_64


[root@localhost images]# virsh net-list 
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default1             active     no            yes

[root@localhost images]# virsh net-dumpxml default1
<network>
  <name>default1</name>
  <uuid>7392199b-dd2e-44f5-a260-1f71ee9db6fb</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr1' stp='on' delay='0' />
  <mac address='52:54:00:71:f8:62'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
      <host mac='12:34:56:78:90:ac' name='aaa' ip='192.168.122.123' />
    </dhcp>
  </ip>
</network>

[root@localhost images]# iptables -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24    
POSTROUTING_direct  all  --  anywhere             anywhere            
POSTROUTING_ZONES_SOURCE  all  --  anywhere             anywhere            
POSTROUTING_ZONES  all  --  anywhere             anywhere            

[root@localhost images]# virsh net-update default1 delete ip-dhcp-host "<host mac='12:34:56:78:90:ac' name='aaa' ip='192.168.122.123' />"
Updated network default1 live state

[root@localhost images]# virsh net-update default1 add ip-dhcp-host "<host mac='12:34:56:78:90:ac' name='bbb' ip='192.168.122.123' />"
Updated network default1 live state

[root@localhost images]# cat /var/lib/libvirt/dnsmasq/default1.hostsfile
12:34:56:78:90:ac,192.168.122.123,bbb

[root@localhost images]# iptables -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24    
POSTROUTING_direct  all  --  anywhere             anywhere            
POSTROUTING_ZONES_SOURCE  all  --  anywhere             anywhere            
POSTROUTING_ZONES  all  --  anywhere             anywhere            

[root@localhost images]# virsh net-update default1 delete ip-dhcp-range "<range start='192.168.122.2' end='192.168.122.254' />"
Updated network default1 live state

[root@localhost images]# virsh net-update default1 add ip-dhcp-range "<range start='192.168.122.3' end='192.168.122.253' />"
Updated network default1 live state

[root@localhost images]# cat /var/lib/libvirt/dnsmasq/default1.conf|grep dhcp-range
dhcp-range=192.168.122.3,192.168.122.253

[root@localhost images]# iptables -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24    
POSTROUTING_direct  all  --  anywhere             anywhere            
POSTROUTING_ZONES_SOURCE  all  --  anywhere             anywhere            
POSTROUTING_ZONES  all  --  anywhere             anywhere  

Check guest' network simultaneously ,it works fine

Comment 5 Ludek Smid 2014-06-13 10:43:38 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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