Im running Windows Server 2008 R2, we have an application that connects from (binds to) a public IP on the server to 127.0.0.1:8334 [connects to a service listening on 0.0.0.0:8334]
In Windows 2003, there was no issue with this. We can connect using TCP from 126.96.36.199 [eg] to 127.0.0.1:8334 just fine.
In Windows 2008, we find that TCP connections from public ip e.g. 188.8.131.52 to 127.0.0.1:8334 fail, even. but the service accepts connections from 127.0.0.1 to 127.0.0.1:8334, and 127.0.0.1 to 184.108.40.206:8334.
Tried turning Windows firewall off, configuring its logging etc (no useful log entries showed up), to no avail. Is this an issue with the new networking stack?
220.127.116.11 is trying to connect to localhost [127.0.0.1] on the same machine
Hosts file is default Windows 2008 host file.
Loopback check info, interesting. Tried it out...didnt work. Crosschecked to verify that Id done everything correctly - I have.
Im wondering if there is a solution using NAT or some other way to forward ports - if I forward 127.0.0.1:port to 18.104.22.168:port, would that work? Given that the app listens on 0.0.0.0:port it would pick up connections on 22.214.171.124:port
The HOSTS file does contain localhost 127.0.0.1 - however, the hosts file is only used on hostname lookups. In this case, our application would not look up any hostname, since the 127.0.0.1 IP address is hardcoded into it (rather than localhost hostname). So the HOSTS file would not come into play here.
As for ports above 1024 [think you refer to the MaxUserPort issue perhaps?] I tested this out by trying a simple connect to port 445 - works from 127.0.0.1, doesnt work when I connect from source IP 126.96.36.199. 445 is a standard Windows service, so should work!
Currently not running NAT or RRAS on the machine...was wondering if there was a way to do the rerouting - Im guessing it wont work since the TCP/IP stack will reject the packet before it reaches the loopback interface to re-route.
Route print I had checked - seems fine, the public IPs routed first, then finally 127.0.0.0 netmask 255.255.255.0 and 127.0.0.1 netmask 255.255.255.255 both to loopback.
Edit Seems I have found the answer as to the reason for the problem. I used eventvwr.msc, enabled Winsock logging, turned off other services, just tried this connection test. Got an error which in hexadecimal mapped to STATUS_INVALID_ADDRESS_COMPONENT when I googled it.
Which confirmed that this is a change by design in WFP for Vista/7/Server 2008 [windows filtering platform].
[See response by Anupama Vasanth]
Looks like I will have to go the hard route and rewrite the code [hard because it means dealing with managers!]
Thank you for helping me locate/confirm the issue!