VPN with Netgear FVS338 fails

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

I want to establish a VPN connection from a client (Windows XP SP2,
Netgear ProSafe VPN Client Software) over the internet to a Netgear
FVS338 ProSafe VPN Firewall. After two days of trying, I'm starting to
get mad. The process fails after initiating IKE Phase 2.

This is the log from the Netgear ProSafe VPN Client (leading date/time
information was deleted for better reading):

Attempting to resolve Hostname (xxx.dyndns.org)
Initiating IKE Phase 1 (Hostname=xxx.dyndns.org) (IP
ADDR=xxx.xxx.xxx.xxx)
SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID 6x)
RECEIVED<<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, NAT-D 2x, VID
2x)
Peer is NAT-T draft-02 capable
NAT is detected for Client
Floating to IKE non-500 port
Peer supports Dead Peer Detection Version 1.0
Dead Peer Detection enabled
SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D 2x,
NOTIFY:STATUS_REPLAY_STATUS, NOTIFY:STATUS_INITIAL_CONTACT)
Established IKE SA
MY COOKIE db 4a a4 73 dd af 3 2b
HIS COOKIE cd 99 66 5c 35 94 21 28
Initiating IKE Phase 2 with Client IDs (message id: 80266275)
Initiator = IP ADDR=192.168.110.32, prot = 0 port = 0
Responder = IP ADDR=192.168.111.10, prot = 0 port = 0
SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID 2x)
QM re-keying timed out. Retry count: 1

This is the log from the router :

phase-I negotiation
received NOTIFY PAYLOAD of notify type REPLAY_STATUS
received NOTIFY PAYLOAD of notify type INITIAL_CONTACT
IKE phase-I started
Initiator SPD selectors received: IPADDR, 192.168.110.xx, proto 0,
port 0
Responder SPD selectors received: IPADDR, 192.168.111.xx, proto 0,
port 0
No matching SPD policy for the selectors received in IKE phase-II
message IKE phase-II with message ID 80266275 failed

There are three retries which I removed for a better reading
experience

Phase 1 completes successfully, Phase 2 times out. At first, it is
rather obvious, the entry in the security policy database must be
wrong and the router stops responding because of this. But the entries
look very good to me (I usually know what I'm doing) and we already
tried every senseful and senseless combination possible.

Has anyone else encountered similar problems with the Netgear FVS338
router? We set up dozens of smaller routers with VPN, like the Netgear
FVS318 and never had any problems. Firmware and Drivers are up to date
- before you ask

What else (than wrong entries in the security policy database) could
cause this problem?

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

Your connection IP/name does not match

On 27 Apr 2005 09:23:30 -0700, nicolas.keller@slb.de (Nicolas Keller)
wrote:

>I want to establish a VPN connection from a client (Windows XP SP2,
>Netgear ProSafe VPN Client Software) over the internet to a Netgear
>FVS338 ProSafe VPN Firewall. After two days of trying, I'm starting to
>get mad. The process fails after initiating IKE Phase 2.
>
>This is the log from the Netgear ProSafe VPN Client (leading date/time
>information was deleted for better reading):
>
>Attempting to resolve Hostname (xxx.dyndns.org)
>Initiating IKE Phase 1 (Hostname=xxx.dyndns.org) (IP
>ADDR=xxx.xxx.xxx.xxx)
>SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID 6x)
>RECEIVED<<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, NAT-D 2x, VID
>2x)
>Peer is NAT-T draft-02 capable
>NAT is detected for Client
>Floating to IKE non-500 port
>Peer supports Dead Peer Detection Version 1.0
>Dead Peer Detection enabled
>SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D 2x,
>NOTIFY:STATUS_REPLAY_STATUS, NOTIFY:STATUS_INITIAL_CONTACT)
>Established IKE SA
>MY COOKIE db 4a a4 73 dd af 3 2b
>HIS COOKIE cd 99 66 5c 35 94 21 28
>Initiating IKE Phase 2 with Client IDs (message id: 80266275)
>Initiator = IP ADDR=192.168.110.32, prot = 0 port = 0
>Responder = IP ADDR=192.168.111.10, prot = 0 port = 0
>SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID 2x)
>QM re-keying timed out. Retry count: 1
>
>This is the log from the router :
>
>phase-I negotiation
>received NOTIFY PAYLOAD of notify type REPLAY_STATUS
>received NOTIFY PAYLOAD of notify type INITIAL_CONTACT
>IKE phase-I started
>Initiator SPD selectors received: IPADDR, 192.168.110.xx, proto 0,
>port 0
>Responder SPD selectors received: IPADDR, 192.168.111.xx, proto 0,
>port 0
>No matching SPD policy for the selectors received in IKE phase-II
>message IKE phase-II with message ID 80266275 failed
>
>There are three retries which I removed for a better reading
>experience
>
>Phase 1 completes successfully, Phase 2 times out. At first, it is
>rather obvious, the entry in the security policy database must be
>wrong and the router stops responding because of this. But the entries
>look very good to me (I usually know what I'm doing) and we already
>tried every senseful and senseless combination possible.
>
>Has anyone else encountered similar problems with the Netgear FVS338
>router? We set up dozens of smaller routers with VPN, like the Netgear
>FVS318 and never had any problems. Firmware and Drivers are up to date
>- before you ask
>
>What else (than wrong entries in the security policy database) could
>cause this problem?

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

We finally figured it out: The problem was that we used the VPN Wizard
which build a wrong SPD entry you can't fix afterwards. You have to
create an entry in the SPD database *manually*. Netgear Support
confirmed it's a problem with the wizard (unfortunately we had half of
the support center on the phone before someone told us ;-) ).

Thanks for helping!

nicolas.keller@slb.de (Nicolas Keller) wrote in message news:<11b2268.0504270823.3142f0b8@posting.google.com>...
> I want to establish a VPN connection from a client (Windows XP SP2,
> Netgear ProSafe VPN Client Software) over the internet to a Netgear
> FVS338 ProSafe VPN Firewall. After two days of trying, I'm starting to
> get mad. The process fails after initiating IKE Phase 2.
>
> [...]

 

[Slipdipidis]

THAT IS ABSOLUTELY CORRECT !!!

ISSUE RESOLVED.

When adding a new policy, do not use the wizard. This also applies to the FVS318(all versions).
The firmware updates have never addressed this issue (as of FW ver. 3.0.27).
The SPD entry is incorrect and the tunnel drops after 60 seconds or so of failed QM re-keys (although you may or may not see the failures in the client log).

To resolve the issue, copy all your settings, delete the VPN first, then the IKE.
Create a manual IKE policy, copy all the info back into the policy.
Now create an VPN Auto Policy (must use auto policy for stand-alone tunnels for use with the prosafe clients).
Put all the info back in that you copied earlier and save the policy.

Now give it a try. If you entered all the info the same way you copied it down, it should connect... and whats this ? It stays up !!!!