[
https://issues.apache.org/jira/browse/CLOUDSTACK-10379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494264#comment-16494264
]
Sean Lair edited comment on CLOUDSTACK-10379 at 5/29/18 9:05 PM:
-----------------------------------------------------------------
[~weizhou] Here is the command output:
{code:java}
root@r-313-VM:~# ip route
default via 46.99.52.1 dev eth1
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
10.101.141.0/30 dev eth3 proto kernel scope link src 10.101.141.2
46.99.52.0/26 dev eth1 proto kernel scope link src 46.99.52.18
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.2.12
192.168.10.0/24 via 10.101.41.1 dev eth3
root@r-313-VM:~# ip rule
0: from all lookup local
32761: from all fwmark 0x3 lookup Table_eth3
32762: from all fwmark 0x2 lookup Table_eth2
32763: from all fwmark 0x1 lookup Table_eth1
32764: from 10.0.0.0/16 lookup static_route_back
32765: from 10.0.0.0/16 lookup static_route
32766: from all lookup main
32767: from all lookup default
root@r-313-VM:~# ip route show table Table_eth1
default via 49.99.52.1 dev eth1 proto static
root@r-313-VM:~# ip route show table Table_eth2
root@r-313-VM:~# ip route show table Table_eth3
{code}
was (Author: slair1):
[~weizhou] Here is the command output:
{code:java}
root@r-313-VM:~# ip route
default via 46.99.52.1 dev eth1
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
10.101.141.0/30 dev eth3 proto kernel scope link src 10.101.141.2
46.99.52.0/26 dev eth1 proto kernel scope link src 46.99.52.18
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.2.12
root@r-313-VM:~# ip rule
0: from all lookup local
32761: from all fwmark 0x3 lookup Table_eth3
32762: from all fwmark 0x2 lookup Table_eth2
32763: from all fwmark 0x1 lookup Table_eth1
32764: from 10.0.0.0/16 lookup static_route_back
32765: from 10.0.0.0/16 lookup static_route
32766: from all lookup main
32767: from all lookup default
root@r-313-VM:~# ip route show table Table_eth1
default via 49.99.52.1 dev eth1 proto static
root@r-313-VM:~# ip route show table Table_eth2
root@r-313-VM:~# ip route show table Table_eth3
{code}
> Using Source NAT option on Private Gateway does not work
> --------------------------------------------------------
>
> Key: CLOUDSTACK-10379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VPC
> Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
> Reporter: Sean Lair
> Priority: Minor
> Labels: patch
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> There is a bug in the Private Gateway functionality, when Source NAT is
> enabled for the Private Gateway. When the SNAT is added to iptables, it has
> the source CIDR of the private gateway subnet. Since no VMs live in that
> private gateway subnet, the SNAT doesn’t work. Below is an example:
>
> * VMs have IP addresses in the 10.0.0.0/24 subnet.
> * The Private Gateway address is 10.101.141.2/30
>
> See the outputs below, see how the SOURCE field for the new SNAT (eth3) only
> matches if the source is 10.101.141.0/30? Since the VM has an IP address in
> 10.0.0.0/24, the VMs don’t get SNAT’d as they should when talking across the
> private gateway. The SOURCE should be set to ANYWHERE.
>
> BEFORE ADDING PRIVATE GATEWAY
> -----------------------------------------------
> {code:java}
> Chain POSTROUTING (policy ACCEPT 1 packets, 52 bytes)
> pkts bytes target prot opt in out source destination
> 2 736 SNAT all -- any eth2 10.0.0.0/24 anywhere
> to:10.0.0.1
> 16 1039 SNAT all -- any eth1 anywhere anywhere
> to:46.99.52.18{code}
>
> AFTER ADDING PRIVATE GATEWAY W/ SNAT
> -----------------------------------------------
> {code:java}
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 SNAT all -- any eth3 10.101.141.0/30 anywhere
> to:10.101.141.2
> 2 736 SNAT all -- any eth2 10.0.0.0/24 anywhere
> to:10.0.0.1
> 23 1515 SNAT all -- any eth1 anywhere anywhere
> to:46.99.52.18
> {code}
>
> It looks like CsAddress.py treats the creation of the Private Gateway SNAT
> as if it is a GUEST network, which works fine, except for the SNAT problem
> shown above. Here is the code from MASTER (line 479 is SNAT rule):
>
> {code:java}
> if self.get_type() in ["guest"]:
> ...
> ...
> self.fw.append(["nat", "front",
> "-A POSTROUTING -s %s -o %s -j SNAT --to-source %s" %
> (guestNetworkCidr, self.dev, self.address['public_ip'])])
> {code}
>
> I am thinking we just change that to the following. I can’t think of any
> reason we need the source/guest CIDR specified:
>
> {code:java}
> if self.get_type() in ["guest"]:
> ...
> ...
> self.fw.append(["nat", "front",
> "-A POSTROUTING -o %s -j SNAT --to-source %s" %
> (self.dev, self.address['public_ip'])])
> {code}
>
> THE NAT TABLE IF THE ABOVE CODE CHANGE IS MADE
> -----------------------------------------------
> {code:java}
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 SNAT all -- any eth3 anywhere anywhere
> to:10.101.141.2
> 2 736 SNAT all -- any eth2 anywhere anywhere
> to:10.0.0.1
> 23 1515 SNAT all -- any eth1 anywhere anywhere
> to:46.99.52.18
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
