TMG 2010 is logging an error "Failed Connection Attempt" Status: 64 The specified network name is no longer available" in Live Logging

TMG 2010 is logging an error "Failed Connection Attempt" Status: 64 The specified network name is no longer available" in Live Logging

  • Comments 1
  • Likes

Problem

I recently had a case where a customer was very alarmed by some of the errors being logged in Forefront Threat Management Gateway 2010 (TMG). The customer was using a web publishing rule so external Outlook Anywhere clients could connect to their internal Exchange CAS Server. The customer had recently experienced some issues and wanted to be proactive. The error that was being logged by TMG was "Failed Connection Attempt" Status: 64 The specified network name is no longer available"

I asked the customer if their Outlook Anywhere users were reporting any issues or outages. They weren’t but he still had some concerns so I gathered data on the issue.

Data Analysis

IP addresses in the traces

10.1.5.11 CAS Server

10.1.4.98 Internal IP address of TMG

We used Network Monitor to gather the network traces and I matched the errors that were being logged up to specific packets in the trace. The way the conversation between TMG and the CAS server ended is shown below and is where I focused my attention:

1348 11:34:15.5026040 10.5716040  10.1.5.11 10.1.4.98 TCP TCP:Flags=...A...F, SrcPort=HTTPS(443), DstPort=31024, PayloadLen=0, Seq=1162679467, Ack=3797497206, Win=7457 (scale factor 0x0) = 7457 {TCP:203, IPv4:1}

1349 11:34:15.5026040 10.5716040  10.1.4.98 10.1.5.11 TCP TCP: [Bad CheckSum]Flags=...A...., SrcPort=31024, DstPort=HTTPS(443), PayloadLen=0, Seq=3797497206, Ack=1162679468, Win=64033 (scale factor 0x0) = 64033 {TCP:203, IPv4:1}

1410 11:34:15.8416240 10.9106240  10.1.4.98 10.1.5.11 TCP TCP: [Bad CheckSum]Flags=...A.R.., SrcPort=31024, DstPort=HTTPS(443), PayloadLen=0, Seq=3797497206, Ack=1162679468, Win=0 (scale factor 0x0) = 0 {TCP:203, IPv4:1}

I had to dig a little deeper so I looked at the application level tracing for TMG.  This is an internal tracing process so it wouldn’t be available to our customers by default but here is a look into what I saw.  This specific area of the TMG trace jumped out at me.  (It referenced the same time frame we see in the Netmon data above):

 (185.x.x.x:64207 ==> 200.x.x.x:443)   (10.x.x.x:31024 --- 10.x.x.x:443), 0 bytes, "<NULL>", 64(ERROR_NETNAME_DELETED)

(ERROR_NETNAME_DELETED) was my focus.  This error corresponds to what TMG was logging which was "Failed Connection Attempt" Status: 64 The specified network name is no longer available."

Conclusion

The error and the reset are not only okay but they are by design.  The “Error 64” is being logged in response to ERROR_NETNAME_DELETED when TMG resets the connection to the CAS server rather than doing a "graceful close." Networking professionals will sometimes refer to this as a “dirty close.” This method is perfectly acceptable and saves resources on both the TMG Server and the network. It will do this for the following reasons:

1.)    Minimizes traffic and time on the wire and time because rather than TMG doing a graceful close by sending a FIN, ACK and waiting for CAS server to ACK this, TMG just sends an RST. One less packet on the wire. Doesn’t sound like a lot but multiply that by thousands or tens of thousands and it adds up to a lot.

2.)    More efficient for resources. If TMG did a “graceful close” (explained in detail in the TCP Connection States document below) the socket would go into a TIME_WAIT state.  It would have to wait the default time, which is 2x the MSL, before releasing that socket to be able to be reused.  2x the MSL is 4 minutes by default.  (See resources below for more info on Time Wait states and Resets)

As a rule firewalls are pretty busy devices since they are inspecting everything that comes in and out of your network. Firewalls such as ISA and TMG often have thousands of connections being made through them at any given time. Imagine if all of these connections had to wait the default 4 minutes before being reused. It is pretty easy to see how this could lead to a rapid depletion of available resources and bring the firewall to its knees.

Resources

TCP Connection States and Netstat Output

http://support.microsoft.com/kb/137984

TcpTimedWaitDelay

http://technet.microsoft.com/en-us/library/cc938217.aspx

Where do resets come from? (No, the stork does not bring them.)

http://blogs.technet.com/b/networking/archive/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them.aspx

Author

Keith Abluton

Sr. Support Engineer

Microsoft EPS Forefront Security Edge Team

Technical Reviewer and Contributor

Brett Crane

Support Escalation Engineer

Microsoft EPS Forefront Security Edge Team

Comments
  • We are having a similar problem, but it is causing serious problems for users external to the firewall.  The only error logged (that we can find) is "64 The specified network name is no longer available."

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment