[
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434685#comment-15434685
]
ASF GitHub Bot commented on CLOUDSTACK-9339:
--------------------------------------------
GitHub user murali-reddy opened a pull request:
https://github.com/apache/cloudstack/pull/1659
CLOUDSTACK-9339 Virtual Routers don't handle Multiple Public Interfaces
correctly for non-vpc networks
As pointed out in CLOUDSTACK-9339, in case of multiple public IP's from
different public IP ranges are associated with VR, VR functionality is broken.
Below are the brief list of problems specific to non VPC networks addressed in
the PR.
- revere traffic for the connections accepted on the eth3 and above public
interfaces are getting blocked. Need a rule for e.g "-A FORWARD -i eth3 -o
eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT" in the filter table to
permit reverse path traffic
- outbound public traffic from eth0 to eth3 (and above) needs rule to run
through FW_OUTBOUND chain in the filter table
- network stats on public interfaces eth3 are getting gathered
- default gateway is missing in the device specific routing table,
resulting in traffic to be looked up in main routing table
- reating a device specific route table is generating "from all lookup
Table_eth3" in the
ip rules, resulting in traffic getting blocked.
Picked few commits from #1519 from dsclose
(https://github.com/apache/cloudstack/pull/1519) submitted for 4.7
Marvin tests are added to test below
- Static NAT works on the public interfaces above eth2, in case non-vpc
networks
- Portforwarding works on the public interfaces above eth2, in case non-vpc
networks
- Route tables are configured as expected for the device specific table for
the public interfaces above eth2, in case non-vpc networks
- IP tables rules are as expected for the traffic from and to the public
interfaces above eth2, in case non-vpc networks
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/murali-reddy/cloudstack
multiple_public_ip_ranges_non_vpc
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1659.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1659
----
commit af55d84a0954a50d88387660a47c5eb3be09c8c0
Author: dean.close <dean.cl...@icloudhosting.com>
Date: 2016-04-27T09:08:23Z
CLOUDSTACK-9339: Allow forwarding and collect network stats on any public
interface.
commit 7a2334d5c642a61f9275da240f834411ece5ced1
Author: Murali Reddy <muralimmre...@gmail.com>
Date: 2016-08-23T21:41:36Z
only mark packets arriving on public interfaces. On guest networ interfaces
mark only when they are part of static nat. this will ensure device specific
routing table will be used
commit e85a638c751c8c5fab234176c1772e22a16d4431
Author: dean.close <dean.cl...@icloudhosting.com>
Date: 2016-04-27T08:49:25Z
CLOUDSTACK-9339: Add default gateway to device-specific routing tables.
commit fa2d3332b6b953341604091c005bec64224585c9
Author: Murali Reddy <muralimmre...@gmail.com>
Date: 2016-08-23T21:46:04Z
smoke tests for multiple public ip ranges for non-vpc network scenarios
----
> Virtual Routers don't handle Multiple Public Interfaces
> -------------------------------------------------------
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Affects Versions: 4.8.0
> Reporter: dsclose
> Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple
> public interfaces. These are more pronounced on redundant virtual router
> setups. I have not attempted to examine these issues in a VPC context.
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The
> master.py script is responsible for setting public interfaces to UP during a
> keepalived transition. Currently the check_is_up method of the CsIP class
> brings all interfaces UP on both RvR. A proposed fix for this has been
> discussed on the mailing list. That fix will leave public interfaces DOWN on
> RvR allowing the keepalived transition to control the state of public
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers.
> Assuming public interfaces should be default be DOWN on an RvR we need to
> accommodate the fact that, as interfaces are created, no keepalived
> transition occurs. This means that assigning an IP from a new public subnet
> will have no effect (as the interface will be down) until the network is
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two
> iptables rules in the FORWARD chain of the filter table created for eth2 that
> allow forwarding between eth2 and eth0. Equivalent rules are not created for
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead,
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New
> connections from guests that are destined for public networks are processed
> like so:
> 1. Traffic is matched against the following rule in the mangle table that
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark
> 0x0/0xffffffff
> 2. There are no "ip rule" statements that match a connection marked 0x0, so
> the kernel routes the connection via the default gateway. That gateway is on
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
