[vpn-help] VPN not passing traffic using Shrew Client

[kevin shrew-vpn]

On Sun, 09 May 2010 12:14:03 -0400
mikelupo at aol.com 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
VPN configuration.  If it is set to "Obtain Topology Automatically or
Tunnel All" and the NetGear is not providing the network details, you
may run into the tunnel traffic to gateway problem fixed in 2.1.6.
Hopefully your testing with the 2.1.6 beta will eliminate this.

The next thing you might be running into is a NAT-traversal problem.
There could be some additional NATting going on.  Do you know if the
NetGear is NAT-T capable (or has it enabled)?

If you want to provide some useful information, try providing a debug
log.  Open the Shrew Trace Utility.  Go File->Options and change the
"Log output level" from none to informational or debug. Make note of
the IKE log file location, then click OK.  Use the restart button on the
IKE, DNS and IPSEC service tabs.  Then connect the VPN, try some
traffic, then disconnect.  Stop the IKE service and upload the iked.log
file.

Something to watch on the trace utility when you're connected are the
Security Policies and the Security Associations tabs. On the SP tab,
when you're connected there should be at least two IPSEC policies (one
in each direction) and one rule that is not IPSEC that covers the VPN
gateway public IP.  There should be two associations on the SA tab
(also one for each direction).