[
https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002062#comment-15002062
]
ASF GitHub Bot commented on CLOUDSTACK-9050:
--------------------------------------------
Github user dsclose commented on the pull request:
https://github.com/apache/cloudstack/pull/1063#issuecomment-156103018
I've only used situational tests for this fix. I'll looking into the docs
regarding getting the integration tests up and running and will get back to you
in the next few days.
> Virtual Router Static-NAT rules bind to wrong public interface
> --------------------------------------------------------------
>
> Key: CLOUDSTACK-9050
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: ISO, Virtual Router
> Affects Versions: 4.5.2
> Reporter: dsclose
>
> When a virtual router has multiple public NICs (in a scenario where multiple
> guest subnets are available) the router is liable to create static-NAT rules
> for certain IP addresses that refer to incorrect interfaces.
> Example
> ----------
> A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are
> used for guest IP addresses. This may lead to the following IP addresses
> being assigned to a virtual router:
> eth0: 10.1.1.1/24
> eth1: 169.254.3.82/16
> eth2: 123.123.123.130/26 and 123.123.123.150/26
> eth3: 123.123.123.19/25 and 123.123.123.120/25
> Scenario:
> The user decides to create two static NATs. One from 123.123.123.120/25, the
> other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range.
> Result:
> 123.123.123.120/25 is successfully configured as a static NAT and works
> immediately. All NAT rules in the resulting iptables correctly refer to eth3
> as the source or destination interface. Cloudstack reports that
> 123.123.123.19/25 is successfully configured but it does not work. All NAT
> rules in the resulting iptables INCORRECTLY refer to eth2 as the source or
> destination interface.
> Cause:
> The virtual router greps the output of "ip addr show dev ethN" until it finds
> the IP address. However, this command also prints out the broadcast address
> for the subnet which may partially include an IP address from a similar
> range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2
> because the IP address was matched by the broadcast address of
> 123.123.123.191.
> This is liable to occur on any router with NICs on two similar subnets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
