NTJOCK
asked on
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.
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.
ASKER
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.
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.
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.
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.
By the way phase 2 failure is usually more a problem with mis-matched encryption algorithm selections.
ASKER
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.
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.
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:
http://www3.ns.sympatico.ca/malagash/Downloads/Netgear%20Sample/
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:
http://www3.ns.sympatico.ca/malagash/Downloads/Netgear%20Sample/
ASKER
I'm using the same settings. I've tried des/md5 and 3des/sha1. I've got the local IP set to 192.168.1.0/255.255.255.0 which should refer to the whole subnet. I have the remote set to ANY. The remote VPN endpoint is set to IP Address/0.0.0.0
I've disabled PFS (because I really don't care, lol) I've got the same settings on the client as well.
any ideas?
I've disabled PFS (because I really don't care, lol) I've got the same settings on the client as well.
any ideas?
ASKER
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.
ASKER
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.
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.
ASKER
I'm changing the remote IP range to 192.168.5.1/192.168.5.10 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!
I meant to mention above that the sample I provided uses 192.168.1.0 as the local subnet. Always choose something less common as they must be different at both ends, and a lot of remote users have 192.168.1.0
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.
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.
ASKER
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.
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.
ASKER
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.
Can you help me understand what goes on in phase II? I think an analysis of the steps will reveal the mismatch or obstacle.
>>"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 192.168.1.0. This is a basic rule of VPN's. Problem is when the router receives a packet for the 192.168.1.0 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 192.168.0.0, 192.168.1.0, 192.168.2.0, 192.168.100.0, 192.168.111.0, and 10.0.0.0
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.
Understand that is a huge task, however at least for test purposes, make sure the client end uses something other than 192.168.1.0. This is a basic rule of VPN's. Problem is when the router receives a packet for the 192.168.1.0 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 192.168.0.0, 192.168.1.0, 192.168.2.0, 192.168.100.0, 192.168.111.0, and 10.0.0.0
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.
ASKER
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 192.168.5.1-.10
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!
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 192.168.5.1-.10
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!
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."
Absolutely.
ProSafe client is actually extremly stable. A pain to set up though. <G>
>>"I am almost certain that the client IP is determined at connection."
Absolutely.
ProSafe client is actually extremly stable. A pain to set up though. <G>
ASKER
I'm going to try upgrading the firmware on the router. I hate doing that as what I have is stable.
ASKER
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.
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.
>>"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)
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)
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:
http://kbserver.netgear.com/pdf/fvs114_ref_manual_29Apr05.pdf
http://kbserver.netgear.com/pdf/fvs114_ref_manual_29Apr05.pdf
ASKER
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!
;-)
>>"Can you help me understand what goes on in phase II?"
See pdf page 176 in last link provided.
See pdf page 176 in last link provided.
ASKER
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.
UGGGH!
Dlink stuff worked but it dies randomly at about 18 months. Making it unsuitable for production.
They require some a format called PEM or DER for certificates which is not offered by Certificate Services on MSFT.
UGGGH!
Dlink stuff worked but it dies randomly at about 18 months. Making it unsuitable for production.
ASKER
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).
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).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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. 192.168.1.0 to 192.168.1.0 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.co
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 192.168.1.1
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.
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. 192.168.1.0 to 192.168.1.0 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.co
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 192.168.1.1
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.
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. 192.168.1.0 to 192.168.1.0 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.
Cheers.
--Rob
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. 192.168.1.0 to 192.168.1.0 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.
Cheers.
--Rob
ASKER
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_rem
- 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 0.0.0.0 for the IP address
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_rem
- 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 0.0.0.0 for the IP address
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.
http://kbserver.netgear.com/kb_web_files/n101436.asp
http://www.vpncasestudy.com/casestudy/FVS114/v11/casestudy.html
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.