[vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue
mgrooms at shrew.net
Wed Jan 12 01:21:10 CST 2011
On 1/7/2011 1:11 PM, Darren Nye wrote:
> Hi all,
> 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
> 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. 188.8.131.52 is a
> changed IP address but represents our internal IP address of the Juniper
> 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 ...
More information about the vpn-help