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


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 CAS Server 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 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 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 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."


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.


TCP Connection States and Netstat Output


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


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 (4)

  1. glen says:

    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."

  2. Eric says:

    TMG must be able to resolve the published URL AND the certificate’s FQDN (both should be the same) to the internal server (via the same URL -> FQDN). I used HOSTS file entries on TMG to correctly resolve the internal server.

  3. Jorge says:


    I got the 64 error with OWA, and in my case was due to the Microsoft Exchange Form-Base Authentication service was down. Once I started up, users could access to OWA. In the other hand, MS Exchange Protected Service Host was down and I started up as well, but OWA was running when i started the Form-base authentication service. Anyways I think that all MS Exchange services configured on automatic start must be online because they are depending each other one or another way.

    I hope this help

    Best regards

    1. Asanda says:

      I’m having a similar problem, however it’s a forwarding proxy and users can access other websites other than google.

      Thanks in advance.

Skip to main content