Thanks Sean. Can you do something for us? Can you open an issue at https://github.com/apache/cloudstack/issues/? We decided not to use Jira anymore. Also, can you close the jira ticket?
On Tue, May 29, 2018 at 6:08 PM, Sean Lair <sl...@ippathways.com> wrote: > Opened up Issue with more info: > > https://issues.apache.org/jira/browse/CLOUDSTACK-10379 > > > -----Original Message----- > From: Sean Lair > Sent: Tuesday, May 29, 2018 12:08 PM > To: dev@cloudstack.apache.org > Subject: Private Gateway SNAT Bug > > I've found 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 > ----------------------------------------------- > 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 > > AFTER ADDING PRIVATE GATEWAY W/ SNAT > ----------------------------------------------- > 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 > > > 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): > > > 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'])]) > > I am thinking we just change that to the following. I can't think of any > reason we need the source/guest CIDR specified: > > 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'])]) > > > THE NAT TABLE IF THE ABOVE CODE CHANGE IS MADE > ----------------------------------------------- > 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 > > Thoughts everyone? > > -- Rafael Weingärtner
