Monday, May 04, 2009 4:09 PM
I am having an issue where a certain client is getting the following error:
Error Code 1460: Timeout
I checked the ISA logs and the following is logged (edited):
Failed Connection Attempt MYSERVER 05/01/2009 12:03:06 PM
Log type: Web Proxy (Reverse)
Status: 1460 This operation returned because the timeout period expired.
Rule: Secure Web Services for Fiddler
Source: External ( 126.96.36.199:0)
Destination: - ( 192.168.2.26:80)
Request: POST http://192.168.2.26/MyWebServices/MyWebService.asmx
Filter information: Req ID: 0b3255e0
Closed Connection MYSERVER 05/01/2009 12:03:06 PM
Log type: Firewall service
Status: A connection was gracefully closed in an orderly shutdown process with a three-way FIN-initiated handshake.
Source: Local Host ( 192.168.2.1:14706)
Destination: Internal ( 192.168.2.26:80)
Closed Connection MYSERVER 05/01/2009 12:03:08 PM
Log type: Firewall service
Status: A connection was abortively closed after one of the peers sent a RST segment.
Source: External ( 188.8.131.52:25562)
Destination: Local Host ( 184.108.40.206:443)
Here are the details about this issue:
- It can only be reproduced if it goes through ISA 2004. When the firewall is bypassed, it works as expected.
- It can only be reproduced when initiated on one of our client's machines (please see below for more details).
- It can only be reproduced if the request content-length is 1,716 or 7,194. Changing the length of the request body by even 1 character allows the request to go through successfully. Changing the content without changing the content length does not allow the request to go through successfully.
- ISA has the following error in the log: 1460 This operation returned because the timeout period expired. Please note that there is no way this request should take 120 seconds; when successful (e.g. change the content length by one character) it is well under a second.
- The issue cannot be reproduced on the client side if we use Fiddler as a proxy on the customer's end.
Since this could only be reproduced from our client's machines, I decided to create a virtual machine for testing both here and there. I ran some tests from another offsite location with this virtual machine and it worked as expected. I then had the client run the same virtual machine from their network (and firewall) and the issue was reproduced. The client then ran the same test from the virtual machine outside of their network (direct DSL connection) and the issue was reproduced. I found this a little odd.
I started Wireshark on the client's end and found that the entire request is being sent (3 ssl segments for the one that has an http content length of 1,716). However, shortly after there are a few TCP Retransmissions and then a "https > brvread [RST, ACK] Seq=1 Ack=1 Win=0 Len=0".
Running Wireshark on our end (after the firewall), I only see the first 2 ssl segments. The first is for the http header and the second is 1024 bytes of the body. The third segment doesn't make it.
I am not too familiar with this level of networking. I'm not sure where to look next. Any help would be greatly appreciated.
Tuesday, May 05, 2009 7:21 AMModerator
Thank you for your post.
I did some research regarding error message “1460 This operation returned because the timeout period expired”. This issue may related to HTTP compression. ISA disables compression by default for HTTP, whereas without ISA running, compression is apparently turned on by default. we may set compression on HTTP requests, so that ISA asks for compressed content when making requests to the internal network. Please refer to the following article.
Enabling HTTP Compression in ISA 2004
If the issue still retains, please perform the following steps(set the ConnectCacheSize registry value to 0):
1. Click Start, and then click Run.
2. In the Open box, type regedit, and then click OK.
3. Locate and then select the following registry subkey:
4. In the right pane, click ConnectCacheSize.
5. On the Edit menu, click Modify.
6. In the Value data box, type 0, and then click OK.
7. Quit Registry Editor.
For more information, please read the following articles:
ISA Server Web Proxy service maintains a connection after a client session is closed
ISA Server 2004 or ISA Server 2006 client computers may experience an excessive delay before their connection requests are served
Nick Gu - MSFT
- Proposed As Answer by Nick Gu - MSFTMicrosoft Contingent Staff, Moderator Wednesday, May 27, 2009 6:39 AM
Wednesday, May 06, 2009 7:36 PMThanks for the reply Nick. The ISA server in question is a production server. Unfortunately it is not easy for me to test your suggestions. I will need to test this either during off hours or I will need to set up a test ISA server (more likely). I will reply after trying your suggestions.
Friday, May 08, 2009 6:05 PMI have an update on this issue. In my original post I had mentioned that the problem only occurs if the data is sent from the client, either behind OR in front of the firewall. Well, I went on site and found that all previous tests were behind the firewall; none were in front of the firewall. I tested this myself and I could not reproduce this issue from the client location when a direct line (without a firewall) was used; I could only reproduce the issue if the traffic went through their firewall.
Today I set up a virtual machine with ISA 2004 and tested it, but I could not reproduce this issue. I even backed up the settings on the production server and restored them on the test server, but I still could not reproduce the issue. I'm not sure why I cannot reproduce this on the test ISA server.
I would love to try out your recommendations, but I can't do this on our live firewall; too many people could be affected. I could do it during off hours, but the client cannot (and it can only be reproduced when going through the client's firewall). I was really hoping that I could reproduce this issue on the test firewall so that I could test out your recommendations.
Is there anything else I can do to help narrow down the cause of this issue?
Saturday, June 06, 2009 6:21 PMModeratorNot sure if this is feasible for you or not but you could try and capture the traffic though net monitor so we can check it further. Alternative use the ISA repo feature to catch what goes on. One of the failings of this forum is that you can not attach outputs but there is likely a way you can display them somewhere?
I am assuming you have confirmed that the version of host OS/Service packs and ISA version, supportability pack, service packs, windows updates etc were identical on both the test system and the production system?
One other area is what is between the customers ISA Server and the Internet? Is anything going on there?
The last ditch approach is to simply remove and reinstall ISA. This would not take more than 30 minutes max and, as you have already stated, you have the config file to restore.
Monday, July 06, 2009 7:59 PMHi Keith,
Sorry for the delay in my response. My email provider recently changed how they handle spam, and unfortunately the email notification for your response got blocked. I just found out about your response today.
I have existing Wireshark captures of this issue from both the client side and our side. I am able to open these with Microsoft Network Monitor 3.3. Would this be sufficient? If so, I could make these available to you, but I would not like to make them public.
I am fairly certain that the updates, SPs, etc. were the same on both the test system and production system.
The customer doesn't have ISA Server (ISA Server 2004 is on our end). I'm not too familiar with their set up, but they said they haven't seen anything like this on their end.
I would not like to reinstall ISA Server at this point, unless there are no other options.
Thursday, June 03, 2010 2:27 PM
ISA server name / Configuration / Networks / Internal / Properties / Web Proxy / Advanced / Connection Timeout - increase time to requested value.
Default is 120 seconds.
Maybe simple, but I sought it hours.