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" <[email protected]> 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:[email protected]] >Sent: Wednesday, January 12, 2011 2:21 AM >To: Darren Nye >Cc: [email protected] >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 > _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
