Thanks! On Tue, May 29, 2018 at 6:40 PM, Sean Lair <sl...@ippathways.com> wrote:
> No problem! > > https://github.com/apache/cloudstack/issues/2680 > > Also, create a possible Pull Request: > > https://github.com/apache/cloudstack/pull/2681 > > > > > -----Original Message----- > From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] > Sent: Tuesday, May 29, 2018 4:11 PM > To: dev <dev@cloudstack.apache.org> > Subject: Re: Private Gateway SNAT Bug > > 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 > -- Rafael Weingärtner
