Expect the unexpected… Failed Connection 995 and 64 with SSL Traffic
When speaking with customers, we hear a lot of questions around “unexpected” errors like “Failed Connection Error 995 Operation Aborted” and “Failed Connection Error 64 Net name Deleted” in the ISA/TMG logs. The main concern here is always if these errors are real errors and how to prevent them.
These errors occur most of the time when SSL traffic is involved.
First of all, if you see those errors: “Don’t Panic” ;-)
These errors are expected in most scenarios, where you’re using ISA 200x or TMG without SSL Inspection.
In this blog I want to provide some background about these errors, and why they are not an indication for an actual error in most cases.
Another good article about these errors had been published by Thomas Detzner covering the connection of these with RPC/HTTP publishing (http://blogs.technet.com/b/isablog/archive/2007/06/25/rpc-over-http-logging-wildness.aspx )
Why 995 and 64?
You may wonder why we’re not logging any HTTP Error codes but use error numbers like 995 or 64 instead. The answer to this question is quite simple: ISA/TMG are both running on Microsoft Windows, as you might have noticed J, where Error 995 and 64 are both standard error codes of the Win32 API, which are defined in the Winerror.h header file (http://msdn.microsoft.com/en-us/library/ms819773.aspx). This file contains the definitions for the standard error codes for Win32 API functions.
But why doesn’t ISA 200x and TMG log the result codes defined in the HTTP RFC?
This question directly leads to the cause of the failed connection attempt log entries, and is quite simple:
“Because it can’t!”
ISA 200x and TMG without HTTPSi can’t look inside the SSL tunnel in forward proxy scenario, once the tunnel is established. Please keep in mind that the SSL tunnel is established between the client and the SSL server and it is an end to end relation. Therefore ISA/TMG has no clue about the traffic inside of the SSL Tunnel, and can’t make any assumptions on why a connection has been closed by the client or the server on the other end.
For more information about the SSL Tunnel setup over a proxy and how TMG HTTPSi changes this scenario please have a look at this article: http://technet.microsoft.com/en-us/magazine/ff472472.aspx
But how can I troubleshoot SSL connection issues then?
Unfortunately the ISA / TMG live logging is not the best tool to troubleshoot SSL connection issues. If you have to troubleshoot these issues, the first thing to start with is to verify the web server logs. if you can access them, or you will need to analyze the network traces. You want to do this ideally on all participating network devices and try to identify any issues with the SSL Handshake, any kind of packet loss or with delays happening during a SSL session.
If this approach doesn’t show any indications what’s going wrong you have to troubleshoot SSL. Next step should always be to either turn off SSL and verify if there are any issues when using HTTP. Another option is to use tools like STRACE (http://www.microsoft.com/downloads/en/details.aspx?familyid=f5ec767f-27f2-4fb3-90a5-4bf0d5f4810a&displaylang=en ) in combination and HTTPREPLAY (http://www.microsoft.com/downloads/en/details.aspx?familyid=d25ba362-c17b-4d80-a677-1faff862e629&displaylang=en) or different tools which allow you to look inside of the SSL Tunnel.
In summary - SSL Troubleshooting can be one of the most challenging things to troubleshoot. If something is going wrong inside the Tunnel, you have to find a way to look inside the tunnel. As SSL is designed in a way that this shouldn’t be possible, to prevent man in the middle attacks, you’ll most likely have to check the endpoints of the tunnel in most of the cases.
Author
Philipp Sand
Microsoft CSS Forefront Security Edge Team
Technical Reviewer
Thomas Detzner
Escalation Engineer - Microsoft CSS Forefront Security Edge Team