On 1/7/2011 1:11 PM, Darren Nye wrote:
Hi all,
Hi Darren,
VPN Client: ShrewSoft 2.1.7 and 2.2 Alpha 9. Windows: 7 64bit and Vista 64bit Gateway: Juniper SSG5 Gateway Hardware Version: 710(0) Gateway Firmware Version: 6.3.0r5.0 (also tried firmware 6.0 with same issue). Five people in different locations, have been able to duplicate this problem, with the ShrewSoft 2.1.7 and 2.2 Alpha 9 clients. However when we use NCP Client or Green Bow VPN Client, we do not have this issue and everything seems fine. So this points to either a configuration issue with ShrewSoft or a bug. I hope someone can help?
Are you absolutely sure that this problem can be resolved by installing the NCP or Greenbow clients? I'm not to proud to admit when the Shrew Soft client has a bug that needs to be fixed. From looking at your log output, it would appear that you are not using virtual adapter configs which can cause problems related to MTU issues. Some carriers will drop packet fragments or large UDP packets for no good reason. When using a virtual adapter, a custom MTU can be set to avoid these issues.
We can connect to the Juniper with ShrewSoft and also connect to our network file servers, and perform short tasks such as copy small files up/down or use remote desktop. However, when we try to use Windows Explorer to connect to a Linux/Samba (v3.1) file server (ie: \\192.168.66.1\printfileserver <file:///\\192.168.66.1\printfileserver>) and copy a folder with a large number of files (100mb or more) – by dragging and dropping from the server to the desktop – it seems that Windows thinks the connection to the server is lost – although the tunnel itself in ShrewSoft doesn’t show that it disconnected. But the log file seem to show a “halt” command around the same time the issue is probably happening.
The halt should only show up in the log when someone stops the service. It's the normal shutdown procedure. I see the halt in your logs about four minutes into the connection. Is that a user stopping the service or do you mean that its stopping itself?
See attached: Windows-preparing-copy.jpg = the beginning of the file copy – things going normal so far Windows-copy-start.jpg = after windows is finished preparing (I believe figuring out how much and what it’s going to copy) – it then tries to start the copy – but never seems to start Windows-failure.jpg = a short time after the windows-copy-start above, windows will display a failure. It’s at this point that shrewsoft perhaps is getting the halt. The Shrew trace and other log/dump files are attached. 1.1.1.1 is a changed IP address but represents our internal IP address of the Juniper router. These particular logs were when connecting via ATT and my cell phone. However we’ve had these issues remotely from homes on Comcast and Optimum cable modems. I’ve been told by our Juniper tech rep that our internal servers are sending a RST (reset) although I don’t see that in any of the logs I’m looking at. But we don’t experience these odd issues when using the NCP client or Green Bow. But I’d rather not license every single one of our users. Any suggestions, please let me know.
There is a feature included in modern network adapters called TCP Large Segment Offload. Up until the last 2.2.0 alpha release, the client had a bug that caused problems similar to the one you describe when TCP LSO was enable and virtual adapters were not in use. The Alpha 9 version of the client that you tested with does not have the fix for this bug. Not that I can imagine TCP LSO would be implemented by an AT&T cell phone dongle driver, but it could certainly be effecting your home users. If you want to try a version of the client that has been tested a bit more than the latest alpha, you can have a user try this version ...
http://www.shrew.net/download/vpn/vpn-client-2.2.0-lsofix-1.exe -Matthew _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
