To Mike W's mail which has not yet hit my inbox but is up on the VPN-HELP list... Mike, Yup, I'm already using Xauth with modeconfig. The major problem was that I was using the 192.168.1.x subnet in the assigned IP address pool for Mode Config. Changed it to 192.168.2.x as you suggested and now I"m able to ping ....but somewhat unreliably. For example, one time I ping 192.168.1.1 and the ping request come back with 4 positive hits. Try it again and this time I get a response from the WAN address saying "Destination host unreachable". So one step forward to peel away at what appear to be a few problems.... Thanks, Mike MIke W wrote... ------------------------------------------------------------------------------------------------------------------------ If You use NetGear with ModeConfig you must use XAUTH because NetGear has bug in their products (only NetScreen works OK on configuration with modeconfig and xauth disabled) Next basic thing is that ModeConfig IP pull must be different of LAN and WAN so You can't use the same subment 192.168.1.x Change mode-config adresses to 192.168.2.x and it will be fine (NetGear has default routing so You don't need to change anything on clients computers) Regards, Michal Wegrzyn ------------------------------------------------------------------------------------------------------------------------ -----Original Message----- From: kevin shrew-vpn <[email protected]> To: [email protected] Sent: Sun, May 9, 2010 1:14 pm Subject: Re: [vpn-help] VPN not passing traffic using Shrew Client On Sun, 09 May 2010 12:14:03 -0400 [email protected] wrote: > 1) I do not have overlapping local LAN IP address ranges. In fact, my local LAN address is 10.0.0.x and the remote lan address (behind the VPN router) is in the 192.168.1.175 -to-192.168.1.195 range. So no problem there. So listed: 192.168.1.1 is the VPN's local network gateway address. 192.168.1.175 thru 195 is the DHCP address range as set up in the Netgear mode-config for VPN clients connecting. 255.255.255.0 is the network mask used by VPN and client so that they match on both ends. The WAN address is NOT static unfortunately as Comcast refused the business owner. As a workaround, we're using dyndns.org. 2) I will uninstall 2.1.5 in favor of the 2.1.6 beta and see if this helps. Is there any log file or any other source of information that I could post that would perhaps give greater visibilty into the issue? Hi Mike, the next thing I would look at is the Policy defined in the PN configuration. If it is set to "Obtain Topology Automatically or unnel All" and the NetGear is not providing the network details, you ay run into the tunnel traffic to gateway problem fixed in 2.1.6. opefully your testing with the 2.1.6 beta will eliminate this. The next thing you might be running into is a NAT-traversal problem. here could be some additional NATting going on. Do you know if the etGear is NAT-T capable (or has it enabled)? If you want to provide some useful information, try providing a debug og. Open the Shrew Trace Utility. Go File->Options and change the Log output level" from none to informational or debug. Make note of he IKE log file location, then click OK. Use the restart button on the KE, DNS and IPSEC service tabs. Then connect the VPN, try some raffic, then disconnect. Stop the IKE service and upload the iked.log ile. Something to watch on the trace utility when you're connected are the ecurity Policies and the Security Associations tabs. On the SP tab, hen you're connected there should be at least two IPSEC policies (one n each direction) and one rule that is not IPSEC that covers the VPN ateway public IP. There should be two associations on the SA tab also one for each direction). ______________________________________________ pn-help mailing list [email protected] ttp://lists.shrew.net/mailman/listinfo/vpn-help
_______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
