[vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue

[Darren Nye]

Hi Matthew & Kevin,

Thanks for all your help.

I went over and over the server and client settings outlined here, and all
are as described (though I'm on the latest firmware):
http://www.shrew.net/support/wiki/HowtoJuniperSsg

Unfortunately I'm getting a "negotiation timeout" so I must be doing
something wrong

It looks like it's getting hung up in Phase 1.

See attached.

50.50.50.50 was the changed IP representing our cable modem.

Hope you can help!


-----Original Message-----
From: Matthew Grooms [mailto:mgrooms at shrew.net] 
Sent: Wednesday, January 12, 2011 4:27 PM
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/12/2011 2:17 PM, Darren Nye wrote:
> Hi Matthew,
>
> Unfortunately installing your revised client alpha, didn't resolve the
> issues we're having.
>
> I'm not clear how to create a virtual adapter or what configuration
changes
> I would need to make on both the Jupiter SSG5 and Shrew Client side?
>

You would have to create a configuration like the one described in the 
SSG howto on our support site. Kevin gave some good information on how 
the client needs to be re-configured but the SSG configuration changes 
need to be made as well ...

http://www.shrew.net/support/wiki/HowtoJuniperSsg

I'm not sure why the consultant opted not to use a virtual adapter. It 
solves other problems besides MTU and packet fragmentation issues. For 
example, if two clients are handed the same DHCP IP address ( because 
they are behind different Firewall/NAT devices using the same DHCP scope 
), you will have problems with only one of the two working and the other 
mysteriously breaking. That's why non-consumer level VPN gateways have 
the option to assign private addresses to VPN clients.

That said, the client should also work ( barring IP address conflicts 
and bandwidth provider issues ) with the non-virtual adapter mode. Its 
just not clear to me what the problem may be at this point. I'm almost 
certain that it has something to do with MTU and packet fragmentation. 
Unfortunately, Microsoft IP stacks don't have a separate TCP Maximum 
Segment Size setting for adapters, only an MTU setting. You could try 
adding a MTU registry entry for your public interface adapter on one of 
the 'trouble' workstations ( use a value of 1380 ) to see if it helps.

http://support.microsoft.com/kb/314053

If you are unable to test other configurations, I'm not sure what else 
to suggest.

-Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iked.log
Type: application/octet-stream
Size: 5630 bytes
Desc: not available
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20110122/9d708f57/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump-ike-decrypt.cap
Type: application/octet-stream
Size: 1284 bytes
Desc: not available
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20110122/9d708f57/attachment-0005.obj>