Windows Server 2008 - Connecting to 127.0.0.1

10,351

Don't forget, in windows 2008, the firewall is turned on by default. This potentially can block any & all traffic even on the loopback interface. Additionally, if you bind to 0.0.0.0, you are accepting connections on ALL interfaces. The firewall would still block this. You could try turning off the firewall while testing... and then turn it back on. I haven't had any issues connecting to various programs I have developed on 127.0.0.1.

Share:
10,351

Related videos on Youtube

Kara Marfia
Author by

Kara Marfia

"We teach what we need to learn. We preach what we need to do. We write what we need to know." - E. Taliaferro Writing the Perfect Question

Updated on September 17, 2022

Comments

  • Kara Marfia
    Kara Marfia almost 2 years

    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 1.2.3.4 [eg] to 127.0.0.1:8334 just fine.

    In Windows 2008, we find that TCP connections from public ip e.g. 1.2.3.4 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 1.2.3.4: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?

    edits

    1.2.3.4 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 1.2.3.4:port, would that work? Given that the app listens on 0.0.0.0:port it would pick up connections on 1.2.3.4: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 1.2.3.4. 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.

    That got me to: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/d7cb6138-3f67-4467-a068-8325f56739ba

    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!

    • Admin
      Admin almost 14 years
      Are, in your description, 1.2.3.4 and 127.0.0.1 on the same machine? What do you have for them in hosts file?