[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