Bug 985653

Summary: The network should not be saved or defined successfuly if the start NAT address is large than the end address
Product: Red Hat Enterprise Linux 7 Reporter: Xuesong Zhang <xuzhang>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: cwei, dyuan, honzhang, rbalakri
Target Milestone: rcKeywords: Upstream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-1.2.17-5.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 05:43:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Xuesong Zhang 2013-07-18 03:12:52 UTC
Description of problem:
The network should not be saved or defined successfully if the start NAT address is large than the end address. 

Version-Release number of selected component (if applicable):
libvirt-0.10.2-20.el6
qemu-kvm-rhev-0.12.1.2-2.378.el6 
kernel-2.6.32-396.el6

How reproducible:
100%

Steps:
1. define and start the network like following, note the start address is large than the end address.
# virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>262de6f3-1d82-4ce1-b59e-48dfaf6daf09</uuid>
  <forward mode='nat'>
    <nat>
      <address start='10.66.4.211' end='10.66.4.190'/>
      <port start='1' end='3000'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:83:B4:AB'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
    </dhcp>
  </ip>
</network>

2. check the POSTROUTING.
# iptables -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       tcp  --  192.168.122.0/24    !192.168.122.0/24    to:10.66.4.211-10.66.4.190:1-3000 
SNAT       udp  --  192.168.122.0/24    !192.168.122.0/24    to:10.66.4.211-10.66.4.190:1-3000 
SNAT       all  --  192.168.122.0/24    !192.168.122.0/24    to:10.66.4.211-10.66.4.190 

3. edit the DHCP range, change the start address large than the end address like following, it will fail to save the modify.
......
<dhcp>
      <range start='192.168.122.200' end='192.168.122.100' />
    </dhcp>
......
# virsh net-edit default
error: XML error: Invalid dhcp range '192.168.122.200' to '192.168.122.100' in network 'default'
Failed. Try again? [y,n,f,?]:


Actual results:
as steps

Expected results:
The network should not be saved or defined successfully if the start NAT address is large than the end address. It should be prompt error like step 3.

Comment 4 Jiri Denemark 2014-04-04 21:37:46 UTC
This bug was not selected to be addressed in Red Hat Enterprise Linux 6. We will look at it again within the Red Hat Enterprise Linux 7 product.

Comment 7 Laine Stump 2015-05-26 19:49:45 UTC
Fix posted upstream:

https://www.redhat.com/archives/libvir-list/2015-May/msg01008.html

This checks several new conditions, including the condition pointed out in this BZ.

Comment 8 Laine Stump 2015-06-02 16:43:51 UTC
The following 4 patches have been pushed upstream to remedy the problem (in order of pushing):

commit 48e8b95d8ec3871d883e2f48f637b2f663e7b8fc
Author: Laine Stump <laine@laine.org>
Date:   Mon Jun 1 12:18:01 2015 -0400

    test: fix IP address range failure test
    
commit 1e334a0a000b70c8f0ab57d9fcaaa8cfc480759a
Author: Laine Stump <laine@laine.org>
Date:   Fri May 22 17:32:02 2015 -0400

    network: validate DHCP ranges are completely within defined network
    
commit 198d503c6428fb8c4a3c9e31331be8f1026a4dde
Author: Laine Stump <laine@laine.org>
Date:   Tue May 26 15:32:59 2015 -0400

    network: cleanup range loop in networkDnsmasqConfContents
    
commit 55ace7c4789c8a7408139460f4b639cee00e5125
Author: Laine Stump <laine@laine.org>
Date:   Tue May 26 15:44:24 2015 -0400

    util: report all address range errors in virSocketAddrGetRange()

Comment 11 hongming 2015-07-20 07:38:10 UTC
It is failed to validate the address range for NAT

# rpm -q libvirt
libvirt-1.2.17-1.el7.x86_64

# cat testnet.xml 
<network>
  <name>test</name>
  <forward mode='nat'>
    <nat>
      <address start='10.66.4.10' end='10.66.4.1'/> <==== wrong range 
      <port start='1' end='3000'/>
    </nat>
  </forward>
  <bridge name='virbr1' stp='on' delay='0' />
  <mac address='52:54:00:83:B4:AB'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
    </dhcp>
  </ip>
</network>

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

# virsh net-start test
Network test started

# virsh net-dumpxml test
<network>
  <name>test</name>
  <uuid>3c5fa0eb-e174-4d07-8c1f-f834f55b2d43</uuid>
  <forward mode='nat'>
    <nat>
      <address start='10.66.4.10' end='10.66.4.1'/>
      <port start='1' end='3000'/>
    </nat>
  </forward>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:83:b4:ab'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

Comment 12 Laine Stump 2015-08-08 22:07:57 UTC
derp.

This is what happens when I don't *carefully* read the bug report. I saw the problem that I wanted to see (failure to proper validate DHCP address ranges), and fixed that instead of fixing the (very similar) problem that was reported (failure to validate NAT address ranges).

I've generalized virSocketAddrGetRange() (which is used to validate address ranges) so that it can be used in both cases, and added validation of NAT address ranges. The patch is posted upstream, waiting for review:

https://www.redhat.com/archives/libvir-list/2015-August/msg00268.html

Comment 13 Laine Stump 2015-08-10 17:46:12 UTC
Pushed upstream:

commit a6f9af8292b6462e509892b3a16acbcaaef61e4e
Author: Laine Stump <laine@laine.org>
Date:   Sat Aug 8 17:46:41 2015 -0400

    network: validate network NAT range

Comment 16 hongming 2015-08-18 06:36:55 UTC
Verify it as follows. The result is expected. Move its status to VERIFIED.


# cat testnet.xml 
<network>
  <name>test</name>
  <forward mode='nat'>
    <nat>
      <address start='10.66.4.10' end='10.66.4.1'/> 
      <port start='1' end='3000'/>
    </nat>
  </forward>
  <bridge name='virbr1' stp='on' delay='0' />
  <mac address='52:54:00:83:B4:AB'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
    </dhcp>
  </ip>
</network>

# virsh net-define testnet.xml
error: Failed to define network from testnet.xml
error: internal error: range 10.66.4.10 - 10.66.4.1 is reversed 

# vim testnet.xml 
# cat testnet.xml 
<network>
  <name>test</name>
  <forward mode='nat'>
    <nat>
      <address start='10.66.4.1' end='10.66.4.10'/> 
      <port start='1' end='3000'/>
    </nat>
  </forward>
  <bridge name='virbr1' stp='on' delay='0' />
  <mac address='52:54:00:83:B4:AB'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.20' end='192.168.122.2' />
    </dhcp>
  </ip>
</network>

# virsh net-define testnet.xml
error: Failed to define network from testnet.xml
error: internal error: range 192.168.122.20 - 192.168.122.2 is reversed 

# virsh net-create testnet.xml
error: Failed to create network from testnet.xml
error: internal error: range 192.168.122.20 - 192.168.122.2 is reversed 

# virsh net-edit default
error: internal error: range 10.66.4.10 - 10.66.4.1 is reversed 
Failed. Try again? [y,n,f,?]: 

error: internal error: range 192.168.122.254 - 192.168.122.2 is reversed 
Failed. Try again? [y,n,f,?]:

Comment 18 errata-xmlrpc 2015-11-19 05:43:33 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.

https://rhn.redhat.com/errata/RHBA-2015-2202.html