[vpn-help] Windows 7 32bit poor performance and timeouts

Matthew Grooms mgrooms at shrew.net
Sun Oct 10 19:16:51 CDT 2010


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



More information about the vpn-help mailing list