Partager via

Error 64 - From the Field to the Classroom

  • Article

This week I’m delivering an ISA Server 2006 Workshop to Microsoft Premier Customers. While the training is going really well one thing that I notice was the following common question from students in the class: why sometimes I can’t access a website while I’m behind ISA and if I bypass ISA it works?

 

This is a really broad question and we need data to better understand what is causing such behavior. I’m assuming that all firewall policies are correctly configured and that you have no issues on that side. If this assumption is correct then the next question is: what it is the error message do you receive when tries to access the page behind ISA?

 

Situations like that needs precision on those answers and data gathering is essential for the success of the case. To give them an example that sometimes ISA just does what is suppose to do, I showed them the following scenario:

 

Client is trying to access a website through ISA Sever 2006 and logging shows the error below:

Error Code 64: Host not available

 

Error 64 is generic and I agree that doesn’t help at all. For this reason you need to dig in to find out what is going on otherwise it will be hard to determine the root cause. For this scenario a simple netmon trace helped us to determine the root cause:

- ISA Sends the request to the destination server:

- Http: Request, GET /

     Command: GET

   + URI: /

     ProtocolVersion: HTTP/1.1

     Via: 1.1 SRV

     UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; MS-RTC LM 8)

     Host: www.contoso.com

     Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */*

     Accept-Language: en-us

     UA-CPU: x86

     Connection: Keep-Alive

     HeaderEnd: CRLF

 

The destination server responds:

- Http: Response WebSite:

    _BuildHTTPConversation:

  - Response: 0x1

     ProtocolVersion: HTTP/1.0

     StatusCode: 302, Moved temporarily

     Reason: OK

     Server: XXXXX

     Location: https://srv.contoso.com

 

Looking closely to the binary details in netmon hex details pane we have the root cause for that:

48 54 54 50 2F 31 2E 30 20 33 30 32 20 4F 4B 20 28 43 6C 75 73 74 65 72 20 42 6F 6D 62 20 62 79 20 53 68 69 66 74 34 29 0D 0A 53 65 72 76 65 72 3A 20 41 70 61 63 68 65 2F 31 2E 33 2E 32 36 20 28 55 6E 69 78 29 0D 0A 4C 6F 63 61 74 69 6F 6E 3A 20 68 74 74 70 73 3A 2F 2F 73 65 72 76 65 72 31 31 2E 64 6F 6C 6C 61 72 73 6F 6E 74 68 65 6E 65 74 2E 6E 65 74 2F

The destination server does not terminate the response in accordance with RFC-2616. This RFC says:

“.. HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body”

From: https://www.ietf.org/rfc/rfc2616.txt

Therefore ISA correctly rejects it as malformed. What we should see in a normal HTTP Response is:

Conclusion: bypassing ISA as an attempt to proof that the issue is on ISA sometimes doesn’t prove the real point. ISA Server inspects the packet and act according to RFC for that protocol. If the destination server is not in accordance with that protocol ISA will correctly drop the packet as malformed.

They were surprise with the result and confident that from now on, they will research before blame ISA J.

Comments

  1. Another error 64? After posting one of the reasons why ISA Server 2006 can come up with the generic
  • Anonymous
    September 12, 2014
    It would be really useful if ISA gave slightly less generic messages...