Seems al fine (port forwarding AND static NAT) on 4.4.1. Just tested. @Rohit - Is it too late now to actually submit a bug for this port forwarding - and possibly backport to 4.3.2 ?
Thanks On 11 December 2014 at 10:25, Andrija Panic <andrija.pa...@gmail.com> wrote: > Static NAT (all port forwarding) - also broken, all connections to private > IP on VM, seems to come from main Public IP of VPC VR, instead of real > client's IP... :( > > Will test 4.4 and possibly 4.5rc now... > > On 10 December 2014 at 13:56, Andrija Panic <andrija.pa...@gmail.com> > wrote: > >> 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ć >> > > > > -- > > Andrija Panić > -- Andrija Panić
