Users Receive an error 64 when Browse a Web Site Published through ISA Sever 2006

1. Introduction

 

This post is based on a very interesting issue where an ISA Admin was publishing an internal Web Server that was working internally just fine for a while. Internally the web server was listening on port 82 and therefore the bridging configuration on the Web Publishing rule was correctly setup to HTTP 82. However when users were trying to browse from outside they received the error below:

 

 

Figure 1 – Error 64: host not available.

To better address this issue we need to gather more data.

2. Gathering Data

There are three main tools that can be used to isolate this issue:

· ISA Logging

· ISA Diagnostic Logging

· Netmon Trace

By gathering this data while the user was accessing the web site and getting the error it was possible to better understand what was happening. Let’s see:

1. ISA Serve Logging shows the error 64 and more details about the connection:

Figure 2- ISA Server Logging.

Notice in the details pane that:

· ISA is sending a GET for the FQDN of the internal web server.

· Error 64 here appears with more details saying that the network name is no longer available.

· Write down the Req ID because it will be used in the filter for Diagnostic Logging

2. Diagnostic Logging shows the following sequence of events:

Figure 3- Diagnostic Logging details.

The sequence shows:

· ISA Server sending the connect request to WSRVCT.contoso.msft on the IP 10.20.20.25 – both are correct.

· ISA Server is forwarding the correct path (/*)

· Target host header is showing as www.contoso.com

· Right after ISA Server sends this request to the target host the web server replies with a response status equals to 400.

3. Network trace shows more details about this 400

> ISA sends HTTP GET (notice the host header):

10.20.20.2 10.20.20.25 HTTP GET / HTTP/1.1, NTLMSSP_NEGOTIATE

Hypertext Transfer Protocol

GET / HTTP/1.1\r\n

Request Method: GET

Request URI: /

Request Version: HTTP/1.1

Reverse-Via: ISACONTN2, ISACONTN2\r\n

Host: www.contoso.com:82\\r\\n

Referer: https://www.contoso.com/CookieAuth.dll?GetLogon?curl=Z2F\&reason=0\&formdir=3\\r\\n

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)\r\n

Authorization:NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==\r\n

NTLMSSP

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*\r\n

Accept-Language: en-us\r\n

UA-CPU: x86\r\n

Cache-Control: no-cache\r\n

X-Experience: Premium\r\n

X-LogonType: Public\r\n

Connection: Keep-Alive\r\n

X-Experience: Premium\r\n

X-LogonType: Public\r\n

Content-Length: 0

\r\n

> IIS Server sends the Error 400:

10.20.20.25 10.20.20.2 HTTP HTTP/1.1 400 Bad Request (text/html)

Hypertext Transfer Protocol

HTTP/1.1 400 Bad Request\r\n

Request Version: HTTP/1.1

Response Code: 400

Content-Type: text/html\r\n

Date: Wed, 28 Jan 2009 16:52:41 GMT\r\n

Connection: close\r\n

Content-Length: 39

\r\n

Line-based text data: text/html

<h1>Bad Request (Invalid Hostname)</h1>

Now it is time to review the web server configuration since this error is being sent by IIS. By opening the properties of the IIS Default Web Site (which is the one that is being published) the first thing to check in this case is the host header. You might be asking: why host header? Because is after ISA Sends the GET with host header equals to www.contoso.com that we receive the error 400. Here is the result of the IIS Configuration in this case:

Figure 4 – Host header on IIS.

Now that explains why the error is happening. This web site is accepting requests only for this host header. Now what? Easy, just add “www.contoso.com” as an additional host header as shown below:

Figure 5- New host header added on IIS.

After that the publishing rule was working perfectly.

4. Conclusion

I always beat in the same key but it is important to emphasize over and over this to avoid wrong mind set: do not think that because it works internally and doesn’t works externally that the root cause is ISA. This is a clear and classic example of that. This article showed you how you can rapidly identify what is wrong in your publishing rule by using two native ISA troubleshooting features (Logging and Diagnostic Logging) plus network monitor traces.

Author

Yuri Diogenes

Security Support Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Thomas Detzner

Escalation Engineer

Microsoft CSS Forefront Security Edge Team