[vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue

[kevin vpn]

Hi Darren,

You are correct that it is getting hung up early on.  However, there is
not enough information in the iked.log file to know why.  What we can
see is that Shrew is not getting a response from the gateway.

Since the gateway will not respond to a peer that it does not
recognize, I think the problem may be there.  In the case of the howto,
it is expecting to be contacted by a client identifying itself as
'client.shrew.net'.

I would first double-check that on the gateway, you've got the IKE
User, Local Group and the Dialup User Group all setup correctly and
that in Shrew, you've got Local Identity setup so that they all match.
In Shrew, you should be using UFQDN and the UFQDN String should match
exactly the IKE Identity field in the user you created on the gateway.
Based on your iked.log, the gateway user's IKE Identity field should
contain 'client.jkdesign.com'.

If that is correct, the easiest way to troubleshoot this would be to
get the event log from the VPN gateway, it will have messages
explaining why it ignored the Phase1 request from Shrew.

Use the search function in the event log to look for your client's
public IP address.  The first message in the sequence should have
something like "begin aggressive negotiation".

If nothing shows up in the event log, then I would look to see if port
500 is allowed in from the Internet to the VPN gateway IP address.  It
could be the request is being silently dropped by a deny policy.


On Sat, 22 Jan 2011 00:09:16 -0500
"Darren Nye" <darrenn at jkdesign.com> wrote:

> 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