Hi Stefan,<br><br>Thanks for your input.  Yes, I've tried what you suggested.  <br><br>Here is an extract from my DG834G log file:-<br>
<br>
Thu, 2009-04-30 11:47:05 - [MiniEee] responding to Main Mode from unknown peer 58.8.195.60<br>
Thu, 2009-04-30 11:47:06 - [MiniEee] <u><b>no suitable connection for peer '192.168.1.4'</b></u><br>
Thu, 2009-04-30 11:47:06 - [MiniEee] sending encrypted notification INVALID_ID_INFORMATION to <invalid>:0<br>
Thu, 2009-04-30 11:47:16 - [MiniEee] STATE_MAIN_R2: retransmission; will wait 20s for response<br>
Thu, 2009-04-30 11:47:16 - [MiniEee] <u><b>no suitable connection for peer '192.168.1.4'</b></u><br>
Thu, 2009-04-30 11:47:16 - [MiniEee] sending encrypted notification INVALID_ID_INFORMATION to <invalid>:0<br>
Thu, 2009-04-30 11:47:26 - [MiniEee] <u><b>no suitable connection for peer '192.168.1.4'</b></u><br>
Thu, 2009-04-30 11:47:26 - [MiniEee] sending encrypted notification INVALID_ID_INFORMATION to <invalid>:0<br>
Thu, 2009-04-30 11:47:36 - [MiniEee] sending notification PAYLOAD_MALFORMED to <invalid>:0<br>
Thu, 2009-04-30 11:47:36 - [MiniEee] STATE_MAIN_R2: retransmission; will wait 40s for response<br>
Thu, 2009-04-30 11:48:16 - [MiniEee] max number of retransmissions (4861828) reached<br>
<br>
I've underlined the point at which I believe the negotiation fails.<br>
<br>
It appears that the DG834G won't accept the 'Remote Identity Type'. I've attempted to connect with the Remote Identity Type set to both 'IP
Address' (as was the case when the above log was created) and 'Fully
Qualified User Name' and specifying the Internal IP address in the <font color="Red">Data field</font> to see if that would work, but this has not met with success.<br>
<br>
On the client side (Shrew Soft VPNClient Ver 2.1.0), I have used the IP
Address Identification Type in conjunction with both the 'Use
discovered local host address' checked and unchecked. When unchecked I
have entered an address string and duplicated that in the the <font color="Red">Data field</font>
of the DG834G. When I do that the DG834G log shows the same error
except that instead of "no suitable connection for peer '192.168.1.4'"
it says "no suitable connection for peer '255.255.255.255'".  I note that in the help file of the DG834G it states that if the 'Remote Identity Type' is set to 'IP address' it means 'IP Address - The Internet IP address of the remote VPN endpoint.', which the Shrew Client is clearly not using (it is instead using the internal IP address).  I tricked the DG834G into thinking that Shrew was sending its Routable IP address by unchecking the 'Use discovered local host address'  field under Authentication - Local identity in Shrew and entering the External (routable) IP address of the client.  Then I get the following log entries in the DG834G log file:<br>
<br>Thu, 2009-04-30 12:36:22 - [MiniEee] responding to Main Mode from unknown peer 58.8.195.60<br>Thu, 2009-04-30 12:36:22 - [MiniEee] sent MR3, ISAKMP SA established<br>Thu, 2009-04-30 12:36:22 - [MiniEee] Dead Peer Detection (RFC 3706): enabled<br>
Thu, 2009-04-30 12:40:33 - [MiniEee] received Delete SA payload: deleting ISAKMP State #3<br><br><br>The Shrew Client reports 'gateway is not responding' at the point that 'received Delete SA payload: deleting ISAKMP State #3' is entered in the DG834G log and the connection gets dropped. <br>

<br>Obviously, even if I had managed to get the VPN to work using the above workaround it wouldn't be practical on an on-going basis.  In the Shrew Client under the Local identity tab of the Authentication Tab in the Identification Type drop down box there is only one option, which is IP Address (which clearly means internal/non-rotable IP address).  Other than that I can either check or uncheck the 'Use discovered local host address' field, as stated above.  If I uncheck this field I can then enter data in the 'Address String' box.  I've tried doing that with various combinations of data and duplicating this setting in the Netgear DG834G, but the DG834G still reports a similar error except that instead of the internal IP address it shows the address 255.255.255.255 as stated above.  The only one that worked to get passed this error is the solution shown above.  It seems to me that I need other options under this tab.  Perhaps I need to report this as a bug?<br>
<br>
Anyone have any thoughts as to how to overcome this issue?<br>