Marcus, for outbound I meant Source NAT, sorry... Will check other Static NAT (all port forwarding) and will also test sinle port forwarding stuff on 4.4 or possibly 4.5. I see this as a serious issue for any VDC user... so will check...
On 9 December 2014 at 17:34, Marcus <shadow...@gmail.com> wrote: > 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 > > > -- Andrija Panić
