Because I know how to use ISA Server I relate to it as if it were my favorite child. But customers who know ISA Server less well don't feel this way, and usually put ISA Server in the wrong when they have problems that seem to be related to it.
I really like sniffers, because I can monitor the packet content using a sniffer - which ISA Server doesn’t provide. There are many sniffers you can choose, such as Microsoft network monitor.
Here's the case I want to share with you:
One of my customers reported that when users browse the Internet via ISA Server, they encounter error 64 - host not available very often.
KB 940659 is for error 64, but I thought it might not be suitable for this scenario - and it’s true, the problem continued after applying this update.
I wrote an article about how to resolve ISA Server’s Web filter’s compatibility problem in Chinese (http://www.ISACN.org/info/info.php?sessid=&infoid=323), so I let the customer follow this article to resolve it, but customer said there is no effect after following the steps in the article.
Well, I think this problem isn’t ISA Server’s problem at this step. But we need to find the root cause – let me find it! J
I captured the packets with a sniffer when the problem appeared, and analyzed it.
This figure below is when a user browses the Internet without a problem:
It’s clear and works fine:
Packet 1-3, three-way handshake between ISA Server computer and the remote Web server
Packet 4-5, http request from ISA Server computer to Web server
Packet 6 TCP ACK from Web server to ISA Server computer, followed by http response in packet 11
This figure below is when the client browses the Internet with problems:
But let us focus on packets 6-7 and 8, because they are strange!
Packet 6-7 The TCP connection is reset by Web server
Packet 8 TCP ACK from Web server to ISA Server computer
Because the remote Web server reset the connection, the problem appears.
But why did the Web server reset the connection? Let us look more closely:
Packet 8’s content is below (TCP ACK from Web server to ISA Server computer):
Packet 6’s content is below (The TCP connection is reset by Web server):
Just compare the TTL value, you can find these packets are sent by different hosts.
So we can reach the conclusion: a rogue host between ISA Server and the Web server reset the TCP connection before the Web server’s response, so users encounter error 64 when they browse.
It’s an ISP problem, not ISA Server’s.
Premier Field Engineer
Microsoft China Co Ltd
News Microsoft Internet Security and Acceleration Server Forefront Threat Management Gateway, the Next
And you don't think the second packet could have come from a different route?
What tool did you use to sniff packets?