git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Private Gateway SNAT Bug


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:rafaelweingartner@xxxxxxxxx] 
Sent: Tuesday, May 29, 2018 4:11 PM
To: dev <dev@xxxxxxxxxxxxxxxxxxxxx>
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 <slair@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> 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