• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6966
  • Last Modified:

Help configuring Netgear Prosafe VPN Client

I have a Netgear FVS124G on our network acting as a firewall.
It has a VPN connection to another Netgear router at a different location that works fine.
I am having hell trying to get a laptop to VPN to the 124G.

I can usually get phase 1 up, but phase 2 fails.

The router displays:
No matching SPD policy for the selectors received in IKE phase-II message

in the vpn log.

I have searched high and low and can't figure out exactly what an SPD is, and what it's requirements are.

I've used a variety of identity schemes.  Including email addresses.

I'm currently using fvs_local and fvs_remote as I understand these are only for authentication purposes.

I'd appreciate some help understanding what an SPD is, figuring out how to get this running without a fixed IP on the client, and in better understanding VPN as netgear imagines it.

My understanding is that Netgear Router to Router with fixed IPs works great.  That isn't an option in this case.  Nor is replacing hardware.  Nor is using SBS 2003 Ras.  

Client is giving time out errors (assume because router is discarding requests based on no matching spd).

I'm assigning 500 points  to this because:
1) I spent 8 hours on it yesterday.  I'm an MCSE and degreed and consider myself "good at IT".
2) It seems to be a particularly tedious thing to get netgear vpn clients to connect.  Netgear has not documented it on their site.  
3) Netgear charges $45 for support. That increases the value a bit I think.
4) There are lots of folks with this problem but few documented solutions that go beyond a example.  In other words nobody is explaining how it works so that people can solve their own headaches and make informed decisions.  

I think that makes it a more valuable question.
  • 16
  • 13
1 Solution
Rob WilliamsCommented:
SPD is just the file type ProSafe (SafeNet) uses for it's security policies. If you were to choose to import an existing security policy (ProSafe client configuration) you would see it is an SPD file. Though that may answer your question, I am sure it is of little help. <G>.

The ProSafe client is a pain in the neck to set up the first time, but it does work well.
Have you seen the following links ? Though not the same router, the configuration is similar.

If still stuck, perhaps I can help with details.
By the way no need of fixed IP on client, but definitely helps on the Server/FVS124G end.
NTJOCKAuthor Commented:
The server is a fixed IP and I currently have a router to router tunnel open for another location.  
I think it's stable.  It has been running for a long time (almost a year)

the netgear KB article is a derivative of another KB article I tried to follow.

I may be hung up on the whole FQDN - fvs_local.com fvs_remote.com  

I'm unable to follow some of the advice (such as leaving the IP blank on policies, that produces an error).

I also see that it says to set the SA life to unspecified which invokes a known issue for Netgear (per their website).

What is key to phase 2 (IKE?) succeeding?  This is pretty clearly a phase 2 failure.  I'm just mystified as to what goes on in phase 2 that isn't happening.
Rob WilliamsCommented:
I usually use on the server end, as Local Identity - "WAN IP Address (the static public IP) and remote identity as - Fully Qualified User Name in the form me@somewhere.com (this does not need to be a real e-mail address or domain). Then on the client match that with ID type - the server end Public IP, and "my Identity", "ID type" - Email address, again in the form me@somewhere.com .
I am "out-a-here" for the night, but I can put together a complete sample config tomorrow night. Have a look at the second link I posted above or that entire site, it is more helpful than the Netgear site.
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

Rob WilliamsCommented:
By the way phase 2 failure is usually more a problem with mis-matched encryption algorithm selections.
NTJOCKAuthor Commented:
I've not made much progress here and I'm still stumped.
You have backed up my suspicions and confirmed that I'm in the right area.

I prefer the email address so I switched back to it.
The real challenge here is why phase 2 is dying.
The log on the router indicates that the settings don't match (vaguely).

I'm a bit confused as to what IKE Policy and VPN policy actually correspond to.

I think IKE is Phase 1 and VPN policy is phase 2.  That's just a hunch from trial and error.

Right now I'm using 3des/sha1, preshared key, group 2, 28800 lifetime on IKE policy.

I'm using ESP and 3des/sha1 on vpn policy.

Client has matching settings.

I've tried PFS enabled and disabled and still not getting anywhere.
I have replay detection enabled as well.
Rob WilliamsCommented:
I would agree IKE is phase 1 and VPN policy Phase 2.
To state the obvious, make sure your encryption options match, but also if phase 2 is failing, verify if you have PFS enabled, it is done on both client and router, and the same Group # chosen.
Following is a link to sample config for a FVS318 and ProSafe client. Should be very similar. Might be of some help:
NTJOCKAuthor Commented:
I'm using the same settings.  I've tried des/md5 and 3des/sha1.  I've got the local IP set to which should refer to the whole subnet.  I have the remote set to ANY.  The remote VPN endpoint is set to IP Address/

I've disabled PFS (because I really don't care, lol)  I've got the same settings on the client as well.

any ideas?
NTJOCKAuthor Commented:
I do have this configured under VPN Client Policy.  I've tried it under just regular VPN policies but that is more for router to router configs.  I even tried putting in the IP of the client as a test to eliminate the IP setting on the VPN policy page.  I did use the VPN wizard to create this, but there is no other way to make a VPN client policy.
NTJOCKAuthor Commented:
INFO :: Initiator SPD selectors received: IPADDR, 166.x.x.x, proto 0, port 0
THU JAN 01 09:11:32 1970  INFO :: Responder SPD selectors received: IPADDR, 24.x.x.x, proto 0, port 0
THU JAN 01 09:11:32 1970  INFO :: No matching SPD policy for the selectors received in IKE phase-II message
THU JAN 01 09:11:32 1970  INFO :: IKE phase-II with message ID bf1dd749 failed

This is the error sequence on the router side.  I think the router side is the issue.  I'm just not sure what the issue is.
NTJOCKAuthor Commented:
I'm changing the remote IP range to as it seems to be a routing table entry.  I don't want all my network traffic to try to return via a VPN connection in timbuktwo!
Rob WilliamsCommented:
I meant to mention above that the sample I provided uses as the local subnet. Always choose something less common as they must be different at both ends, and a lot of remote users have

Never thought to mention, Phase 2 can fail if the subnets are identical. Are they ??

Did you compare with the screen shots I uploaded to the link above? any differences.
It is recommended that you use aggressive, rather than main mode for VPN clients.
NTJOCKAuthor Commented:
I did compare the screenshots.

Agressive is required when you don't know the IP address of both ends.

Our network uses 192.168.1.x so it's not up for discussion right this second.  I just can't change our whole network over. :(

I was expecting the vpn router to assign an IP to the client when it connects, is this wrong?  if so I do need to look at the laptop.

unrelated: right now my cat just brought in a dead mouse, so I have to go "deal" with that and then I'll dig into the client IP some more.  The joys of cat ownership.
NTJOCKAuthor Commented:
I've tried changing to AH vs. ESP and it still doesn't seem to work.  This is most aggravating because there is no obvious cause.

Can you help me understand what goes on in phase II?  I think an analysis of the steps will reveal the mismatch or obstacle.
Rob WilliamsCommented:
>>"Our network uses 192.168.1.x so it's not up for discussion right this second. "
Understand that is a huge task, however at least for test purposes, make sure the client end uses something other than This is a basic rule of VPN's. Problem is when the router receives a packet for the subnet, does it keep it local or send it to the remote site ??? The client is assigned an IP by the router yes, but the remote site still needs to be something else.

If you don't switch the office at some point, the remote users will not be able to connect every time they go to a site with the same subnet. 1/2 of the Internet café's, hotels and homes stick with the default router configs of,,,,, and

Actually I am switching over a little single server and 15 workstation environment tonight for that very reason.

Try dogs, they are easier.....except when they drag in a cat ! <g.

>>"Can you help me understand what goes on in phase II?"
That would assume I know something. Afraid I don't know the details. Phase one does the handshaking and establishes the basic connection, Phase 2 establishes the encryption algorithms to be used.
NTJOCKAuthor Commented:
Hmm, I have a dog too!  He just chases the other cats.

It really wouldn't be that big a deal to change things over except that I've taken some shortcuts in ASP and hardcoded some IPs.  I also have some security stuff enabled at the code level for intranet apps that looks at IP.  So for now it stays.

My primary use of VPN is actually my Edge/cingular connection so no worries about statis configs there.  I have a live (or live enough) IP from Cingular.  The cingular promise is that it's cingularly worthless.  Actually it works okay.  a bit laggy.

As the details emerge, this is is a work-aholic project.  I'm trying to make it so I can do work on my laptop while I'm bowling 2 nites a week.  As a bonus I'll be able to work when I do travel.  But I'm flat rate with Edge/cingular so I can always go to that if I have a crap wireless point.  Primarily this is for email and retrieve and synch HTML/ASP code so I can work on it.  All of which is small and will work over pseudo-dialup.  At some point I may try to expand it, but I only have a couple of other employees who have blackberries.

Back to the issue at hand, the IP address of the vpn client should be assigned at connect.  I set up a modeconfig profile with a small IP range of
Okay so I thought I had that setup.  I re-set that up.  Still no dice.  I am almost certain that the client IP is determined at connection.  Although I have no idea where to specify it in the NetGear ProScrewed client.  It's just baffling why they don't support PPTP.  This is the one sore spot I have with netgear hardware.  It works great accept for VPN.

Rant: I think Netgear's tactic is to inhibit VPN through frustration initiation.  Users will be so annoyed they will give up on connecting to the network and throw the laptop out the window!
Rob WilliamsCommented:
I assume you are not using your Edge card for testing ? I have used the ProSafe client over Cell modems, dial up, and edge cards, but use a basic DSL/ADSL connection for testing. You don't want to add other variables. As for PPTP, very few VPN routers do support it. I only know of Cisco and one of the Linksys.

>>"I am almost certain that the client IP is determined at connection."

ProSafe client is actually extremly stable. A pain to set up though. <G>
NTJOCKAuthor Commented:
I'm going to try upgrading the firmware on the router.  I hate doing that as what I have is stable.  
NTJOCKAuthor Commented:
does this work better with certificates?

It seems like they are sort of pushing towards certificates because the pre-shared key stuff is so poorly explained.  Almost like a sure you can do that have fun figuring it out.

I'm just a tad lost on the whol CA and certificate thing.  I mean I know what they are in the context of web servers.  But I'm not familiar with them in this context.
Rob WilliamsCommented:
>>"does this work better with certificates?"
Never tried it. It is definitely more involved though, and I believe you have to use purchased certificates, rather than "home grown".

If you like I can log on to your router, configure that end, and try to create a client .spd policy file for you to import. I have done it for others. I usually recomend you disconnect your router from your network first for security, and change remote router management passwords when done. However, in this case I would be reluctant as your site to site information would be available to me. Unless you wanted to back up and wipe your configuration.
Should you want to go that route let me know. You can e-mail me the private information (do not post here) through the e-mail on my profile page (click RobWill). discussions pertaining to the solution need to remain on the forum. However, I cannot do it until tomorrow night. I am off to start a project that will probably take most of the rest of the day and tomorrow morning. (-4hrs GMT here)
Rob WilliamsCommented:
Stumbled on the following while looking for something unrelated. It is documentation for FVS114 VPN, but very similar, but much better explanation than other Netgear information I have seen. Starts Chapter 5:
NTJOCKAuthor Commented:
Great document, but more netgear snow and fluff.  They talk about it like it's cotton candy but they never actually explain how they use the parameters or how to troubleshoot it.  They have really good technical writers who don't know squat about their products beyond the buzzwords.  I think they used to work for microsoft!
Rob WilliamsCommented:
Rob WilliamsCommented:
>>"Can you help me understand what goes on in phase II?"
See pdf page 176 in last link provided.
NTJOCKAuthor Commented:
It appears that NetGear is the anti-Microsoft of VPN.

They require some a format called PEM or DER for certificates which is not offered by Certificate Services on MSFT.


Dlink stuff worked but it dies randomly at about 18 months.  Making it unsuitable for production.
NTJOCKAuthor Commented:
Page 176 is just fluff.  It tells you to read the logs and watch the connection monitor.

that's like the mechanic's page in your car manual that says to call the dealer when the red light on the dash comes on.  No new info there.  I'm beginning to think Netgear doesn't know much about VPN and simply bought a package to include in their equipment.  the ProScrewed client is OEM'd from SoftNet (I think that's the name).
Rob WilliamsCommented:
Agree not very detailed but:
IKE Phase I.
a. The two parties negotiate the encryption and authentication algorithms to use in the IKE
b. The two parties authenticate each other using a predetermined mechanism, such as
preshared keys or digital certificates.
c. A shared master key is generated by the Diffie-Hellman Public key algorithm within the
IKE framework for the two parties. The master key is also used in the second phase to
derive IPSec keys for the SAs.
3. IKE Phase II.
a. The two parties negotiate the encryption and authentication algorithms to use in the IPSec
b. The master key is used to derive the IPSec keys for the SAs. Once the SA keys are created
and exchanged, the IPSec SAs are ready to protect user data between the two VPN
4. Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and
keys stored in the SA database.
5. IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.
NTJOCKAuthor Commented:
I have an update.
I broke down and called Netgear expecting to pay $75 for support.
Turns out I'm still under warranty on the router and so they transferred me in for free.  I was shocked.

The high points:

Virtual Adapter is for when you are stuck in a IP range that is the same as what you are connecting to.  i.e. to  It will work around that.  Otherwise it shouldn't be used.  When it is used you need to "decide" what IP you are and fill in the detail.

We are using the FQDN settings.  they steered clear of the FQUN.  We are using <policyname>1.fvs_local.com
I think this tells the router what policy to match you to.

IKE policy is FQDN for local and remote.  using fvs_local.com for router and fvs_remote.com for remote.

for the VPN policy it's important to use 192.168.1.*0* not
Remote IP is set to Any
ESP settings are default  (3des/sha1)

Remote endpoint is set to fvs_remote.com and fqdn.

on the client is where it gets tricky and we did new things.
on my identify we set it to no certificate, entered a pre-shared key and hit save.
this "unlocked" the id type and we could then choose domain name.
You put int <policyname on router>1.fvs_remote.com  - thus id'ng yourself as the remote domain and telling it what policy to use.

Virtual adapter is off for this instance see above for more detail.
interface is set to any.

on the connection page is key as well.
Connect to set to IP Subnet (KEY)
and enter in the subnet/mask

enable connect using secure gateway and tell it
domain =fvs_local.com and gateway IP is your public IP.
this is where you tell the client what you are connecting to and where it is and what network it is.
the phase1/2 stuff is left alone.

I think the key issues were the policyname, FQDN, and the remote party Identity and Addressing.

It now opens a tunnel but won't exchange data.  They are sending me a link to an updated version of the client.  I was running 10.1.1 which I bought a year ago.  Because it's licensed I don't feel it appropriate to repost the link.  Just be aware that the client version may impact things.

stay tuned for more info.

I'm going to award the points to Rob because you did help me get through this and sort it out.  Even though really netgear ended up untangling it.  It's poorly documented and I'm posting this back in hopes that it will help others sort the thing out.
Rob WilliamsCommented:
Thanks NTJOCK, glad to hear you were able to work it out. Seems to me most or all but naming was the same as in the samples provided, but something obviously made the difference for you.

Though I never use the virtual adapter (disabled in sample) I am very skeptical about "Virtual Adapter is for when you are stuck in a IP range that is the same as what you are connecting to.  i.e. to  It will work around that. " Change it to an IP that is not in the same subnet as the remote site and you shouldn't be able to connect.

Appreciate you posting your findings.
NTJOCKAuthor Commented:
I think the key was the "connect to subnet"

There were 3 keys in my opinion and one "oh"

the oh was what the virtual adapater is for.  It just lets you bridge similar subnets and is actually a very useful feature if you can't control the network you are on (internet cafe etc).

The keys were on the client side:
- confirmation of the <policy><sequence>.fvs_remote.com
- connecting to the subnet and clearly defining what you are connecting to.  i.e. what the inside of the remote lan is, the outside, and your credential (FQDN).
- using for the IP address
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

  • 16
  • 13
Tackle projects and never again get stuck behind a technical roadblock.
Join Now