Yeah, that seems strange. I don't recall it working that way in the past. It uses the standard iptables DNAT, and I believe the same methods as static NAT to rewrite the destination ip. Do you see the same behavior with static NAT on routing incoming traffic to a particular VM?
Just to make sure we're not confusing terms here, static NAT is a port forward for all ports, basically mapping IP2 in whole to an instance. I think you're referring to SNAT (source NAT) when you say outbound static NAT looks fine, but I'm not sure. On Mon, Dec 8, 2014 at 11:19 PM, Andrija Panic <andrija.pa...@gmail.com> wrote: > Hi Marcus, > static NAT (outound connections) works fine - when internal VM access > internet, it's source address is replaced with the MAIN public IP of the > VPC VR (call it IP1 in my example - x.x.x.x) - so all fine. > > Then I have additional public IPs to be able to do port forwarding... - > when I do port forwarding on IP2 x.x.x.y (additional public IP on VR) to > the internal IP on VM - the VR actually does some kind of proxying so to > speak - so the source IP in the TCP/UDP packet that reach internal VM IP, > appears to be the IP1 x.x.x.x (main public IP of the VR) instead the real > remote IP of the client... > > Will check the scripts - but this is serious issue in my opinion. I > understand proxying (haproxy) works like every proxy - so the behaviour for > the proxy is expected. But this behaviour for the port forwarding is NOT > normal at all... > > THanks >
