Slair1 commented on issue #2680: Using Source NAT option on Private Gateway does not work URL: https://github.com/apache/cloudstack/issues/2680#issuecomment-395888889 @rhtyd @ustcweizhou @DaanHoogland Actually, thinking about this some more, why are we even creating a SNAT for traffic destined towards a guest network? Looking at the existing functionality: ~~~ 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 ~~~ `eth2` is the interface connected to the guest network. That SNAT doesn't even make sense. Nothing should have a source address of 10.0.0.0/24 if it is destined to the guest network (10.0.0.0/24). The only traffic with a source of 10.0.0.0/24 would be traffic originating from the vRouter itself - which would already have a source IP of 10.0.0.1. **Actually, we we shouldn't event have a SNAT at all, we should never be NAT'ing traffic destined towards a Guest network... The only exception to that is when using a Private Gateways with SNAT enabled - since a Private Gateway is treated as a Guest network.** Wouldn't this make more sense? ~~~ if self.address["source_nat"]: self.fw.append(["nat", "front", "-A POSTROUTING -o %s -j SNAT --to-source %s" % (self.dev, self.address['public_ip'])] ~~~ We don't even need this code at all: ~~~ else: self.fw.append(["nat", "front", "-A POSTROUTING -s %s -o %s -j SNAT --to-source %s" % (guestNetworkCidr, self.dev, self.address['public_ip'])]) ~~~ Thoughts?
---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
