[Vpn-help] Netgear DG834G

[shrew.nelipot at spamgourmet.com]

Hi Stefan,

Thanks for your input.  Yes, I've tried what you suggested.

Here is an extract from my DG834G log file:-

Thu, 2009-04-30 11:47:05 - [MiniEee] responding to Main Mode from unknown
peer 58.8.195.60
Thu, 2009-04-30 11:47:06 - [MiniEee] *no suitable connection for peer
'192.168.1.4'*
Thu, 2009-04-30 11:47:06 - [MiniEee] sending encrypted notification
INVALID_ID_INFORMATION to <invalid>:0
Thu, 2009-04-30 11:47:16 - [MiniEee] STATE_MAIN_R2: retransmission; will
wait 20s for response
Thu, 2009-04-30 11:47:16 - [MiniEee] *no suitable connection for peer
'192.168.1.4'*
Thu, 2009-04-30 11:47:16 - [MiniEee] sending encrypted notification
INVALID_ID_INFORMATION to <invalid>:0
Thu, 2009-04-30 11:47:26 - [MiniEee] *no suitable connection for peer
'192.168.1.4'*
Thu, 2009-04-30 11:47:26 - [MiniEee] sending encrypted notification
INVALID_ID_INFORMATION to <invalid>:0
Thu, 2009-04-30 11:47:36 - [MiniEee] sending notification PAYLOAD_MALFORMED
to <invalid>:0
Thu, 2009-04-30 11:47:36 - [MiniEee] STATE_MAIN_R2: retransmission; will
wait 40s for response
Thu, 2009-04-30 11:48:16 - [MiniEee] max number of retransmissions (4861828)
reached

I've underlined the point at which I believe the negotiation fails.

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 Data field to see if
that would work, but this has not met with success.

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 Data field 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:

Thu, 2009-04-30 12:36:22 - [MiniEee] responding to Main Mode from unknown
peer 58.8.195.60
Thu, 2009-04-30 12:36:22 - [MiniEee] sent MR3, ISAKMP SA established
Thu, 2009-04-30 12:36:22 - [MiniEee] Dead Peer Detection (RFC 3706): enabled
Thu, 2009-04-30 12:40:33 - [MiniEee] received Delete SA payload: deleting
ISAKMP State #3


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.

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?

Anyone have any thoughts as to how to overcome this issue?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20090430/b0211554/attachment-0002.html>