Sdílet prostřednictvím

Expect the unexpected… Failed Connection 995 and 64 with SSL Traffic

  • Článek

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.

995 error in ISA logging

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

Comments

  • Anonymous
    October 01, 2010
    One the issues you may have tracking down this issue and following the packet through a web proxy chain is that the your ISA/TMG server upstream web proxy server will “anonymise” the packet and always put the upstream proxy IP address as the Client address. This happens because there is no RFC standard for tracking the originating client IP address in HTTP/(s) headers although most other proxies use the X-Forwarded-For header. If you want to track this value on ISA/TMG servers, Winfrasoft have an XFF product for Forefront that allows you to track the route a packet follows from source to dest. This should help you with isolating the issue and is also useful for other auditing requirements.  Good luck!