Can't browse site by IP address that requires authentication. Page cannot be displayed.

One of the things I am trying to accomplish with my blog, is to shed some light on some IIS/ASP.Net issues that may be very common but that I have seen manifested in some "not so common" ways.  This post is about just one such instance.  Unlike some of my other posts, I am going to lead of with the summary of the problem and the solution and then I will discuss the way it was discovered.  The common issue here is that Windows Integrated Authentication requires that HTTP Keep-Alives be enabled in IIS.  This is a fairly well known and documented fact, however this was discovered in something of a less than traditional way.

I received a call from a customer who had updated Sharepoint on his IIS server and after restarting IIS, he was not able to browse any of his applications using the IP address of the machine.  He went on to say that he could browse the sites fine if he used the Netbios name of the machine from the local box as well as clients inside the domain. 

My first instinct was that something else (besides IIS) was listening on the IP address he was using on port 80.  A quick check of NETSTAT -ANO proved this not to be the case.  I decided to be doubly sure by changing the default web site to run on port 81 instead of 80 but still had the same result.  One thing we did notice was that when we were browsing by IP address, we were being prompted for credentials.  This is to be expected for sites that require Windows Integrated Authentication and are browsed using a FQDN or IP address.  After entering in correct credentials 3 times, we were getting "Page cannot be displayed".  Ok, so we knew we were hitting the right site and we knew we were entering the correct username and password so what was going on?  Well, it turns out that the customer had inadvertently turned off HTTP Keep Alives which was causing the authentication to fail.

All of this made sense now.  Clients inside the domain that were using the netbios name, were getting in because IE (by default) will pass the security token on to IIS in the intranet zone and the regular NTLM handshake isn't required.  When users outside the domain or when browsing using IP address, the Windows Integrated Auth handshake needed to occur.  The handshake was failing in these instances and thus the "Page cannot be displayed" response was given. 

Hopefully this will help someone who may be experiencing this same problem but hasn't been able to put the two seemingly unrelated facts together.

HTTP/1.1 200 OK