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
iked.log
Description: Binary data
dump-ike-decrypt.cap
Description: Binary data
_______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
