Symantec Endpoint Protection appears to cause networking problems with NICs using a TCP Offload Engine
Last Updated January 09, 2008
Symantec Endpoint Protection (SEP) appears to cause networking problems with NICs using a TCP Offload Engine (TOE). TOE is a technology in some NICs that allows all processing of the TCP/IP stack in NIC hardware rather than by the operating system. This feature may be evident by advanced NIC settings in the device manager that mention "Offload".
Symptoms Slow/broken connections, Remote Desktop connection failures, other symptoms. See Microsoft article below for a list of issues:
NOTE: The Microsoft article mentions only Windows 2003 SP2, but these symptoms may be seen in other Windows versions (Windows XP, Server 2008, Vista) after installing SEP. Symptoms may also be observed in virtual machines.
Offload problems that are caused by Symantec Endpoint Protection are fixed in SEP 11 RU5 and newer.
As a work-around, disable TCP Offload functions by following a combination of the instructions below.
Windows Vista, Server 2008, and Windows 7
From command line:
netsh int tcp set global chimney=disabled
To verify setting, from command line:
netsh int tcp show global
Windows Server 2003 and Windows XP x64
From command line:
netsh int ip set chimney enabled
To verify setting, query the following registry value:
Create/set the following registry value:
To ensure the new configuration is active, disable/enabled the network connection or reboot.
NOTE: Some NIC drivers or management software may automatically re-enable these settings. In this case, disable any advanced NIC setting that mentions "Offload", then disable/enable connection or reboot. These settings may be found under the Advanced tab of the NIC Adapter Properties in the Device Manager.
References Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008
When this option is enabled, all packets with bad checksums are displayed (by default) with red lettering on black background. A Wireshark indication of bad checksums doesn't necessarily mean the checksums are bad—a LOT of checksum errors likely means that TCP offloading is enabled and the NIC performed checksum calculations for the packets *after* they went through Wireshark.
In any case, TCP offloading may be part of various networking problems, sometimes only in combination with SEP. So, next step is to disable TCP offloading between the two networking points and re-test. Perform another capture if symptoms still occur.
If many bad checksums still appear, you haven't successfully disabled offloading--or something is truly wrong with the networking hardware.
Imported Document ID: TECH105646
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe