On 10/10/2010 5:47 PM, Bernd Muschke wrote:
Hi Matthew, thanks for your suggestions. 1) There is no provider, all clients are located in the same office and the same subnet.
Ok.
2) All clients connect to the same firewall, a Juniper Netscreen 50 inside our office. Hardware Version: 4010(0), Firmware Version: 5.0.0r11.0 (Firewall+VPN). We use the VPN to secure the connection to our datacenter. Before switching to Win7 we used the Juniper VPN Client with Windows XP without the described problems.
I was referring to a SOHO router/firewall that would NAT between a home office network to a public IP address. If all your client computers are in a single managed location, then the problem is most likely local to the hosts that are experiencing the issue.
3) Not exactly. All clients are on common Dell desktops but different models. One of the "bad" network interfaces is a Broadcom NetXtreme 57xx for example.
This is where I would start then. Have you checked to see if all the "bad" network interfaces use the same chipset? Have you tried updating the network drivers on one of these hosts? Have you tried disabling the hardware assisted task offload features of the network card? Finally, I would try dropping an alternate network card into one of these machines and see if the problem goes away. If you narrow the problem down to a specific chipset driver issue, I can do more research.
4) Yes, most of our test were made with Winscp. Additionally we tried RDP with the same results.
Since TCP supplies flow control, I would guess that packet injection is the cause of your issue. If so, this is either a Shrew Soft VPN driver problem or a NIC driver problem. An extremely wild guess would be that something like TCP LSO is presenting a problem for the client. However, I have similar features enabled on my main development host ( Win7/64 with a Realtek Gigabit adapter ) and I don't see this problem.
Is there a specific debug level which will show us exactly what happens while a file transfer stops or loses packets?
You can dump both the public and private network traffic using the VPN Trace program and then have a look at the output using wireshark. I don't know that the information will be that telling since it difficult to see when a packet traversed the private interface but didn't make it out the public interface in its encapsulated form. Diagnosing this at a low level would require installing a debug version of the client on one of the trouble PCs and then inspecting the kernel level debug output. Unfortunately, debug output slows network operations considerably so it usually takes a dozen builds using a dozen variations of output before you actually see evidence of a problem. This is all based on the premise that it is related to a driver issue. The other steps mentioned above may seem low tech, but they are a really good place to start.
Hope this helps, -Matthew _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
