[vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue

[Darren Nye]

Hi Matthew,

I'm absolutely sure that using NCP and Green Bow, resolves the issues.

I'm not sure how to setup a Virtual Adapter - everything was setup by the
consultant we hired. Are there instructions somewhere of how to try a
virtual adapter?

I don't know if it matters but the consultant was able to get the free IP
Securitas to work fine also - which runs on Macs (half of our clients are
Macs).

I did try stepping through the alternate configuration found here:
http://www.shrew.net/support/wiki/HowtoJuniperSsg

But I couldn't get a tunnel connection at all with the above. Maybe it's
because some of the SSG pages were a bit different, with the updated
firmware. And one field, IKE ID Type, was not sticking on AUTO but was being
changed to something starting with an F (not currently connected to router).

To answer your other question, the user is not stopping the service. As per
the pictures what is happening, is I start copying using Windows Explorer
from the server to my notebook, and the copy stops and produces the Windows
error as per the pics - and it seems the halt happens at that time. But the
user never touches the servers from a technical standpoint.

I will try your latest alpha version and report back:
http://www.shrew.net/download/vpn/vpn-client-2.2.0-lsofix-1.exe



-----Original Message-----
From: Matthew Grooms [mailto:mgrooms at shrew.net] 
Sent: Wednesday, January 12, 2011 2:21 AM
To: Darren Nye
Cc: vpn-help at lists.shrew.net
Subject: Re: [vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue

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