You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by GitBox <gi...@apache.org> on 2018/05/29 21:26:23 UTC

[GitHub] Slair1 opened a new issue #2680: Using Source NAT option on Private Gateway does not work

Slair1 opened a new issue #2680: Using Source NAT option on Private Gateway does not work
URL: https://github.com/apache/cloudstack/issues/2680
 
 
   <!--
   Verify first that your issue/request is not already reported on GitHub.
   Also test if the latest release and master branch are affected too.
   Always add information AFTER of these HTML comments, but no need to delete the comments.
   -->
   
   ##### ISSUE TYPE
   <!-- Pick one below and delete the rest -->
    * Bug Report
   
   ##### COMPONENT NAME
   <!--
   Categorize the issue, e.g. API, VR, VPN, UI, etc.
   -->
   ~~~
   VPC (Private Gateway Source NAT)
   ~~~
   
   ##### CLOUDSTACK VERSION
   <!--
   New line separated list of affected versions, commit ID for issues on master branch.
   -->
   
   ~~~
   At least: 4.9, 4.10, and 4.11
   ~~~
   
   ##### CONFIGURATION
   <!--
   Information about the configuration if relevant, e.g. basic network, advanced networking, etc.  N/A otherwise
   -->
   When you use the Source NAT feature of Private Gateways on a VPC.  This should Source NAT all traffic from CloudStack VMs going towards IPs reachable through Private Gateways
   
   ##### OS / ENVIRONMENT
   <!--
   Information about the environment if relevant, N/A otherwise
   -->
   I happen to be running KVM, but shouldn't be hypervisor specific.  it is an issue in the SystemVM / VPC Router
   
   ##### SUMMARY
   <!-- Explain the problem/feature briefly -->
   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.  
   
   ##### STEPS TO REPRODUCE
   <!--
   For bugs, show exactly how to reproduce the problem, using a minimal test-case. Use Screenshots if accurate.
   
   For new features, show how the feature would be used.
   -->
   
   <!-- Paste example playbooks or commands between quotes below -->
   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
    
   In the outputs below, 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
   ~~~
   
   <!-- You can also paste gist.github.com links for larger files -->
   
   ##### EXPECTED RESULTS
   <!-- What did you expect to happen when running the steps above? -->
   
   ~~~
   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
   ~~~
   
   ##### ACTUAL RESULTS
   <!-- What actually happened? -->
   
   <!-- Paste verbatim command output between quotes below -->
   ~~~
   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
   ~~~
   ##### SUGGESTED FIX
   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'])])
   ~~~
   
   ##### More Information
   Here is a link I found that further documents the Private Gateway Source NAT feature:
   
   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Source+NAT+on+private+gateway
   
   Notice, how in the SNAT shown it does not specify a source guest network CIDR - my above fix matches the example in the link above.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services