[vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue

[Paul Papasavas]

Matthew,

FYI the issue was resolved simply by using a virtual adapter and assigning
am MTU of I believe 1380 ... All problems went away with Shrew / ssg5

Paul


On 1/12/11 8:13 AM, "Darren Nye" <darrenn at jkdesign.com> wrote:

>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
>