9

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!

1

3 Answers 3

1

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.

0

Try connecting to 127.0.0.2 in Vista/win2k8 and above - sounds funny but it works. Had positive results with this in the past

-3

I most certain that it is connected with loopback check security feature though I cannot get in-depth detail how it is implemented, only how to overcome it:

http://chillicode.wordpress.com/tag/loopback-check/

And for "APPLIES TO" Windows 2008 see http://support.microsoft.com/kb/896861


Well, what is exactly is in your HOSTS file? I do not have W2008. Do you mean that there is no "127.0.0.1 localhost" there?

I also did read somewhere that default W2008 setup does not permit to communicate with ports greater than 1024.


You can submit feedback on MS Windows Server 2008 directly to MS team through

and they will reply

If you tried to switch off "loopback check" through method of registry editing then it requires reboot. Another one - not.

NAT inside machine? 127.0.0.1 is not forwarded or routed, I believe so, it is internal, you can unplug network card, your 1.2.3.4 will disappear but 127.0.0.1 will continue to be there .

What is output of your (Run--> cmd --> route print)?

There is one more moment, I was thinking, though I do not know how to put it together.

127.0.0.1 is localhost (interface), it is single-label name and considered local. 1.2.3.4 is non-singlelabel name.

Possible issues with this is that such name might have been considered external


Can you try, separately:

  1. Disabling (if it is enabled and enabling if it is disabled) IPv6 on network adapter?

  2. Putting some single-label name for 1.2.3.4 into HOSTS file?


What is corresponding event description, EventID, etc. in eventvwr.msc for failure to communicate from 1.2.3.4 to 127.0.0.1:8334 ?


"445 is a standard Windows service"

Is it for SMB-direct over TCP/IP? for file sharing? CIFS?

Not so reliable... It is constantly being hacked by MS hotfixes. Read:

("NetBIOS browsing across subnets may fail after upgrading to Windows Server 2008") - http://blogs.technet.com/b/networking/archive/2008/07/25/netbios-browsing-across-subnets-may-fail-after-upgrading-to-windows-server-2008.aspx?wa=wsignin1.0

Then,

"we have the same issue as described earlier with Vista SP2 machines trying to reach a Windows Server 2008 SP1 or SP2 file share. The file sharing service is protected by Windows Firewall with advanced security using a predefined rule for file sharing (SMB) reguesting a secure connection"

0

You must log in to answer this question.