Link to home
Start Free TrialLog in
Avatar of Pumpernickel
PumpernickelFlag for United States of America

asked on

The most Secure VPN line

I'm going to setup a VPN.  I'm trying to figure out what is the most secure way to set one up.  Which protocols are better?  PPTP, SSTP.. ect?  I have a netgear vpn box but the problem is it doesn't assign clients ips from the DHCP, so I need to setup something up that will assign local ips from the dhcp server such as sstp or pptp, ect.
Avatar of Qlemo
Qlemo
Flag of Germany image

PPTP is considered unsafe for long-term use, as it does not change the encryption key, and the encryption key is derived directly from the password you use. A long and cryptic password is hence more secure not only for connection establishment but also encrypting all traffic.

Usually you do not need to use the global DHCP pool for VPN connections - just exclude a small region from your DHCP pool and assign it to the VPN box. In most cases this works flawlessly. DHCP alone is no reason for using PPTP (or SSTP).
If you asking for security, you should choose IPSec with AES, SHA-1 and Diffie-Hellman key exchange.
Avatar of Pumpernickel

ASKER

How would I setup IPSec with SHA-1 on windows server 2008? Or do I have to use the netgear vpn box?
The latter one should work. And IPSec needs both a VPN client and server - there is nothing integrated in Windows capable of connecting to or terminating a IPSec service (besides Forefront/ISA Server).
So then what you are saying, I would have to use the netgear vpn box because it supports ipsec?  The only problem is it doesnt have a DHCP pool.  When you use the netgear vpn client software, it doesnt give you an ip from the dhcp server.
I'm aware of that. As I described, you need to exclude some range from your DHCP pool, and assign that to the Netgear's VPN client IP pool.
But if I turn the DHCP on the netgear box, wont that assign ips out and conflict with the domain controller dhcp server?
Usually the IPSec VPN IP pool is not assigned using DHCP, but by a similar mechanism only applied to the VPN connections. However, I'm uncertain there about the Netgear. The simple approach is to use the Netgear DHCP only - it should not make any difference whether you use the Windows Server's DHCP server or Netgear's.
I have to use windows dhcp because I use three ip ranges.  The netgear vpn won't support that.  
That's a valid reason ;-). In that case you should have a look into Netgear VPN settings if you can assign a static range of IPs to use. If that is the case, you don't use DHCP for VPN.
I'm using an FVS318v3.  I don't see a setting for the vpn ip pool.  Maybe I'm missing something, unless it doesn't support it.  
There is not much literature out there for this router, but what I see confirms that you can't choose an IP pool. The configuration examples (found on a German site only, sorry: http://www.netgear.de/download/anleitungen/VPNKonfigurationsanleitung.pdf, page 11ff) describe you have to set up a static IP address in the ProSafe client. Would that be appropriate?
The configuration for the FVS318 is at http://www.vpnc.org/InteropProfiles/FVS318-profile.pdf   Now would I put the static ip where it says Local IPSec Identifier on page 3?
The Local and Remote IPSec ID is something exchanged at connection init to identify the partners. It can be a mail address, DNS name, IP address, or whatsoever.

The PDF shows a LAN-LAN setup, you are wanting a Client-LAN setup, so that one is not applicable.
http://kb.netgear.com/app/answers/detail/a_id/999

What about the remote lan ip address?  Step 2f and Step 13f?
Correct.
That requires a single VPN per client, as you need exact match of the IP addresses configured.
These are my options in the VPN Policies:

VPN Auto Policy Help
This screen allows you to define or edit an "Auto" VPN policy.

An "Auto" VPN policy uses the IKE (Internet Key Protocol) to exchange and negotiate parameters for the IPsec SA (Security Association). Because of this negotiation, it is not necessary for all settings on this VPN Gateway to match the settings on the remote VPN endpoint. Where settings must match, this is indicated.

General
These settings identify this policy and determine its major characteristics.
Name
Enter a unique name to identify this policy. This name is not supplied to the remote VPN endpoint. It is used only to help you manage the policies.
IKE policy
The existing IKE policies are presented in a drop-down list.
The required IKE policy must be created BEFORE the VPN policy.
Select the desired IKE policy.

IKE Keep Alive
Enable Keep Alive to ensure that the VPN tunnel is re-established quickly if the connection is lost. Enter an IP Address on the remote LAN. This address will be periodically pinged to test the connection.

Remote VPN Endpoint
Select the desired option (IP address or Domain Name) and enter the address of the remote VPN Gateway/Server or client you wish to connect to.

Note: The remote VPN endpoint must have this VPN Gateway's address entered as it's "Remote VPN Endpoint".

SA Life Time
This determines the time interval before the SA (Security Association) expires. (It will automatically be re-established if necessary.) While using a short time period (or data amount) increases security, it also degrades performance. It is common to use periods over an hour (3600 seconds) for the SA Life Time.
PFS (Perfect Forward Secrecy)
If enabled, security is enhanced by ensuring that the key is changed at regular intervals. Also, even if one key is broken, subsequent keys are no easier to break. (Each key has no relationship to the previous key.)
PFS Key Group - If PFS is enabled, this setting determines the DH group used.

 

Traffic Selector
These settings determine if and when a VPN tunnel will be established. If network traffic meets ALL criteria, then a VPN tunnel will be created.
Local IP
This identifies which PCs on your LAN are covered by this policy. For each selection, data must be provided as follows:
Any - no additional data is required. Any IP address is acceptable.
Single address - enter an IP address in the "Start IP address" field.
Range address - enter the starting IP address in the "Start IP address" field, and the finish IP address in the "Finish IP address" field.
Subnet address - enter the desired network mask in the "Subnet Mask" field.
The remote VPN endpoint must have these IP addresses entered as it's "Remote" addresses.
Remote IP
This identifies which PCs on the remote LAN are covered by this policy. For each selection, data must be provided as follows:
Any - no additional data is required. Any IP address is acceptable.
Any outgoing traffic from the "Local IP" PCs will trigger an attempted VPN connection to the remote VPN endpoint. Any Internet traffic will be sent via the remote VPN endpoint.
Only select this option if this is really what you want.
Single address - enter an IP address in the "Start IP address" field.
Range address - enter the starting IP address in the "Start IP address" field, and the finish IP address in the "Finish IP address" field.
Subnet address - enter the desired network mask in the "Subnet Mask" field.
The remote VPN endpoint must have these IP addresses entered as it's "Local" addresses.

 

AH Configuration
AH (Authentication Header) specifies the authentication protocol for the VPN header. These settings must match the remote VPN endpoint.

AH Authentication is often not used. In this case, leave the checkbox unchecked.
To use AH Authentication, check the checkbox and select the desired Authentication Algorithm.
 

ESP Configuration
ESP (Encapsulating Security Payload) provides security for the payload (data) sent through the VPN tunnel. Generally, you will want to enable both Encryption and Authentication. These settings must match the remote VPN endpoint.

Encryption   To enable ESP Encryption, check this checkbox and select the desired Encryption Algorithm.

Authentication   To enable ESP Authentication, check this checkbox and select the desired Authentication Algorithm.
NETBIOS Enable

Check this if you wish NETBIOS traffic to be forwarded over the VPN tunnel. The NETBIOS protocol is used by Microsoft Networking.



I don't see a Remote Lan start ip address, there is a remote ip or a reomte vpn option.

Screen shot of my vpn policy: http://delranems.org/chris/vpn.png

The upper part (Remote VPN Endpoint) should be none, or the public IP of your client.
The lower part should be the range or single IP you want to assign to the VPN Client.
I can't seem to get this to work... I made a test policy.  Its currently not active, so I don't mind posting the information on it.  Did I set something wrong?

VPN Box:
http://delranems.org/chris/VPN/IKE.png
http://delranems.org/chris/VPN/VPN.png


Client:
http://delranems.org/chris/VPN/client1.JPG
http://delranems.org/chris/VPN/client2.JPG
Sorry it took me so long to return to this question. Too much work to handle ...

I cannot talk about the 3DES/SHA-1/DH-2 part, since it is not shown in the client settings. However, the IP setting on your router is wrong.

In "VPN.png", set VPN Remote Endpoint to IP Address 0.0.0.0 (my mistake, sorry - I told you something different earlier). You can see the reason in "IKE.VPN", on the help panel, under "Remote Access".

In "VPN.png", Traffic Selector, set Local IP to any, and Remote IP to 10.1.10.5.

In "IKE.png" and in both client setting pages, you need to set up the identification type to "Name". Again, the explanation why is in "IKE.png"'s help.

If it still does not work, try to get a log from both client and router. The router should tell you something like "No proposal chosen", or "ID mismatch" or the like.
I got an error on the VPN.png ERROR : Remote network can not be on the LAN subnet             That came up when I set the Remote IP to single address and typed in 10.1.10.5

So should I set it on subnet??  If I set it on subnet, then how will I identify the ip?
That is weird, when I select Subnet as the type, then put in the ip 10.1.10.5, then subnet 255.255.254.0, I still get the same error... even though that it is a different subnet.. But then again, I need them on the same subnet so I can ping it..
Okay, I set the type to Single IP and then the IP to 10.1.12.1, that worked.
On the client, the only thing I have on the My Identity Page under ID Type is IP Address, Domain Name, E-Mail Address.  Under DelranEMS, under the Remote Party Identity and Addressing, for the ID Type, I have Any, IP Address, Domain Name, Distinguished Name.

I don't have just Name..
My Security Policy Editor is 10.8.4 (Build 2)
The IP issue is coming from an subnet conflict. I thought you could choose whatever you like to do, but that was on error, obviously. The client IP subnet has to be different from the LAN. That is why a 10.1.12.x address works.

Regarding "Name": That is what the "help panel" says. Maybe it is in fact "Domain Name". So what you set up there seems to be correct.

Did you try the VPN yet (with the new IP address set up in the client)?
I keep getting an error:

 9-02: 11:10:20.046 My Connections\DelranEMS - Initiating IKE Phase 1 (IP ADDR=76.116.44.66)
 9-02: 11:10:20.234 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID 6x)
 9-02: 11:10:23.375 My Connections\DelranEMS - RECEIVED<<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, NAT-D 3x)
 9-02: 11:10:23.375 My Connections\DelranEMS - Peer is NAT-T draft-01 capable
 9-02: 11:10:23.375 My Connections\DelranEMS - NAT is detected for Peer
 9-02: 11:10:23.500 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D 2x, NOTIFY:STATUS_REPLAY_STATUS, NOTIFY:STATUS_INITIAL_CONTACT)
 9-02: 11:10:23.500 My Connections\DelranEMS - Established IKE SA
 9-02: 11:10:23.500 My Connections\DelranEMS -   MY COOKIE 99 a3 6b 8f ca 52 b9 66
 9-02: 11:10:23.500 My Connections\DelranEMS -   HIS COOKIE 3f e2 c2 5d 95 47 31 dd
 9-02: 11:10:23.562 My Connections\DelranEMS - Initiating IKE Phase 2 with Client IDs (message id: 9B9F202D)
 9-02: 11:10:23.562 My Connections\DelranEMS -   Initiator = IP ADDR=75.195.217.57, prot = 0 port = 0
 9-02: 11:10:23.562 My Connections\DelranEMS -   Responder = IP ADDR=10.1.12.1, prot = 0 port = 0
 9-02: 11:10:23.562 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID 2x)
 9-02: 11:10:39.234 My Connections\DelranEMS - QM re-keying timed out. Retry count: 1
 9-02: 11:10:39.234 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK QM *(Retransmission)
 9-02: 11:10:39.718 My Connections\DelranEMS - RECEIVED<<< ISAKMP OAK QM *(HASH, SA, NON, ID 2x)
 9-02: 11:10:39.718 Cannot match Policy Entry for received Phase 2 IDs:
 9-02: 11:10:39.718 local host=IP ADDR=10.1.12.1, prot = 0 dst_port = 0
 9-02: 11:10:39.718 remote host=IP SUBNET/MASK=0.0.0.0/0.0.0.0, prot = 0 src_port = 0
 9-02: 11:10:39.718 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK INFO *(HASH, NOTIFY:INVALID_ID_INFO)
 9-02: 11:10:39.718 NO MATCHING SECURE CONNECTION (IP ADDR=76.116.44.66) - Error validating Proxy ID
 9-02: 11:10:54.234 My Connections\DelranEMS - QM re-keying timed out. Retry count: 2
 9-02: 11:10:54.234 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK QM *(Retransmission)
 9-02: 11:11:09.234 My Connections\DelranEMS - QM re-keying timed out. Retry count: 3
 9-02: 11:11:09.234 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK QM *(Retransmission)
I uploaded my client policy, if you could, take a look at it for me please.  http://delranems.org/chris/Policy.zip

Just go by the screen shots I posted, the connection is disabled on the vpn side.
I cannot tell (at the moment) what is wrong. Phase 1 is fine, but Phase 2 has a mismatch somewhere. The public IP is sent, and the local IP which is expected for the VPN:

 9-02: 11:10:23.562 My Connections\DelranEMS - Initiating IKE Phase 2 with Client IDs (message id: 9B9F202D)
 9-02: 11:10:23.562 My Connections\DelranEMS -   Initiator = IP ADDR=75.195.217.57, prot = 0 port = 0
 9-02: 11:10:23.562 My Connections\DelranEMS -   Responder = IP ADDR=10.1.12.1, prot = 0 port = 0
 9-02: 11:10:23.562 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID 2x)
 9-02: 11:10:39.234 My Connections\DelranEMS - QM re-keying timed out. Retry count: 1

the QM re-key time out happens after 15 seconds - that is rather long, usually you have a timeout of one second. Nevertheless, after sending the same QM message (ISAKMP OAK...), the FVS answers, and the IP addresses exchanged are not matching:

Client: Local = 75.195.217.57, Remote = 10.1.12.1
FVS:   Remote = 0.0.0.0, Local = 10.1.12.1

For a test, you could enter the current public IP your client uses on the FVS instead of the 0.0.0.0 remote network. However, that will only help temporarily (if at all).

I cannot see the setting used to configure the proxy ID, probably it is just automatic. However, on some devices the proxy IDs configured on client and server need to match exactly, while on others it is ok to send a more specific proxy ID (76. .../32 is more specific than 0.0.0.0/0, of course).
That is weird, if I set the Remote Address on the FVS to Any, it will let the client connect...
So I tried setting my remote address to my wan ip in the FVS, and it connected.  I set my Remote Party Identity and Addressing to: ID Type: IP Subnet              Subnet: 10.1.10.40            Mask: 255.255.255.0

I tried to ping 10.1.10.50 and it couldn't ping it.  Then I set my IP Subnet to Subnet: 10.1.10.0, Mask: 255.255.255.0 and it could ping it... I wonder whats going on here..
Strictly seen, a subnet of 10.1.10.40/24 is not valid. The network part (the last byte here) needs to be zero to be valid. Maybe the FVS is irritated by that?
Then what would I set my subnet to so I am able to ping the FVS?  The FVS is 10.1.10.1.  
Or maybe this FVS318v3 is just a piece of shyt :)
You wrote you could ping 10.1.10.50 with the "correct" subnet settings. What is the issue then if you remain at that setting?
Yeah, if I set the subnet 10.1.10.0, then I can ping 10.1.10.50, BUT I'm trying to ping the VPN client from 10.1.10.50, but with the ip 10.1.10.0, that won't logically work.
It should. Because the FVS should capture that packet, and act as a proxy for the IP address (Proxy ARP). In LAN, the FVS will have that IP address (virtually), and so all LAN components should send traffic for this IP to the FVS, which will pass traffic to the remote client.
So if I have two vpn clients that are using the same vpn profile, just different ike policies.. they both would have the ip 10.1.10.0... so how would that work then?? Now I'm getting very confused.
ASKER CERTIFIED SOLUTION
Avatar of Qlemo
Qlemo
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Well if 10.1.10.x is the subnet, how does it know what ip to assign if I didn't specify a range anywhere?
Under my connection monitor, I now have:
Local Address: 75.206.007.142
Local Subnet: &255.255.255.255
Remote Address: 010.001.011.010
GW Address: 76.116.44.XX (XX is a number, I'm just not typing it)
Protocol: All
Local Port: All
Rem Port: All
010.001.011.010 is a very specific IP address, isn't it? You have set that up on your client, IIRC, because the FVS does not want to choose any for the client (I assume).
So with the same setting on FVS, other clients should be able to connect, as long as they assign themselves different IPs.
Ha, yeah it is specific.  I had posted that about knowning what IP before I assigned it 10.1.11.10.  I'll double check my settings.  It seems to connect but now I can't even ping 10.1.10.50.
I should change my IP Subnet to 10.1.11.0, correct?
Are you sure that you can setup this VPN client like this.  So that you can ping the IP from inside the network, if the client is on a verizon card or another connection.
Are you asking if I'm positive you are able to ping a VPN client from the LAN? No, I'm not. That really depends on many things.
Do you have any other suggestions on a way for me to set this up without using windows pptp or sstp?
I'm confused because your config and what works changes all the time.

If you choose a different subnet, e.g. 10.1.12.0/24, you can connect, but not ping?
If you choose the LAN subnet, you get an error when trying to config first, but now you can set that up?

And what is what you want to achieve exactly: Full accecss from both LAN to Client and Client to LAN?
If I change the subnet to 10.1.10.0, it connects fine (If its changed in the client and fvs).  If I change it to 10.1.11.0, it connects fine (same thing, both places changed).  If I try and set an IP in the Remote IP on the FVS, it keeps doing what I posted above:

 9-02: 11:10:23.562 My Connections\DelranEMS - Initiating IKE Phase 2 with Client IDs (message id: 9B9F202D)
 9-02: 11:10:23.562 My Connections\DelranEMS -   Initiator = IP ADDR=75.195.217.57, prot = 0 port = 0
 9-02: 11:10:23.562 My Connections\DelranEMS -   Responder = IP ADDR=10.1.12.1, prot = 0 port = 0
 9-02: 11:10:23.562 My Connections\DelranEMS - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID 2x)
 9-02: 11:10:39.234 My Connections\DelranEMS - QM re-keying timed out. Retry count: 1

It will do 3 Retry Counts, then say unable to connect.  

What I'm trying to do its Full Access from Lan to Client and Client to Lan.
It works as long as I have, on the FVS, the Local set to 10.1.1X.0 matching the client.  OR if I set the FVS local to Any.
That makes sense as long as what you set up is the restriction (access rule, policy, firewall rule, however you want to name it), not the IP address. The "security description", which both sides' IPs are part of, need to match. However, that does not explain why it does not work if you set a single IP on both sides.

If you are using 10.1.10.0/24, could you try use something where the connection remains open, like RDP or network access, from client to LAN, and than look on the server with netstat -n which IP the client uses in fact?
Okay, so keep my subnet on 10.1.10.0 and connect using an RDP to something on the Lan.  Then do netstat -n on the client side?
Best on both sides.
The Client:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Christopher>netstat -n

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    10.1.10.56:3587        69.63.176.193:80       TIME_WAIT
  TCP    69.97.189.159:3705     68.195.120.113:32213   ESTABLISHED
  TCP    69.97.189.159:3713     69.63.176.193:80       TIME_WAIT
  TCP    69.97.189.159:3714     69.63.176.193:80       ESTABLISHED
  TCP    69.97.189.159:3721     10.1.10.50:3389        ESTABLISHED
  TCP    69.97.189.159:3722     10.1.10.50:445         ESTABLISHED
  TCP    127.0.0.1:1140         127.0.0.1:1141         ESTABLISHED
  TCP    127.0.0.1:1141         127.0.0.1:1140         ESTABLISHED
  TCP    127.0.0.1:1144         127.0.0.1:1145         ESTABLISHED
  TCP    127.0.0.1:1145         127.0.0.1:1144         ESTABLISHED
  TCP    127.0.0.1:2869         127.0.0.1:3594         ESTABLISHED
  TCP    127.0.0.1:3594         127.0.0.1:2869         ESTABLISHED
  TCP    127.0.0.1:5152         127.0.0.1:3384         CLOSE_WAIT

C:\Documents and Settings\Christopher>
Whops,


The CLIENT:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Christopher>netstat -n

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    10.1.10.56:3587        69.63.176.193:80       TIME_WAIT
  TCP    69.97.189.159:3705     68.195.120.113:32213   ESTABLISHED
  TCP    69.97.189.159:3713     69.63.176.193:80       TIME_WAIT
  TCP    69.97.189.159:3714     69.63.176.193:80       ESTABLISHED
  TCP    69.97.189.159:3721     10.1.10.50:3389        ESTABLISHED
  TCP    69.97.189.159:3722     10.1.10.50:445         ESTABLISHED
  TCP    127.0.0.1:1140         127.0.0.1:1141         ESTABLISHED
  TCP    127.0.0.1:1141         127.0.0.1:1140         ESTABLISHED
  TCP    127.0.0.1:1144         127.0.0.1:1145         ESTABLISHED
  TCP    127.0.0.1:1145         127.0.0.1:1144         ESTABLISHED
  TCP    127.0.0.1:2869         127.0.0.1:3594         ESTABLISHED
  TCP    127.0.0.1:3594         127.0.0.1:2869         ESTABLISHED
  TCP    127.0.0.1:5152         127.0.0.1:3384         CLOSE_WAIT

C:\Documents and Settings\Christopher>netstat -n

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    69.97.189.159:3705     68.195.120.113:32213   ESTABLISHED
  TCP    69.97.189.159:3721     10.1.10.50:3389        ESTABLISHED
  TCP    69.97.189.159:3722     10.1.10.50:445         ESTABLISHED
  TCP    69.97.189.159:3864     66.220.147.11:80       ESTABLISHED
  TCP    69.97.189.159:3865     69.63.176.193:80       ESTABLISHED
  TCP    69.97.189.159:3866     64.156.132.140:80      TIME_WAIT
  TCP    69.97.189.159:3867     64.156.132.215:80      CLOSE_WAIT
  TCP    69.97.189.159:3868     64.156.132.215:80      CLOSE_WAIT
  TCP    69.97.189.159:3869     64.156.132.215:80      CLOSE_WAIT
  TCP    69.97.189.159:3870     64.156.132.215:80      CLOSE_WAIT
  TCP    69.97.189.159:3871     64.156.132.140:80      TIME_WAIT
  TCP    69.97.189.159:3872     64.156.132.140:80      TIME_WAIT
  TCP    69.97.189.159:3873     64.156.132.140:80      TIME_WAIT
  TCP    69.97.189.159:3874     64.156.132.140:80      TIME_WAIT
  TCP    69.97.189.159:3875     64.156.132.140:80      TIME_WAIT
  TCP    127.0.0.1:1140         127.0.0.1:1141         ESTABLISHED
  TCP    127.0.0.1:1141         127.0.0.1:1140         ESTABLISHED
  TCP    127.0.0.1:1144         127.0.0.1:1145         ESTABLISHED
  TCP    127.0.0.1:1145         127.0.0.1:1144         ESTABLISHED
  TCP    127.0.0.1:5152         127.0.0.1:3384         CLOSE_WAIT

C:\Documents and Settings\Christopher>
The RDC:

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\administrator.DES>netstat -n

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    10.1.10.50:80          10.1.10.63:1346        ESTABLISHED
  TCP    10.1.10.50:139         10.1.10.65:3513        ESTABLISHED
  TCP    10.1.10.50:389         10.1.10.50:61911       ESTABLISHED
  TCP    10.1.10.50:389         10.1.10.50:61921       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.55:51336       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.55:52280       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.55:52545       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.55:52546       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.55:54102       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.55:54103       ESTABLISHED
  TCP    10.1.10.50:445         10.1.10.61:51696       ESTABLISHED
  TCP    10.1.10.50:445         69.97.189.159:3722     ESTABLISHED
  TCP    10.1.10.50:3389        69.97.189.159:3721     ESTABLISHED
  TCP    10.1.10.50:4158        10.1.10.50:65241       TIME_WAIT
  TCP    10.1.10.50:4158        10.1.10.54:4204        TIME_WAIT
  TCP    10.1.10.50:4158        10.1.10.54:4206        TIME_WAIT
  TCP    10.1.10.50:4158        10.1.10.61:51831       TIME_WAIT
  TCP    10.1.10.50:4158        10.1.10.74:65297       TIME_WAIT
  TCP    10.1.10.50:49156       10.1.10.55:54099       ESTABLISHED
  TCP    10.1.10.50:49213       10.1.10.99:10020       ESTABLISHED
  TCP    10.1.10.50:49214       10.1.10.98:10020       ESTABLISHED
  TCP    10.1.10.50:49215       10.1.10.97:10020       ESTABLISHED
  TCP    10.1.10.50:49314       10.1.10.55:54112       ESTABLISHED
  TCP    10.1.10.50:49314       10.1.10.61:51735       ESTABLISHED
  TCP    10.1.10.50:49314       10.1.10.74:63935       ESTABLISHED
  TCP    10.1.10.50:61911       10.1.10.50:389         ESTABLISHED
  TCP    10.1.10.50:61921       10.1.10.50:389         ESTABLISHED
  TCP    10.1.10.50:65141       10.1.10.50:135         TIME_WAIT
  TCP    10.1.10.50:65142       10.1.10.50:49184       TIME_WAIT
  TCP    10.1.10.50:65214       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65217       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65220       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65225       212.96.161.238:80      TIME_WAIT
  TCP    10.1.10.50:65226       212.96.161.238:80      TIME_WAIT
  TCP    10.1.10.50:65230       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65232       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65235       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65238       10.1.10.50:135         TIME_WAIT
  TCP    10.1.10.50:65242       10.1.10.49:135         TIME_WAIT
  TCP    10.1.10.50:65245       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65251       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65254       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65256       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65259       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65262       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65265       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65274       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65276       65.254.250.109:110     TIME_WAIT
  TCP    10.1.10.50:65277       72.14.204.103:80       ESTABLISHED
  TCP    10.1.10.50:65279       72.14.204.103:80       ESTABLISHED
  TCP    10.1.10.50:65280       10.1.10.75:80          ESTABLISHED
  TCP    10.1.10.50:65282       65.254.250.109:110     TIME_WAIT
  TCP    127.0.0.1:389          127.0.0.1:49176        ESTABLISHED
  TCP    127.0.0.1:389          127.0.0.1:49178        ESTABLISHED
  TCP    127.0.0.1:389          127.0.0.1:61924        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49182        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49191        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49206        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49208        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49209        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49216        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49222        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49232        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49234        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49235        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49236        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49237        ESTABLISHED
  TCP    127.0.0.1:3050         127.0.0.1:49240        ESTABLISHED
  TCP    127.0.0.1:3060         127.0.0.1:49187        ESTABLISHED
  TCP    127.0.0.1:3060         127.0.0.1:49207        ESTABLISHED
  TCP    127.0.0.1:3060         127.0.0.1:49229        ESTABLISHED
  TCP    127.0.0.1:3060         127.0.0.1:49238        ESTABLISHED
  TCP    127.0.0.1:3060         127.0.0.1:49250        ESTABLISHED
  TCP    127.0.0.1:10110        127.0.0.1:65213        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65216        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65219        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65229        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65231        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65234        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65244        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65250        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65253        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65255        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65258        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65261        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65264        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65273        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65275        TIME_WAIT
  TCP    127.0.0.1:10110        127.0.0.1:65281        TIME_WAIT
  TCP    127.0.0.1:49176        127.0.0.1:389          ESTABLISHED
  TCP    127.0.0.1:49178        127.0.0.1:389          ESTABLISHED
  TCP    127.0.0.1:49182        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49187        127.0.0.1:3060         ESTABLISHED
  TCP    127.0.0.1:49191        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49206        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49207        127.0.0.1:3060         ESTABLISHED
  TCP    127.0.0.1:49208        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49209        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49210        127.0.0.1:49211        ESTABLISHED
  TCP    127.0.0.1:49211        127.0.0.1:49210        ESTABLISHED
  TCP    127.0.0.1:49216        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49222        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49229        127.0.0.1:3060         ESTABLISHED
  TCP    127.0.0.1:49230        127.0.0.1:49231        ESTABLISHED
  TCP    127.0.0.1:49231        127.0.0.1:49230        ESTABLISHED
  TCP    127.0.0.1:49232        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49234        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49235        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49236        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49237        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49238        127.0.0.1:3060         ESTABLISHED
  TCP    127.0.0.1:49240        127.0.0.1:3050         ESTABLISHED
  TCP    127.0.0.1:49250        127.0.0.1:3060         ESTABLISHED
  TCP    127.0.0.1:61924        127.0.0.1:389          ESTABLISHED
  TCP    127.0.0.1:65215        127.0.0.1:9675         TIME_WAIT
  TCP    127.0.0.1:65240        127.0.0.1:9675         TIME_WAIT
  TCP    127.0.0.1:65249        127.0.0.1:9675         TIME_WAIT
  TCP    127.0.0.1:65263        127.0.0.1:9675         TIME_WAIT
  TCP    [::1]:135              [::1]:65222            ESTABLISHED
  TCP    [::1]:445              [::1]:65118            ESTABLISHED
  TCP    [::1]:49156            [::1]:49727            ESTABLISHED
  TCP    [::1]:49156            [::1]:60808            ESTABLISHED
  TCP    [::1]:49156            [::1]:64198            ESTABLISHED
  TCP    [::1]:49727            [::1]:49156            ESTABLISHED
  TCP    [::1]:60808            [::1]:49156            ESTABLISHED
  TCP    [::1]:64198            [::1]:49156            ESTABLISHED
  TCP    [::1]:65118            [::1]:445              ESTABLISHED
  TCP    [::1]:65182            [::1]:135              TIME_WAIT
  TCP    [::1]:65222            [::1]:135              ESTABLISHED

C:\Users\administrator.DES>
It looks like on the client side,   TCP    69.97.189.159:3721     10.1.10.50:3389        ESTABLISHED

3389 is the RDP port.  I don't see 3389 on the Remote Desktop though..
Ah, I see it on the Remote Desktop now.    TCP    10.1.10.50:3389        69.97.189.159:3721     ESTABLISHED
My Client IP though is 75.206.104.41    So I'm not sure where its getting the 69.x.x.x from...
I don't know that, too. It is a public IP - maybe that of the FVS?
Anyways, it should be more of a 10.1.12.x or whatever you use at the moment for the client.
The public wan ip is 76.116.44.xx
Okay, disregard, now its working right.  I just reconnected and checked, its matching my WAN ip on my verizon card.

So now what?
Remote Desktop:
TCP    10.1.10.50:3389        75.206.104.41:3721     ESTABLISHED

Client:
TCP    75.206.104.41:3721     10.1.10.50:3389        ESTABLISHED
That is certainly an error. I assume you are connected without using the VPN. On the other hand it could just be that the NAT is acting "wrong" by mapping to the public IP, but routing over VPN nevertheless. I have never heard of such, but seen VPNs identifying themselves with their public IP.

I'm sorry, but I'm not able to support on that, as I only remotely know of the NetGear VPN Client and the NetGear devices.

Maybe we really should drop that idea. And switch over to OpenVPN, which is a free SSL VPN, and allows for routing (opposed to the most other SSL VPN solutions). However, setup needs some time - it isn't difficult, but there are several steps to take, including configuring a script to generate certificates.

Or we only drop the NetGear client, using ShrewSoft VPN instead (again, that is free). It allows to configure more on the client side. But I cannot tell if it is worth it, the FVS might really be a PITA regarding VPN.
I am connected using the VPN.  The firewall blocks it without the VPN.  I really think this FVS doesn't use true IPSec... That when you connect in, you connect to the FVS, and the FVS just passes your request.  I think I told you already, but the FVS isn't the DHCP server.. not sure if that could be it.. I dought it.

We can try the OpenVPN... it doesn't matter to me.  I'm just trying to get something to work here.  I was going to use SSTP originally because I heard it was more secure than PPTP, but I had this netgear VPN FVS laying around.
Ok, I think the FVS is using the public IP for NAT then, lacking a setting to do different. What about the ShrewSoft client?
I havn't tried that, and I never had set that up.  I can give it a shot.  But will that fix the issue with the ips or is that more of the way the nat is handling it.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Okay, ill see if I can get shrew setup.  Anything I need to know before hand?
No. You might want to have a look at the Wiki of Shrew about configuring Netgear routers, though the images shown there do not look remotely similar to your config screen ...

[2010-09-11 10:44:34]<POLICY: CBruder> PAYLOADS: NOTIFY
[2010-09-11 10:44:39][==== IKE PHASE 1(from 69.98.25.207) START (responder) ====]
[2010-09-11 10:44:39]**** RECEIVED  FIRST MESSAGE OF AGGR MODE ****
[2010-09-11 10:44:39]<POLICY: > PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID,VID,VID,VID,VID,VID,VID,VID,VID,VID,VID,VID
[2010-09-11 10:44:39]<LocalRID> Type=ID_FQDN,ID DATA=cbruder
[2010-09-11 10:44:39]<RemoteLID> Type=ID_FQDN,ID DATA=cbruder
[2010-09-11 10:44:39]ERROR# NO MATCHING ISAKMP PROPOSAL
[2010-09-11 10:44:39]SENDING NOTIFY MSG:
[2010-09-11 10:44:39]NO_PROPOSAL_CHOSEN
[2010-09-11 10:44:39]**** SENT OUT INFORMATIONAL EXCHANGE MESSAGE ****
[2010-09-11 10:44:39]<POLICY: CBruder> PAYLOADS: NOTIFY


I keep getting this error... I'm not sure why its saying No Matching ISAKMP Proposal...
I can't tell from examing that log. The proposals (3DES etc.) might not match, or the Pre-Shared Key.
On Shrew:
Under the general tab, I set the Access Method to 'Use a virtual adapter and assigned address'.  I set the address to 10.1.11.5 and the netmask to 255.255.255.0.  Then under the Policy tab, I unchecked the 'Obtain Topology Automatically or Tunnel All'.  I added the Remote network Resource.  I set the Type of Include, then I set the address to 10.1.11.0 and the netmask to 255.255.255.0.  It connects, but I'm unable to ping any addresses that are on the LAN.  
I'm also guessing theres an error with the security associations on shrew because the Established is still at 0.
Wow, I figured it out.  In the Options of the Netgear VPN Client, then Global Policy Settings, then I had to check 'Allow to Specify Internal Network Address'.  That added the virtual adapter and let me set an IP.  Thanks alot for your help!
Wow, I figured it out.  In the Options of the Netgear VPN Client, then Global Policy Settings, then I had to check 'Allow to Specify Internal Network Address'.  That added the virtual adapter and let me set an IP.  Thanks alot for your help!
Glad you managed to get it work "with a little help"!
Yup, thanks again.  Don't worry, I gave you the points haha.  Now I just have to figure out how to get my subnet mask set to 255.255.255.0 on the VPN connection.  It keeps using 255.255.255.255 because that is what my Verizon Cards are using and that is preventing me still from getting the LAN to resolve or ping the VPN client.