Endpoint Protection

OK, so I have been troubleshooting this issue with Microsoft for over a month now, and today, I finally figured out what is causing it, but how to permanently fix it. Here's the scenario:

I am running Windows Vista x86 with SP1 and all patches installed. My hardware consists of a Core 2 Duo CPU, and a GIG Intel NIC.

When I RDP to a Server, running Windows Server 2008, I will stay connected for about 10 seconds to 5 minutes, (It is random) and then get a error box saying, "Because of an error in data encryption, this session will end. Please try connecting to the remote computer again "  I have also been getting this same error RDP'ing to a SBS 2003 server as well. I as well as Microsoft pointed the finger at the Firewall, in which I swapped that out and then the Firewall company (Sonicwall in this case) pointed to the ISP. The ISP on the other hand, looked at it and said, nope it's not us.

So after all of this finger pointing, I RDP'ed into the same Windows 2008 server from a XP workstation, with no SEP installed.... I stayed connected for hours, no problems. I came across this article http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/3e4e9d8a-cf6a-4e7a-9072-f9ecd3f17a72 today indicating something to do with TCP Offloading, but in my case, it was not the fix. 

What did fix it for me, until Symantec can tell me the permanent solution:

Start, Run, type in smc -stop (this stops SEP service on the client)

Now I RDP to the Windows 2008 server or Windows 2003 server, and no problem.

Is it the Teefer2 driver or something else?

Hopefully Symantec has an answer.

Lyle Epstein

Windows SNP (enabled in 2003 SP2 + 2008 for supported drivers, Broadcom being the worst offender) causes lots of network issues especially for Vista clients (RSS).

I know you mentioned this a little, but make sure the server is on the latest NIC driver from your server manufacturer, as well as disabling TCP Offload, Tx/Rx offload, RSS.

This article is a little old, but still applies:
http://support.microsoft.com/kb/948496


I have done alot of SEP deployments and have never seen what you are describing, but that doesnt mean there isnt something about your environment that is different and causing this.

Check your firewall and IPS logs for any events around the time the connection drops.

Have you installed NTP component on the server? Can you allow RDP port 3389? or Try to install sep without NTP.

Worth checking the event viewer at the time when the session disconnects with an error...

What version of SEP are you running?
In a case very similar to yours, uninstalling Network Threat Protection, Proactive Threat Protection and email scanning tools allowed a successful, stable connection to be established. That customer was using MR2 MP1.

If you are on an older build you should upgrade to MR4 then up to MR4 MP1a.

Thomas

I am on SEP 11, MR4 MP1. On the server, SEP is NOT installed. It is running one role, Hyper-V.  It is on the latest drivers from Intel, and I have attempted turning off Offloading, RSS, and pretty much every other setting. I have troubleshooted this with Microsoft for over two weeks, them being as puzzled as me.  Since this issue seems to only occur via Vista SP1 with SEP installed  to Windows 2003 & Windows 2008 with NO SEP on it, it would appear that this issue is related to the SEP client, not the server.

There are no logs in the event viewer to look at, as it doesn't show anything.  On the client machine, SEP is installed with Anti-Virus, Proactive Threat Protection and Network Threat Protection. I suppose the next thing is to diable one by one to see which is causing the exact issue.

So I disabled each piece, one by one, First Network Threat Protection, tried RDPing, got the error. Then left that off, and turned off Proactive Threat Protection, tried RDPing, same thing. Then left that off as well, and turned off AntiVirus and AntiSpyware Protection, tried RDPing, same thing. Then I did a smc -stop, tried it, and it worked like a charm..... so if all of it is off, and that doesn't work, why  is stopping the service the fix?

Hi can you try a clean reinstall? and just use AV and AS only?

Brand new terminal server, was working great and since i installed this 64bit SEP, I am getting the error.

This has actually nothing to do with SEP. It's an issue with the OS and the Send Large TCP Offload setting for the NIC.

There is a verified symantec KB to that effect. Maybe Kedar will be able to find it.

Here is the Link to the KB - service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1313595252a6e4ed6525753f002bb332

I agree with Abhishek that this is not an SEP issue. I just happen to be searching for solutions and found this page. I thought it would be good to post my solution if it might help anyone.

I was having this same exact problem and couldn't find where to disable the large send offload even though (I thought) I had the latest drivers for my NIC (Intel 82566DC-2). I am running Vista Ultimate (32-bit) on a computer with this Intel NIC. Using RDP to connect to it from any computer failed with the encryption error that we all know and love. Apparently, windows thinks I have the latest drivers for the device and so I am stuck with the limited capabilities of the driver it is currently using. I finally decided to go to the Intel site and see if they had anything more up to date. They did! After loading this new driver, I now have the option to disable the Large Send Offload for both IPv4 and IPv6. Not sure if I needed to disable both, but I did and so far I haven't received the data encryption error. So, I would highly recommend going to the vendor's site to get the latest drivers for your NIC and see if that works. My computer is a Dell XPS (I forget the model number) and the dell site didn't have updated drivers either.

Hope this helps.

-Ben

Excellent suggestion Ben !!!!!

I'd recommend that you add a comment to the Symantec KB I've given above and ask the KB team to update the steps with your suggestion !!!!!

I am not sure what to make of it though. I was having the same issue on a 2nd server. Same configuration as above (Dell PowerEdge 2950 with NetXtreme II NIC with windows server 2008 and remoteapp and remote desktop enabled.) and as soon as i installed SEP 64 bit - i ran into the trouble. I then uninstalled it and sure enough it started to work.

But I am glad all problem relates to Large Send Offload. I am using IPv4 on both machines. And whether it is for SEP 64bit or not, turning off LSO seems to do the trick.

Hi there everyone, since I posted my last commend, I was looking arround and I think I have found a solution on one of the sites. Unfortunately I can't remember which site it was exactly but it was from TechNet's article.

Anyways, my situation: I am using Dell PowerEdge 2950 with NetXtreme II NIC with windows server 2008 and remoteapp and remote desktop enabled. After installing SEP it was giving me the error.

The information I found says that it is to do with Large Send Offload option on NetXtreme II NIC. You can just disable this option by selecting IPv4 and then selecting Large Offload option from the configuration. I am not sure yet how to post a picture on here or screenshots so once I figure that out I will try to put that on here.

If you want you can contact me directly as well. Good luck.

If you look at the first reply, the solution was posted 2 weeks ago.

@ Lyle Epstein: Is this resolved ?

The solution above seems to resolve it, although I have not specifically tried it. In my specific case, I was RDPing to a SBS 2008 server that was running in a Hyper-V VM, so the NIC drivers are being serviced by the Microsoft Hyper-V driver, not the Intel NIC. On the host OS, the NIC is a Intel Nic. My solution I performed and still perform as this happens when I connect to Windows 2003 servers as well, is to execute the command smc -stop on my Windows Vista x86 box before I RDP in. This seems to work well for me. I am switching to Windows 7 x64 this week, so I will see how it works on that, although I am not planning on installing SEP till it is fully supported for Win 7 x64.

Lyle Epstein
http://blog.korteksolutions.com

Solution is here:

Microsoft gots the bugs....

http://support.microsoft.com/?kbid=323497