Hi Kevin, Thanks for your help - I haven't had the chance to try any changes yet - but when I read your last email and saw UFQDN I thought - gosh that must be what I did wrong, because I remember setting it to FQDN.
Then I got your email this morning :( But I'll recheck everything based on your two emails. The good news is - I did get a Virtual Adapter to work properly - although through a different less secure manner. It solved the disconnect problems - so it was definitely relating to not having a Virtual Adapter and the MTU issues. Now if I can just get everything working as described, I'd have a bit more secure of a setup. Or perhaps I should consider some sort of certificate setup - but that seems even more complicated. Thanks again all. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of kevin vpn Sent: Wednesday, January 26, 2011 7:48 AM To: [email protected] Subject: Re: [vpn-help] ShrewSoft 2.1.7 and 2.2.0 Issue 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 <[email protected]> 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" <[email protected]> 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:[email protected]] > > Sent: Wednesday, January 12, 2011 4:27 PM > > To: Darren Nye > > Cc: [email protected] > > 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 > [email protected] > http://lists.shrew.net/mailman/listinfo/vpn-help > _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
