Sql-server – How to identify the source of the 17886 errors (“server will drop the connection”) in the SQL errorlog

For a better analysis please provide a network dump (wireshark) from the client. A typical problem with vpn is ip fragmentation. This would explain the established state in netstat and that it is working with another client (which might using smaller packets). But without trace it is just a wild guess.

I don't see it stated anywhere as to what version of the .NET Framework is being used, but given that this question was asked in May of 2014, and .NET Framework version 4.5 came out on 2012-08-15, the following note on SqlConnection.ConnectionString for the Asynchronous Processing / Async keyword seems relevant:

This property is ignored beginning in .NET Framework 4.5.

So, it might help to find out the exact version of Entity Framework being used, and the target version of the .NET Framework.

However, it kinda sounds like this issue might be a result of connection pooling. I suspect connection pooling because after the error message about the connection being closed, the session was still around.

The first thing to try is to simply disable connection pooling by adding the following to the connection string:

Pooling=false;

If the problem never comes back, then this was most likely the issue. I hesitate to say that this was the issue since it isn't exactly proof. It could have merely reduced the frequency from "once every few days" to once every few weeks or even months. But, if this does improve things, yet the app hits the server frequently and you would prefer to use connection pooling if at all possible, then you can try to reintroduce connection pooling, but in limited sense: you can set a low value for the Connection Lifetime keyword:

Connection Lifetime=2;

This will have connections close upon returning to the connection pool, if they are over 2 seconds old. This allows for a series of quick query executions to go through without each of them spending time establishing the connection, while at the same time not allowing the connection to linger out there, possibly holding locks, etc.

Even if the error still occurs, by not having connection pooling keeping the session and connection alive, that should allow for proper cleanup, releasing of locks, etc.

Just to have this stated since it was questioned in comments on the question: Multiple Active Result Sets (MARS) is used by Entity Framework to do Lazy Loading. So if the app has been developed to use Lazy Loading, then turning off MARS is not an option.