Hi
Bernd,
These are always the most difficult type of problem to trouble
shoot. The VPN connection can be established, but a subset of the
clients experience problems for one reason or another. The key to
diagnosing the issue is identifying what the troublesome clients
have in common and how they differ from the clients that are
working well. I'm not sure how much control you have over the
network environment that the client is connecting from, but that
can certainly have an impact on connectivity. You say you have
checks switches and cables, but I'm not sure if that means the
clients are in a remote office network that you manage, or if they
are connecting from home over a public network.
Here are some things to investigate ...
1) Are all the troublesome clients using the same internet
provider? Its possible that one network provider is shaping
traffic in a way that causes problems for the VPN client. Other
times, an internet provider will handle UDP packets ( IPsec NAT-T
) strangely. You can try dropping the MTU on the virtual adapter
to see if this resolves your issue. You can also try disabling
NAT-T support on the VPN client to see if that has an effect. The
drawback to this is that multiple clients behind a single firewall
won't work properly without NAT-T enabled. Ultimately, the best
way to rule out provider problems is to re-locate a troubled
machine into the same source network as a working machine.
2) Are all the troublesome clients using a particular brand of
SOHO router/firewall? VPN client traffic is sometimes handled
incorrectly by the vendor firmware. This can often be resolved by
updating to a newer firmware release version. You can also check
to see if VPN pass-through features are enabled on the SOHO
router/firewall. Sometimes these can cause problems with modern
VPN clients.
3) Are all the troublesome clients using the same make/model of
network interface? It could be that the VPN client isn't working
well with a particular vendors network kernel driver for some
reason. In this case,
try looking for an updated driver version and see if that helps.
You can also try adding a different make/model network card to
test and see if this resolves the issue. If so, please let me know
which make/model of hardware is giving you trouble.
4) Are the working / troublesome clients using the same types of
IP protocols inside the tunnel. For example, SMB/CIFS uses UDP
where remote desktop sessions use TCP. You could test this by
transferring a file using a samba or windows network file share vs
transferring the same file using http, sftp or ftp. I don't have
any good suggestions for fixing this off the top of my head, but
its a good data point for further investigation.
Hope this helps,
-Matthew
Hi Matthew,
thanks for your suggestions.
1) There is no provider, all clients are located in the same office
and the same subnet.
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.
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.
4) Yes, most of our test were made with Winscp. Additionally we
tried RDP with the same results.
Is there a specific debug level which will show us exactly what
happens while a file transfer stops or loses packets?
Thanks,
Bernd
|
_______________________________________________
vpn-help mailing list
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help
