[vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue

[kevin vpn]

Hi Darren,

I realize that I told you the wrong setting in my previous mail.
Since you're using the identifier 'client.jkdesign.com', you should be
using Fully Qualified Domain Name and FQDN String, not UFQDN.


On Tue, 25 Jan 2011 23:24:21 -0500
kevin vpn <klmlk at hotmail.com> wrote:

> 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
> 
> _______________________________________________
> vpn-help mailing list
> vpn-help at lists.shrew.net
> http://lists.shrew.net/mailman/listinfo/vpn-help
>