Dr. I Doctor

Dr. I Doctor's Informational Juggernaut

May 1, 2008

Windows Remote File Copy Timeout Errors

Dear Doctor,
Our remote offices' Windows servers nightly perform file copy operations from our central System i server for database synchronization. Recently, however, the file copy operations have begun randomly failing. Some nights they all work, but other nights one or more copies fail, with Windows giving the inexplicable error "timeout occurred." We have plenty of bandwidth, and other non-Windows copies running in parallel prove that network outages aren't occurring. Packet captures at each end reveal TCP RST (reset) packets being received that were not sent by the other end, which correlates with the timeout errors. What could be causing this?

Gentle User,
The mystery of random TCP resets is no mystery to those familiar with intrusion detection and prevention services. This behavior is the classic signature of a hacker filter attempting to prohibit what it sees as illicit traffic. That hacker filter is likely on a firewall at one end or the other of your communication link, but it could also be one employed by the ISP at either end as well.

Intrusion detection systems (IDS) and intrusion prevention systems (IPS) are mechanisms for detecting and blocking, respectively, hacker attempts to break into a network. The IDS process monitors all traffic, looking for patterns defined in an attack signature database. When the detection process gets a match, it may notify the IPS component to put a stop to the traffic. One method of forcing a stop is to send a TCP Reset to each side, shutting down the connection.

This process appears to be working perfectly in your case. The IDS identifies your legitimate file transfers as intrusion attempts, and the IPS component promptly shuts them down. Windows reports this as a timeout (although it should probably report it as unexpected termination).

The problem, of course, is that your file transfers are not intrusion attempts. Alas, one of the weaknesses of IDS is false positives — normal traffic erroneously identified as malicious. Fortunately, you can usually adjust IDS sensitivity to circumvent this problem. Check the logs of any intervening firewalls to see whether any IDS alarms are raised that identify the IP addresses involved in your file transfers. Then either white-list those IP addresses or reduce the sensitivity of the particular attack signatures being triggered.

If you don't have IDS/IPS enabled in any of your own firewalls, then look to the ISPs at either end. More and more ISPs are employing IDS on their edge networks in an effort to limit the affect of virus traffic. One ISP or the other may have its IDS screwed down a little too tight. If you can't get the ISPs to address the problem, then set up VPN tunnels between the locations. IDS by design will recognize and let pass IPSec VPN traffic.

Posted by mbeckman at May 1, 2008 4:27 PM

Dr. I Doctor
Blog Feed

June 2010
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

Blog Policy

We welcome your comments and opinions and encourage lively debate on the issues. However, Penton Media reserves the right to delete or move any content that it may determine, in its sole discretion, violates or may violate its Terms of Use or is otherwise unacceptable. For more information, see Penton Media's Terms of Use.

ProVIP Sponsors