Routing and Remote Access Blog

Configuring Network Load Balancing (NLB) Cluster of VPN Servers

Hello All, in this blog, I will discuss how to configure a "Network Load Balancing Cluster" of vpn servers to ensure high availability and scalability of vpn service.

For information about "Network Load Balancing (NLB)" feature in "Windows Server 2008 R2" please refer the following link: http://technet.microsoft.com/en-us/library/cc725691.aspx

How network load balancing cluster enhances scalability of vpn server?

To create a NLB VPN cluster each host runs Remote Access (VPN) Service & NLB Service. NLB allows all of the computers in the cluster to be addressed by the same cluster IP address. NLB distributes incoming client requests across the vpn servers in the cluster. The load weight to be handled by each vpn server can be configured as necessary. You can also add a vpn server dynamically to the cluster to handle increased load. In addition, NLB can direct all traffic to a designated single vpn server, which is called the default host.

How network load balancing cluster ensures high availability of vpn server?

When a vpn server fails or goes offline, active connection to the failed or offline server are lost. But new connection request is automatically redistributed among the vpn servers that are still operating. However, if you bring a host down intentionally, you can use "drainstop" command to service all active connection prior to bringing the computer offline. Drainstop allows the host to continue surviving active connections but disables all new traffic to that host.

How to configure a NLB cluster?

To configure the Network Load Balancing (NLB) cluster, you must configure three types of the parameters:

• Host parameters, which are specific to each host in a NLB cluster.
• Cluster parameters, which apply to an NLB cluster as a whole.
• Port rules, which control how the cluster functions. By default, a port rule equally balances all TCP/IP traffic across all servers.

In the following section we will describe step by step guide to deploy an nlb cluster of vpn servers for test lab.

Verification step to make sure vpn server is configured properly before installing nlb:

1. Assign satic ip to vpn-server1 (say 201.0.0.1), vpn-server2 (say 201.0.0.2) [Note: NLB does not support DHCP. NLB disables DHCP on each interface that it configures, so the IP addresses must be static]

2. Ensure client is able to make vpn connection to both the servers for different tunnel types (PPTP, L2TP, SSTP or IKEv2).

Install & Configure NLB in vpn-servers:

3. Install NLB in vpn-server1 & vpn-server2.

4. Create a new cluster using the NLB manager [Open nlbmgr.msc (in Administrative tools)] of vpn-server1 according the steps mentioned below. Add host to the cluster, choose priority of the host & assign cluster IP (say 201.0.0.11).

a) Add new host to the cluster:

Give host name or ip address and select the interface of the host for configuring cluster.

b) Host parameter configuration:

c) Configuring the cluster parameter

Select cluster operation mode as unicast to specify that a unicast media access control (MAC) address should be used for cluster operation. In this mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. Unicast is the default setting for Cluster operation mode.

d) Configuring Port Rules:

· Select Affinity Single or Network to ensure that all network traffic from a particular client is directed to the same host.

· Select Filtering mode to Multiple hosts or Single host considering the following:

o The Multiple hosts parameter specifies that multiple hosts in the cluster will handle network traffic for the associated port rule. This filtering mode provides scaled performance and fault tolerance by distributing the network load among multiple hosts. You can specify that the load be equally distributed among the hosts or that each host will handle a specified load weight.

o The Single host parameter specifies that network traffic for the associated port rule be handled by a single host in the cluster according to the specified handling priority. This filtering mode provides port specific fault tolerance for handling network traffic.

5. Add vpn-server2 to the nlb cluster using nlb manager of the vpn-server1. (you can also do this step using the nlb manager of the vpn-server2 after "connecting to existing cluster" with cluster ip 201.0.0.11)

a) Add new host to the cluster

b) Host parameter configuration

c) Configuring Port Rules

d) Configuring load weight for the host

6. Ensure both the server got same MAC Address for that interface & Cluster IP. [Note: NLB automatically instructs the driver that belongs to the cluster adapter to override the adapter's unique, built-in network address and to change its MAC address to the cluster's MAC address. This is the address used on all cluster hosts.]

Verification after configuring nlb cluster for vpn server:

7. Make Connection from the client using Cluster IP. Connection should succeed & it should be connected to high priority server (vpn-sever1 in this case).

8. Give nlb drainstop on vpn-server1.

9. Drainstop allows the host to continue surviving active connections but disables all new traffic to that host. All new connections should go to vpn-server2.

10. Give nlb drainstop on the vpn-server2.

11. Now all new connections should fail since both the servers are in "drainstop" mode.

12. Give nlb start.

13. Client should be able to connect to vpn-server1.

With Regards,

Anupam Chakraborty (SDET, Windows Networking)

SSTP support on Forefront TMG server

Hello Customers,

If you are wondering, when will Forefront based VPN server be available on Windows server 2008 – specifically when will Forefront VPN server support SSTP – which is  the VPN tunnel that was added in Windows server 2008/Vista SP1 that provides ubiquitous VPN connectivity across firewalls/NAT using HTTPS.

So here is the good news – Forefront team released Beta3 of new Forefront Threat Management Gateway (TMG).  This release of TMG has bunch of features including SSTP integration i.e. TMG based VPN server will now support SSTP based VPN tunnels. Please check-it out, test it out and provide your valuable feedback to us.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

What type of certificate to install on the VPN server

Hello Friends,

In my previous posting related to VPN tunnel selection, I discussed various scenarios in which you need to install a certificate on the VPN server. To summarize this requirement in a nutshell: except PPTP tunnel, for all the other tunnel types (i.e. IKEv2, SSTP and L2TP/IPSec) VPN server machine should be installed with a valid certificate. And what does valid means is what I am going to discuss in this blog.

Let us take a simple deployment scenario: You have one VPN server which is enabled for all VPN tunnels and is also used as NPS based Radius server – with EAP-TLS authentication.

Here are the steps you need to follow:

1) Install a certificate inside machine store (i.e. Local Computer certificate store) of the VPN server. The key properties that you MUST ensure are set inside the machine certificate includes:

• Common name (CN): Same as the hostname OR IPv4/v6 address that is configured as VPN destination on the VPN client. i.e. if the VPN client is configured with the hostname, then set this as same hostname OR if the VPN client is configured with the IP address, then set this as same IP address.
• Extended Key Usage (EKU):  Select “Server Authentication” and “IP Security IKE intermediate”.
• Key Usage: Select Digital signature and Key encipherment.

This certificate must be requested from the certificate authority (CA) – who trust chain is installed on the VPN client machine (see next step on special care if you are using public CA). The certificate can be requested from the CA using any mechanism that supports requesting above set of properties. For example, if you are using Active Directory Certificate Services – you can request a certificate by creating a “Custom request” by clicking on relevant certificate store inside Certificate Manager (certmgr.msc). And you can then submit the certificate request to the CA. And once the request is approved, you can install the machine certificate on the VPN Server.

2) Once the certificate is installed on the VPN server, you must configure the VPN server appropriately to point to the relevant machine certificate:

For SSTP: Ensure the SSTP tunnel is configured for this certificate. For Windows 2008 R2 – RRAS server has a UI/netsh way of selecting the certificate that will be used by SSTP – which is blogged here. For Windows 2008, there is a regkey driven way of ensuring the same which is blogged here and here.

For L2TP/IPSec: No other configuration is required

For IKEv2 EAP authentication: No other configuration is required

For IKEv2 machine certificate authentication: Ensure the trusted root certificate store on the VPN Server contains **only** the trust root certificate that matches the trust chain with which the client will send the machine certificate. And you MUST delete all the other trust chain on the VPN Server – to avoid any malicious client machine having a certificate with one of those trust chain to be able to successfully connect to this VPN server using IKEv2 machine certificate authentication. WARNING: If you have enabled IKEv2 machine certificate authentication scenario, you MUST NOT install any trusted root certificates from a public certificate authority (e.g. Verisign) on the VPN server machine. Otherwise, any malicious user  with a machine certificate from that particular public CA – can connect with your VPN server. You must only install the trusted root certificate of your own certificate authority.

Hope this posting helps you select the right certificate

For further details about the certificates, please refer to this excellent blog by Adrian.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Configuring RRAS based SSTP VPN server behind F5 BIGIP SSL load balancer

Hello All,

In this blog, I will discuss how to load balance SSTP based VPN servers using a F5 BIGIP SSL load balancer.

Lets look at the deployment scenario first: You are having a pool of RRAS based VPN servers hosted behind F5 BIGIP load balancer. The F5 BIGIP load balancer terminates the HTTPS connections coming in from different SSTP based VPN clients, load balances the same by sending HTTP connections to one of the VPN server from this  pool of RRAS based VPN servers.

I will walk-through a sample lab set-up, however you can modify the same according to your own deployment.

Configuring F5 BIGIP

1. Connect to F5 BIGIP management console web interface. Go to Local Traffic
2. SSL Certificates: Import the SSL certificate that will be used during HTTPS negotiation. Please note: the subject name (CN) of the certificate should be same as the VPN destination name as configured inside VPN client. This can be either hostname or IP address – depending upon the VPN client configuration. Also note: The thumbprint of this certificate will be configured inside RRAS server (under Sha1CertificateHash and Sha256CertificateHash registry keys as given in step 3 under Configuring RRAS as SSTP VPN server).
3. Profiles: Create two profiles: a) Name: SSTP_Http profile derived from the existing parent template `HTTP’.  This profile will be attached to the virtual server so that we can add an iRule to do HTTP filtering based on SSTP URI. b) Name: SSTP_Client profile derived from the existing parent template `ClientSSL’. This will be configured with the certificate imported in step 2 and will be used to terminate the HTTPS connections coming in from the client side.
4. Nodes: Create nodes specifying IP address of each of the VPN servers (i.e. RRAS server’s IP address facing towards BIGIP or Internet).
5. Pools: Create a pool with name SSTP-Pool that contains the node we created in step 4. Enter the name of the pool, add gateway_icmp health monitor, select the nodes and select the service port as 80 or any other value that is configured on SSTP based VPN server  to listen for incoming HTTP connections.
6. iRules:  This is the best part of F5 BIGIP – without doing any firmware code change, we were able to get SSTP VPN server getting load balanced – by creating  a new iRule with name: SSTP_iRule as given in the end of this article.
7. Virtual Server: Create a new Virtual server – name: SSTP_VirtualServer. Specify the destination IP address, service port as 443 (HTTPS), configuration as `Basic’. For HTTP profile – select SSTP_Http and SSL client profile – select SSTP_Client
8. Resources: Add the iRule created in step 6 – i.e. SSTP_iRule to the virtual server.

Configuring RRAS as SSTP VPN server

1. On WS 2008 or later OS, using Server Manager, install RRAS server role inside “Network Policy and Access server” node.
2. Once installed, configure RRAS server as VPN server – using RRAS configuration wizard (details given in SSTP step-by-step guide -  in references).
3. By default SSTP based VPN server is configured to listen for HTTPS connections coming in from VPN clients – however in this scenario it is required to be configured for accepting HTTP connections. To configure RRAS VPN server to listen for HTTP connections, configure UseHTTPS, ListenerPort, Sha1CertificateHash and Sha256CertificateHash registry keys (details given in KB947030 and KB947054). Basically – you need to specify UseHTTPS as 0 (i.e. listen for HTTP connections), ListenerPort as 80 or some other value on which you will like to listen on HTTP connections (the same MUST be set inside F5 pool), Sha1CertificateHash and Sha256CertificateHash with the thumbprint of the certificate installed on F5 BIGIP (which will be sent to the client during HTTPS connection establishment phase).
4. Once you have set the regkeys, restart RRAS server.
5. Follow the same steps on all the RRAS servers hosted behind F5 BIGIP (i.e. for all the nodes created on BIGIP).
6. And you are all set-to-go and test the stuff.

Testing

1. Create a SSTP VPN client on Vista SP1 or later OS – give the destination name as the name/IP address of F5 BIGIP virtual server. Note: This must be same as the subject name of SSL certificate installed on the F5 BIGIP SSL certificate.
2. Install the trusted root certificate on the client machine
3. Click connect. The HTTPS connection must go through F5 BIGIP virtual server terminating HTTPS connection and redirecting HTTP connection to one of the RRAS server.
4. For further troubleshooting, look at F5 logs and RRAS event logs.

References

1. Step-by-step guide: Deploying SSTP Remote Access
2. KB947030: How to deploy SSTP based VPN server behind SSL load balancer
3. KB947054: Registry entries that RRAS adds in WS08
4. Here is the iRule with name SSTP_iRule that must be created on F5 BIGIP to redirect SSTP client connections to a pool of VPN servers:

##################################

when HTTP_REQUEST {

log local0. "HTTP Method: [HTTP::method]"

log local0. "HTTP URI: [HTTP::uri]"

log local0. "HTTP Host: [HTTP::host]"

log local0. "Content Length: [HTTP::header Content-Length]"

if { ([HTTP::method] eq "SSTP_DUPLEX_POST") and

([HTTP::uri] eq "/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/") } {

log local0. "Found SSTP Request, routing to sstp_servers pool"

pool SSTP-Pool

# disable the HTTP profile for the rest of the connection

HTTP::disable

} else {

log local0. "Non SSTP Request, dropping connection. You can change it according to your use"

drop

}

}

##################################

Cheers,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Windows7 PPPoE or VPN connectivity experience – we would like to hear back from you

Hello Friends,

As you know – Windows7 RC is out and we will like to hear back from you !

In Windows7, we did couple of changes on the remote access client that includes dialup, broadband (aka PPPoE) and VPN scenarios. Windows7 brings in simpler connectivity experience inside View Available Networks (VAN) that is shown in networking system tray icon.

In Windows7 beta release, we heard from you on some PPPoE connectivity issues in certain regions and some PPPoE performance issues. We actively listened to your valuable feedback and quickly acted on it. We have fixed all of those issues in Windows7 RC release.

If you are using Windows7 RC build and still facing any connectivity or performance issues in  dialup, PPPoE or VPN area, please get back to us by sending us an email (click on the Email link above).

We sincerely appreciate your feedback.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Enhancements to VPN Reconnect in W7 RC

Hello Folks,

By now all of you must have heard about the formal release of W7 RC. In case you don’t have it already here is the link from where you can download the RC bits

http://www.microsoft.com/windows/windows-7/default.aspx

In RC the RAS team has made some enhancements to the VPN Reconnect feature. Here are the details of the change and some recommendations on deployment.

1.       Change in method used to calculate MSK

Details of Enhancement

In accordance with the IKEv2 RFC, in EAP  authentication, the shared secret generated is used by the IKEv2 connection initiator and responder to generate AUTH payloads  for EAP (see section 2.16 in RFC 4306 for more details). This shared secret is called the MSK.

In W7 RC we have changed the method used to calculate the MSK for EAP-MSCHAPv2 . The new method has been documented on MSDN and can be found at http://msdn.microsoft.com/en-us/library/cc224635(PROT.13).aspx

Impact

The MSK calculation method used in RC is different from that in Beta and implementation of the new method involved changes on both the client and server. Hence RC build is required on both client and server to successfully setup an IKEv2 connection using EAP-MSCHAPv2 authentication. IKEv2 connections between Beta client and RC server and vice versa will fail if EAP-MSCHAPv2 authentication is used

Vendors implementing EAP-MACHAPv2 for IKEv2 MUST derive the MSK as specified in http://msdn.microsoft.com/en-us/library/cc224635(PROT.13).aspx

2.       Validation of VPN server machine certificate by client for better security

Details of Enhancement

We have made a change to IKEv2 on the client side to start validating the machine certificate sent by the VPN server that it is connecting to. This change helps prevent possible MITM and dictionary attacks thereby strengthening IKEv2 security. It is not possible to disable these checks on the client

Deployment Recommendation

·        Certificate installed on the server should have the following values for certain important fields in the certificate. Corresponding root certificates should be installed on the client

     -         Certificate Name (CN): This field should contain the name or IP address of the server (depending on which one is being used by the client) that is  

           being validated by the client.

     -          EKU: Should be a ‘Server Authentication’ certificate. If there are multiple certificates present in the machine store of the server then additionally

           specifying ‘IP security IKE intermediate’ (OID: 1.3.6.1.5.5.8.2.2) in the EKU of the cert will ensure that the cert is picked over other certificates in the

           store. The latter is highly recommended

·         If you are running SSTP already in your setup then the same server machine certificate can be used for both SSTP and IKEv2 but the certificate should satisfy the criteria mentioned above. Since root certs required for SSTP are already present on the client no client side changes are needed in this case

Impact/Troubleshooting Tips

If right certificate is not configured on IKEv2 server or if correct trusted root certificate is not present on the client then IKEv2 connections might fail. Error code seen

is 13801 which indicates that validation of the server certificate is failing. If multi-tunnel VPN strategy is used, then a fall back to the next tunnel will happen and the

VPN connection will go through. For e.g. for ‘Automatic’ tunnel type fall back will happen to SSTP

VPN Client Compatibility with Windows 7 and Windows Server 2008 R2

When you upgrade your computer from an older version of Windows to Windows® 7 or Windows Server® 2008 R2, your 3rd-party virtual private network (VPN) client programs might not work. As Windows evolves, sometimes changes to the underlying infrastructure are required to implement new features, and these changes can sometime break compatibility with older programs. While Microsoft makes every effort to maintain compatibility with older programs, there are some categories of programs that are more likely to be impacted by these changes. VPN clients are one of them.

The tables below show the VPN clients available from different vendors. The tables include the minimum version number that has been tested and known to be compatible with Windows 7 and a link to the vendor’s Web site where you can download the client.

Be sure to review the More information column for any important notes that might be relevant to your use of the client.

Notes

·      Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

·      The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

·      AT&T

·      Checkpoint

·      CISCO

·      Citrix

·      F5

·      Juniper

·      NCP

·      NetGear

·      Nortel

·      SafeNet

·      Sonic Wall

Ashish Jain

Program Manager

Routing and Remote Access

AT&T

Checkpoint

CISCO

Citrix

F5

Juniper

NCP

NetGear

NetGear’s native VPN client is not supported on Windows 7. Instead, the following routers have been tested and work with the Windows 7 native VPN client.

Nortel

SafeNet

The existing SoftRemote version of the SafeNet VPN client is not supported on either 32-bit or 64-bit versions of Windows 7. The IPsec Toolkit version named QuickSec, is supported on Windows 7. 

Sonic Wall

Issues, Resolutions, and Status

The following table contains a list of issues identified during application compatibility testing with the respective resolution or status.

Smart Defaults for VPN Strategy and Authentication Protocol in CMAK

For detail description on the order in which tunnels are tried for every VPN strategy and deployment recommendations for managing mixed client and server OS version scenarios refer to this comprehensive blog written by Samir

Aanand Ramachandran

Program Manager, RRAS

Remote Access Deployment – Part 3: Configuring RADIUS Server for remote access

Hello Customers,

In this post, I will go through the steps to configure to deploy Network Policy Server (NPS) based RADIUS server to authenticate and authorize the remote access connections coming from RRAS based VPN server. I will try to go through different policy parameters in order to point you to various important policy options in NPS server role. However for your deployment, you may be adding/deleting more these depending upon your requirements.

Radius server is used to perform AAA i.e. authentication, authorization and accounting of the remote access user. This post gives details on Network Policy server (NPS) role acting as RADIUS server – installed on a different machine from the one running RRAS server.

3.1 Installation of server role

Let us try to configure NPS server role as a RADIUS server on a Windows server 2008 R2 machine. To do that, you need to first install the NPS server role:

• Open “Server Manager”. Click on “Roles”, “Add Roles”. Click “Next”. Select “Network Policy and Access Services”. Click on “Network Policy Server. Click “Next” to install the same.

3.2 Configuration of Radius server

To configure NPS based Radius server to authenticate VPN based remote access connection, follow these steps:

• Open Network Policy Server MMC by clicking on “Start”->”All Programs”->”Administrative Tools”->”Network Policy Server”. This launches the NPS MMC snap-in.
• Click on left pane - “RADIUS Client and Servers”. Click on “RADIUS Client”. This is used to configure the information of RADIUS clients (i.e. RRAS based VPN server in this scenario) that sends authentication and accounting request to this radius server. Right click “New” to create a new entry and enter the RADIUS client information (i.e. IP address and shared secret of the RADIUS client machine i.e. RRAS server machine).

Note: This needs to be configured only if the RADIUS Client and NPS server are running on separate machines.

• Click on “Remote RADIUS Server Group”. This is used when this machine is running as a RADIUS PROXY - configure the information about the RADIUS server to which this machine will forward authentication and accounting requests.

For this example scenario where RADIUS server is authentication the connection locally, skip this configuration.

• Click on “Policies”, then click on “Connection Request Policies”. CRP allows you to designate whether connection requests are processed locally or forward to remote RADIUS server group.

Right click New – to create a new CRP. The specific fields in Connection Request policy of interest are: -

• “Type of network access server” - set it to “Remote Access Server (VPN-Dial up)”
• “Forwarding Connection Request” Authentication – Select “Authenticate requests on this server” if you are authenticating request locally. OR select “Forward requests to the following remote RADIUS Server group – if getting forwarded” if you this machine is acting as RADIUS proxy and forwarding the request to some other machine running RADIUS server.

For this example scenario where RADIUS server is authentication the connection locally, select “Authenticate requests on this server”.

• “Authentication Methods” – this can be set at the CRP level or at the network policy level. If set at CRP level – this will override the authentication setting at the individual policy level.

For this example scenario, let the authentication methods be set at the policy level.

• Click on “Policies” node, then click on ”Network Policies” node. Network policies allow you to designate who is authorized to connect to the network and the circumstance under which they can or cannot connect.

Right click New – to create a new network policy. A network access policy has different fields, however some of the common fields are given below: -

Note: The mandatory ones that are required for remote access connection to pass through are highlighted in bold: -

• Overview:
• “Type of network access server” - set it to “Remote Access Server (VPN-Dial up)” – to specify the type of Radius client which can match this policy.
• “Access Permission” – should be set to “Grant access” – to specify the access permission if conditions and constraints of the policy match against the connection request.
• Condition: If ALL the conditions match against the connection request, NPS uses this policy to authorize the connection request, else skips this policy and evaluates other policies (if configured)
• “Operating System” – specifies the OS for remote access client computer to match this policy
• “Windows Groups” – This condition specifies the remote access user’s group inside Active directory.
• Constraints: If ALL the constraints are not matched by the connection request, the network access is denied for the connection.
• “Authentication Methods” – select access **only** to those remote access clients that authenticate with specific authentication protocols

Note: This list MUST match the authentication methods configured inside RRAS server.

• “Day and time restrictions” – Allow access to remote access users **only** on these days and at these times
• Settings: If conditions and constraints match the connection request and the policy grants access, then the settings are applied on top of the connection.
• “Idle Timeout” – specify the maximum time to remain idle before connection is disconnected.
• “IP Filters” – To be applied to the VPN connection to restrict the remote access user to specify IP addresses.
• “NAP Enforcement” – specify whether you want to enforce NAP for this policy. Note: This will require additional configuration as highlighted in this step-by-step guide.
• Click on “Accounting” – to select your preference on the logging store for the accounting data –SQL or a file.

References: For further details on Radius configuration, please refer to this article. For further details on remote access policy configuration, please refer to this document.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Remote Access Deployment – Part 2: Configuring RRAS as a VPN server

Hello Customers,

In this post, I will go through the steps to configure to deploy RRAS as a VPN server. I will try to go through different configuration scenarios in order to point you to various configuration options in RRAS server role. However for your deployment, you may be skipping some of those – depending upon your requirements.

Terminology: RRAS Internal Interface is the interface representing all remote access devices (all VPN/dial-up clients are part of this interface).

Lets go through the different steps: -

2.1 Installation of server role

Let us try to configure RRAS server role as a VPN server on a Windows server 2008 R2 machine. To do that, you need to first install the RRAS server role:

• Open “Server Manager”. Click on “Roles”, “Add Roles”. Click “Next”. Select “Network Policy and Access Services”. Click on “Routing and Remote Access Service” and the underlying checkboxes. If you want to install NPS based radius server on the same machine as RRAS server, select the same too. Click “Next” to install the same.

2.2 Configuring for VPN server

Once the server role is installed, you need to configure the same to provision the server role as a VPN server. To do the same, follow these steps:

• Open Routing and Remote Access MMC snap-in by clicking on “Start”->”All Programs”->”Administrative Tools”->”Routing And Remote Access”. This launches the RRAS MMC snap-in.
• Right Click on the left pane – on the machine name (below “Server Status”) and select “Configure and Enable Routing and Remote Access”. Click “Next”.
• Select “Remote access (dial-up or VPN)”. Click “Next”.
• Select “VPN”. Click “Next”.
• Select the network interface card (NIC) connected towards the Internet. This is your public interface. And automatically the other interfaces are considered as private interface by RRAS.

If you plan to deploy RRAS serve directly connected to Internet and want to enable RRAS packet filters to allow **only VPN traffic** to be accepted from Internet side, click on “Enable security on the selected interface by setting up static packet filters”.

WARNING: If you are running other server roles (e.g. terminal server) on the same machine that needs access from the Internet side, you need to MANUALLY go and add those filters to allow access to those server roles. Otherwise, the RRAS packet filters will drop those packets.

Click “Next”

• On the “IP Address Assignment” page, select the mechanism by which you will like to assign the IPv4 addresses to the remote access clients (i.e. client’s inner IP address – through which they access the machines sitting on private interface of RRAS).

By default, “Automatically” is set on. This mandates a need for DHCP server to be sitting on the private interface of RRAS. In this scenario, RRAS server obtains IP addresses on behalf of remote access clients using DHCP protocol and then assigns these addresses to the VPN clients when they connect in. Click “Next” to continue.

If you will like to specify the IP address from a static pool, select “From a specified range of addresses”. And select “Next”. In the next page, select “New” and you can enter the Address range (e.g. 192.168.1.1 to 192.168.1.10). Click “Next” to continue.

• You will see “Managing Multiple Remote Access Servers” page. Here you can select how you want to authenticate the remote access clients. There are two options here:
  • “No, use Routing and Remote Access to authenticate connection requests”. Select this option, if you will like to use Windows based authentication. This mechanism will require your remote access server machine to be joined to domain if you will like to authenticate the remote access users using domain credentials.

WARNING: It is not recommended for edge machines to be joined to domain – in order to restrict the security foot-print of a DMZ machine.

If you will like to authenticate the remote access users using work-group credentials – then RRAS server need not be joined to domain.

• “Yes, set up this server to work with a RADIUS server”. Select this option, if you will like to use Radius based authentication. In this scenario there are two options: RADIUS server installed on some other machine or on the RRAS server machine.

WARNING: If Radius server is installed on the same machine, then same restriction of machine to be joined to domain exists in order to authenticate remote access users using domain credentials. And it makes an edge machine joined to domain.

Hence the recommended deployment scenario is RADIUS server installed on some other machine sitting on private interface of RRAS server. And that machine is joined to domain, however RRAS server is a non-domain joined machine.

Select “Yes, set-up this server to work with a RADIUS server”. Click “Next”.

The next page is “RADIUS Server Selection” where you can enter the IP address of Primary and alternate RADIUS server (if any) and the shared secret.

NOTE: The same shared secret must be configured on the RADIUS server as the secret of the RADIUS client (i.e. VPN server in this scenario).

• Click “Finish” to finish installation of remote access role.

If using Windows authentication OR Radius server (i.e. NPS) is installed on the same machine as RRAS server, a pop-up comes which specifies that a default remote access policy named “Microsoft Routing and Remote Access server” is created. Click OK.

Additionally in this scenario, you need change the “Access Permission” inside network policy from “Deny access” to “Grant access”. To do this, follow these steps:

• Click on Routing and Remote Access MMC. Click on “Remote Access Logging and Policies”. Right Click and select “Launch NPS”. This will launch NPS MMC (a minimal one though. A full one can be launched by opening nps.msc at the command prompt).
• Double click on the relevant Policy. Click on “Overview” tab and change the “Access Permission” to “Grant Access”.

2.3 IPv4 or IPv6 based remote access server

• If not already launched, open Routing and Remote Access MMC snap-in by clicking on “Start”->”All Programs”->”Administrative Tools”->”Routing And Remote Access”. This launches the RRAS MMC snap-in.
• Right Click on the left pane – on the machine name (below “Server Status”) and select “Properties”. This will open up the property page.
• Click on “General” tab to select at top level how you will like to deploy this RRAS server. For example:
  • To enable RRAS server to forward IPv4 packets to/from remote access clients, enable “IPv4 Remote access server”.
  • To enable RRAS server to forward IPv6 packets to/from remote access clients, enable “IPv6 Remote access server”.
  • To enable RRAS server to forward IPv4 packets while acting as a site-to-site router, enable “IPv4 Router” and “LAN and demand-dial routing”.
  • To enable RRAS server to forward IPv6 packets while acting as a site-to-site router, enable “IPv6 Router” and “LAN and demand-dial routing”.
• Click on IPv4 tab to change IPv4 transport related configuration:
  • “Enable IPv4 Forwarding” should be checked on – to ensure IPv4 packets can be forwarded between remote access client and rest of intranet resources. This check-box should be turned off – only if remote access users need to access the remote access server (e.g. you have some other server roles like IIS installed on remote access server machine and you will like to give your user access to only those server roles and not any other machines).
  • You can change the “IPv4 address assignment” between a “static address pool” and “DHCP”. This address pool will be used to assign one IP address to remote access client during VPN tunnel establishment phase.
  • If you will like to forward NETBIOS based name resolution queries coming from remote access clients to intranet (or private network behind RRAS server), click on “Enable broadcast name resolution”.
  • If you have multiple NICs as private interface on RRAS server, you need to select the NIC which will be used by RRAS server to read the DHCP server, DNS server and WINS server addresses. The DHCP server address will be used to build the IP address pool if “IPv4 address assignment” is DHCP. The DNS server and WINS server address will be passed to remote access clients during VPN tunnel establishment phase. These addresses will be used by remote access client to do the name resolution for intranet resources.
• Click on IPv6 tab to change IPv6 transport related configuration:
  • “Enable IPv6 Forwarding” should be checked on – to ensure IPv6 packets can be forwarded between remote access client and rest of intranet resources. This check-box should be turned off – only if remote access users need to access the remote access server (e.g. you have some other server roles like IIS installed on remote access server machine and you will like to give your user access to only those server roles and not any other machines).
  • “Enable Default Route Advertisement” should be checked on – if you will like to make this RRAS server as the default IPv6 gateway for the remote access clients (i.e. turning split-tunneling off for the IPv6 transport in the remote access client)

Note: This check-box is not available on IPv4 tab – because in case of IPv4 the remote access client’s VPN configuration is the ONLY configuration that governs whether it has default IPv4 gateway towards VPN server or not (i.e. whether split-tunneling is turned on or off). However IPv6 is a special case because IPv6 protocol allows IPv6 router advertisement capability by which VPN server can advertise to VPN clients to become a default. If it does AND the remote access client’s VPN configuration allows that, then only default IPv6 gateway will be set with highest precedence (or lowest metric) on the VPN interface.

• “IPv6 Prefix assignment” will be used to enter a /64 bit IPv6 prefix – which will be sent to the remote access clients. For example, 3000:1:2:3:

Note: The remote access clients share the same /64 bit IPv6 prefix – with 64 bit interface-id (i.e. lower 64 bit of IPv6 address) being different for each client.

• If you have multiple NICs as private interface on RRAS server, you need to select the NIC which will be used by RRAS server to read the DNS server’s IPv6 address. This parameter is ONLY used for IKEv2 based VPN connection – to relay DNS server IPv6 address to the remote access clients during IKEv2 VPN tunnel establishment phase. This address will be used by remote access client to do the name resolution for intranet resources.

Note: The DNS server IPv6 address for rest of the PPP based VPN tunnels (i.e. PPTP, L2TP and SSTP) are not configured on the RRAS server directly. For this scenario to work, RRAS server is configured as a DHCPv6 Relay agent with RRAS Internal interface (i.e. virtual interface representing the remote access clients) and private interface facing a DHCPv6 stateless server. The DHCPv6 stateless server is configured with the DNS server IPv6 address. During VPN tunnel establishment phase, remote access client sends a DHCPv6 inform request packet – to get DNS server IPv6 address. This packet is sent over VPN tunnel to RRAS server who then relays the same to DHCPv6 stateless server. A DHCPv6 Inform reply is sent in reverse path containing the IPv6 address of the DNS server.

2.4 NAT support

RRAS server can be configured as a NAT router for two main scenarios – a) between machines sitting on LAN (i.e. private interface of RRAS) and Internet b) between remote access user machines and Internet.

To configure RRAS server as a NAT router (address port translation): -

• Open Routing and Remote Access MMC snap-in by clicking on “Start”->”All Programs”->”Administrative Tools”->”Routing And Remote Access”. This launches the RRAS MMC snap-in.
• Click on the left pane – on the machine name (below “Server Status”) and select “IPv4” and “General”. Right click and select “New Routing Protocol” and select “NAT”.
• Select on “NAT” node under “IPv4”. Right click and select “New Interface”.

Select your interface facing internet and in the next page select the “Public interface connected to the Internet” and click to “Enable NAT on this interface”.

Select your interface facing private side (can be RAS Internal interface or other private NIC of RAS). And in the next page select the “Private interface connected to private network”.

2.5 DHCP Relay Agent

RRAS server can be configured as a DHCP Relay Agent for two main scenarios –

• Between remote access clients and DHCP server when RRAS server is acting as a VPN server. In this scenario, the relay agent is used to forward DHCP inform packets between VPN client and DHCP server – to obtain information like DNS server address, IP routes.
• Between LAN clients and DHCP server when RRAS server is acting as a LAN router. In this scenario, the relay agent is used to forward all DHCP packets – to obtain IP address and extended information.

DHCP relay agent is configured for IPv4 or IPv6 – depending upon the transport configured on DHCP client machine. Or in other words, if remote access client is configured to obtain IPv4 address from VPN server, then you need to configure DHCPv4 relay agent on RRAS server. And same way, if remote access client is configured to obtain IPv6 prefix from VPN server, then you need to configure DHCPv6 relay agent on RRAS server.

Note: DHCPv6 Relay Agent MUST be installed on RRAS server to support IPv6 remote access server scenario for all PPP based VPN tunnels (i.e. PPTP, L2TP and SSTP). This is required because the DNS server IPv6 address can be relayed to the VPN client only via the DHCPv6 Inform mechanism and not via PPP IPv6 Configuration Protocol stage. However the DHCPv4 Relay Agent is optional because DNS server address can be relayed to VPN client via PPP IPCP stage. The DHCPv6 Relay is optional for IKEv2 VPN tunnel because DNS server IPV6 address can be relayed to the VPN client using IKEv2 configuration payload stage.

To configure RRAS server as a DHCPv4 Relay Agent: -

• If not already launched, open Routing and Remote Access MMC snap-in by clicking on “Start”->”All Programs”->”Administrative Tools”->”Routing And Remote Access”. This launches the RRAS MMC snap-in.
• Click on the left pane – on the machine name (below “Server Status”) and select “IPv4” and “General”. Right click and select “New Routing Protocol” and select “DHCP Relay Agent”.
• Select on “DHCP Relay Agent” node under “IPv4”. Right click and select “New Interface”.

Select your interface facing DHCP server and in the next page configure the DHCP relay agent parameters.

Repeat the same steps to select your interface facing remote access client (e.g. Internal) and in the next page configure the DHCP relay agent parameters.

• Select on “DHCP Relay Agent” node under “IPv4”. Right click and select “Properties”. Enter the IPv4 address of the DHCP server – to which to relay the requests.

To configure RRAS server as a DHCPv6 Relay Agent: -

• If not already launched, open Routing and Remote Access MMC snap-in by clicking on “Start”->”All Programs”->”Administrative Tools”->”Routing And Remote Access”. This launches the RRAS MMC snap-in.
• Click on the left pane – on the machine name (below “Server Status”) and select “IPv6” and “General”. Right click and select “New Routing Protocol” and select “DHCPv6 Relay Agent”.
• Select on “DHCPv6 Relay Agent” node under “IPv6”. Right click and select “New Interface”.

Select your interface facing DHCP server and in the next page configure the DHCP relay agent parameters.

Repeat the same steps to select your interface facing remote access client (e.g. Internal) and in the next page configure the DHCP relay agent parameters.

• Select on “DHCPv6 Relay Agent” node under “IPv6”. Right click and select “Properties”. Enter the IPv6 address of the DHCP server – to which to relay the requests.

2.6 Packet Filtering

RRAS server can be configured to enable stateless packet filtering on any interface (LAN as well as Internal interface) using source IP address, destination IP address, IP protocol type, source and destination port number (for IP protocol type as TCP/UDP). These filters can be set for IPv4 as well as IPv6 packets.

To enable RRAS packet filtering on LAN interface (e.g. accept only VPN packets on public interface), please follow these steps:

• If not already launched, open Routing and Remote Access MMC snap-in by clicking on “Start”->”All Programs”->”Administrative Tools”->”Routing And Remote Access”. This launches the RRAS MMC snap-in.
• Click on the left pane – on the machine name (below “Server Status”) and select “IPv4” and “General”. Select the appropriate LAN interface on the right side. And right click and select “Properties”.
• Select the “Inbound Filters” to add the filters on the IPv4 packets coming into the interface and “Outbound Filters” to add the filters on the IPv4 packets going out of the interface. On clicking the same, you can select the filter action (e.g. the incoming side filter action is “drop all packets except those that match the criteria below”) and click “New” to add the filter.
• Similarly you can add the filters on IPv6 packets.

SECURITY NOTE: It is strongly recommended to allow specific filters on the public interface of RRAS and drop the rest. This filter set should match all the server roles running on RRAS server and accessible from Internet side (e.g. VPN service). Additionally, the IP address in the filter must be set correctly i.e. destination IP address MUST match the IP address of RRAS server public interface on the inbound filters and source IP address in packet MUST match the IP address of RRAS server public interface on the outbound filters. If you don’t put IP addresses explicitly, there is a risk of IP packets getting forwarded across RRAS server not meant for services running on RRAS server.

To enable RRAS packet filtering on VPN interface (i.e. filters packets coming in from remote access clients or going to remote access clients), please follow these steps:

• Open the remote access network policy inside Radius server, go under the “Settings” tab and, click on “IP Filters” and then add the IPv4 and IPv6 inbound/outbound filters. This filter set will be passed to RRAS server during authentication stage and is applied on top of the internal interface corresponding to the specific authenticated VPN client. Note: The IP address given in this filter set represents the IP address of intranet machines (or machines behind RRAS server).

Note: NAP based health check also requires IP filters to be configured to restrict unhealthy client machines to a quarantine zone. However this quarantine filter set is configured as a “Remediation Server Group” and not as “IP filters” attribute inside the policy “Settings” tab. This is because filters specified as remediation server group is added on RRAS server when the remote access client is unhealthy and removed when the client becomes healthy. However the filters specified as IP filters is added on RRAS server when the remote client is healthy for the NAP scenario and for non-NAP scenario when the remote client is authenticated.

2.7 Tunnel Specific

Most of the configuration on RRAS server side is common for different types of VPN tunnels (i.e. PPTP, L2TP, SSTP and IKEv2), however there are few configuration that varies according to the tunnel. Let us take a look at some of these: -

• Number of devices: A device is a software interface through which the remote access clients connect to VPN server. There is limited number of concurrent devices that is supported by different editions of Windows server – the details given here. Based upon your remote access user profile (mainly OS), you may have configured different VPN tunnels on the RRAS servers. You can thereby restrict number of ports for that particular tunnel type by changing the Ports configuration. Open RRAS MMC snap-in, click on the left pane – on the machine name (below “Server Status”) and select “Ports” node. Right click and select “Properties” and then select appropriate tunnel type and click “Configure” – to set the maximum number of concurrent ports supported by a given tunnel. This way you can divide your pool of concurrent VPN devices in a systematic manner between different tunnel types – hence the specific profile of remote access user.
• Machine certificate configuration: L2TP/IPSec, SSTP and IKEv2 tunnels require a machine certificate to be installed on the RRAS server. This machine certificate should have following properties: EKU as Server Authentication, Subject Name same as the hostname OR IP address configured inside VPN client configuration and part of Trusted Root Chain that is also present on the VPN client machine. The same certificate can be used for all the tunnel types.

This certificate must be installed inside the local machine certificate store – under “Personal”. For L2TP/IPSec and IKEv2 – no other extra configuration is required in order to communicate the certificate pointer to RRAS. However for SSTP tunnel configuration, it is recommended to cross-check that the appropriate certificate is pointed by SSL Certificate Binding found here: Open RRAS MMC snap-in, click on server name, right click and select “Properties” and click on “Security” tab.

• Authentication Methods/Protocols: All the VPN tunnels support EAP based authentication protocols. However PPTP & SSTP additionally supports MSCHAPv2, L2TP/IPSec additionally supports MSCHAPv2 and machine certificate based authentication, IKEv2 additionally supports machine certificate based authentication.

The set of allowed authentication methods are configured at two locations: One inside the Radius policy (as given above). And secondly, RRAS server MUST be configured to accept the appropriate authentication methods. This is done by following these steps: Open RRAS MMC snap-in, click on server name, right click and select “Properties” and click on “Security” tab. Click on “Authentication Methods” and select the appropriate authentication protocols accepted by RRAS server.

• IKEv2 specific: Certain IKEv2 specific configuration like “Network Outage Time”, “Security Association Expiration Time”, “Security Association data size limit” – can be configured by following these steps: Open RRAS MMC snap-in, click on server name, right click and select “Properties” and click on “IKEv2” tab.
• PPP specific (holds true for PPTP, L2TP and SSTP): Certain PPP specific configuration like “software compression” can be configured by following these steps: Open RRAS MMC snap-in, click on server name, right click and select “Properties” and click on “PPP” tab.

References: For further details on SSTP configuration, please refer to this step-by-step guide.

References: For further details on IKEv2 configuration, please refer to this step-by-step guide.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Remote Access Deployment – Part 1: Configuring Remote Access Clients

Hello Customers,

In my last few articles, I discussed about the design guidelines to consider before deploying  a remote access solution.

In the next few articles, I will go through the steps to configure the various components  of the remote access solution. These articles will act as your jump-start guide to quickly build a solution in your pilot lab, test various combinations and then finally roll-it-out in your production environment.

All the steps given below are done on my Windows 7 client beta and Windows server 2008 R2 server beta. If you have other flavour of Windows (like Vista, XP, 2008), you may have to change few steps here and there. Hope you find it useful. 

Here is the first topic on this:  Configuring the remote access clients

1.1 In-built VPN client

To create a VPN client using in-built VPN client, please follow these steps:

• Open “Control Panel” -> “Network and Sharing Center”. Click on “Set up new connection or network”. This launches a wizard
• Click “Connect to a workplace”, click “Next”, click “Next”, double click on “Use my Internet connection (VPN)”, enter the hostname or IPv4/IPv6 address of the VPN server and specify the VPN connection name (as seen in network tray icon), click next, then enter username/password for the connection, click connect. This will try to connect.
• The above steps will create a VPN client and tries to establish the VPN connection to the server. If that fails for any reason, select “Set-up the connection anyway” – so that configuration is saved.

To change the properties of VPN client created using in-built VPN client, please follow these steps:

• Click on networking tray – on bottom right side of your desktop. Move the mouse on the appropriate VPN connection name, right-click and select Properties. This launches VPN connection Properties UI. This UI has four tabs – “General”, “Options”, “Security” and “Networking”.
• “General” tab is used to change the VPN server hostname or IP address. Additionally underlying interface (like dial-up or broadband) to connect to public network can be configured – so that when user clicks on “connect” on VPN interface, it will first try to get underlying interface up (if not already) and then establish a VPN connection on top of it.
• “Options” tab is used to configure some general connectivity options like redial attempts, idle disconnect time, etc
• “Security” tab is used to configure the authentication and VPN tunnel options. By default the in-built VPN client is created with “Type of VPN” tunnel as Automatic (i.e. tunnel order is - try IKEv2 first, if that fails try SSTP, if that fails try PPTP, if that fails try L2TP). However “Type of VPN” can be changed to try specific VPN tunnel. “Advanced settings” button is used for L2TP/IPSec and IKEv2 tunnel type. Various authentication protocols can be configured under “Authentication” heading. To configure EAP based protocols, select the radio button “Use Extensible Authentication Protocol (EAP)” and then select the relevant EAP methods. If you select “Microsoft Protected EAP (PEAP)” to select other configuration like inner EAP method that gets tunneled inside PEAP TLS session and common configuration like “Enforce Network Access Protection”. If you select EAP-MSCHAPv2, you can optionally configure VPN client to pick-up username/password that was entered during Windows login time – avoiding the user to re-enter the credentials when dialing the VPN connection. This is the most commonly deployed scenario.
• “Networking” tab is used to configure the transports (or protocols) that run on top of VPN tunnel. The most common ones are “Internet Protocol Version 4 (TCP/IPv4)” and “Internet Protocol Version 6 (TCP/IPv6)”. Select a particular transport, click on “Properties” to change common fields like default gateway, DNS server address, DNS suffix for the connection etc. If “User default gateway on remote network” is turned on, the VPN client on successful VPN tunnel connection adds the default route on VPN interface with highest precedence. This way all the IP packets (except those destined to local subnet) go to VPN server. If this parameter is turned off, the default route is not added on VPN tunnel. This scenario will require user to add specific network specific route on the VPN interface – in order to reach the corpnet resources.

To connect/disconnect the VPN connection, please follow these steps:

• Click on networking tray – on bottom right side of your desktop. Move the mouse on the appropriate VPN connection name, right-click and select “Connect” (if already disconnected) and select “Disconnect” if already connected).

To view the status and statistics of the VPN connection, please follow these steps:

• Click on networking tray – on bottom right side of your desktop. Move the mouse on the appropriate VPN connection name, right-click and select “Status” (if already connected).

This will launch the VPN connection status UI – where you can find the IP address of the client (inner and outer IP address), IP address of the server, bytes sent/received on the connection.

1.2 CM based VPN client

To create a CM client package as a network administrator, you first need to install “Connection Manager Administration Kit” (CMAK) tool on a Windows 2008 R2 server machine and then run the tool to create a CM package. This is done by following these steps: -

• Open “Server Manager”. Click on “Features”, “Add Features”. Select “Connect Manager Administration Kit”, Click “Next” and install the same.
• Open CMAK by clicking on “Start”->”All Programs”->”Administrative Tools”->”Connection Manager Administration Kit”. This launches the CMAK wizard
• Click “Next”. Select the target OS (i.e. OS of the client machine on which the CM based VPN client will be eventually installed). Note: CM package for Vista and Windows 7 is same. Click “Next”. Select “New profile”. Click “Next”.
• Enter the name of the VPN connection (e.g. “Contoso VPN connection”) and the filename of CM profile or package (e.g. contoso). Click “Next”. Click “Next” to skip the realm name. Click “Next” to skip merging of VPN profiles.
• In the page titled “Add support for VPN connections”, click “Phone book from this profile”. You can then specify the VPN server name or IP address – if there is only one VPN server or cluster of server to which the VPN client connects. However to support scenarios where you have deployed VPN servers at different locations of your corporation (like in different countries), you can specify a list of VPN servers in a .txt file. This text file has a list of VPN servers each tagged with a friendly display name (e.g. Contoso India, Contoso US, etc) – that helps end user to connect to appropriate VPN server. A sample file format looks like:

[Settings]

Message=Select the location closest to your office.

[VPN Servers]

Contoso India=vpnserver.contoso.in

Contoso USA=1.2.3.4

Click “Next”

• You will see “Create or Modify a VPN Entry” page with a default VPN entry created. To edit the connection properties, click “Edit”. You will see “Edit VPN Entry” UI through which you can change the connection properties like tunnel and authentication protocol selection, IPv4 and IPv6 properties, DNS suffix etc.

Once done, click “OK” to come back to previous page. Click “Next”

• For dial-up access you can specify a phone book file. Turn off the “Automatically download phone book updates” checkbox. Click “Next”.
• You will see “Specify Routing Table Updates” page. Here you can add a list of routing table entries in form of a text file that can be added on the client side after the VPN connection comes up. This is used when you turn off the “Make this connection the client’s default gateway” in “Create or Modify a VPN Entry” page and enable split-tunneling. In this scenario, you can enter the IP routes of all the subnets/host machines inside your corporate network that can be accessed by the client. The format of the text file is each line containing a route preceded by a command (ADD or DELETE)

Command Destination MASK Netmask Gateway METRIC Metric IF Interface

For example:

ADD 192.168.1.0 MASK 255.255.255.0 192.168.2.1 METRIC default IF default

Click “Next”

• You will see “Configure Proxy Settings for Internet Explorer”. Here you can add the intranet web proxy settings that will be used after the VPN connection comes up. Click “Next” for default one (i.e. no web proxy configured or required to access the intranet web resources i.e. direct web access without going through proxy).
• You will see “Add Custom Actions” page – where you can add different custom actions by running specific program on specific action. A sample custom action can be – after VPN connection is established (i.e. “post-connect”), download a new CM package file by doing net use to a file server. For more details see link below. Click “Next” to select default one (no actions).
• You can then add a specific bitmap file (.bmp) to display your connection manager package – at the logon time as well as phone book dialog box. Click Next. Click “Next” to select the default one.
• You can then add specific icon file (.ico) to specify the Program Icon and title bar icon of your connection manager package. Click “Next” to select the default one.
• You can then specify the help file (.chm) which your user can refer to. Click “Next” to select the default one.
• You can then specify the support string (e.g. For any issues related to your VPN connectivity, dial 040-12345678) that appears on the logon box. Click “Next” to select the blank one.
• You can then add a text file (.txt) containing the license agreement that should be displayed to users once they install the CM package. Click “Next” to select none.
• Click “Next” to skip adding additional files. Click “Next” to finish.

The above steps generate a CM package (.exe file) under %windir%\Program Files\CMAK\Profiles\Vista and above\ directory – with appropriate profile name on your server machine.

You can then send the CM package (.exe file) to your remote access users using any mechanism – like upload to a file or web server, send via email etc.

To install the CM package on the VPN client machine, double click on the CM package file. It will ask whether the package needs to be installed for single user or all users and then it installs the same.

To change the properties of the VPN connection (e.g. VPN destination) on the VPN client machine, please follow these steps:

• Click on networking tray – on bottom right side of your desktop. Move the mouse on the appropriate VPN connection name, right-click and select Properties. This launches VPN connection Properties UI. This UI is different from the properties UI of in-the-box VPN client because the goal of CM based package is end user not changing any configuration – i.e. exposing minimal configuration.

To connect/disconnect the VPN connection, please follow these steps:

• Click on networking tray – on bottom right side of your desktop. Move the mouse on the appropriate VPN connection name, right-click and select “Connect” (if already disconnected) and select “Disconnect” if already connected).

To view the status and statistics of the VPN connection, please follow these steps:

• Click on networking tray – on bottom right side of your desktop. Move the mouse on the appropriate VPN connection name, right-click and select “Status” (if already connected).
• This will launch the VPN connection status UI – where you can find the IP address of the client (inner and outer IP address), IP address of the server, bytes sent/received on the connection.

References: Please refer to this CM deployment guide and this technical reference for further details on the connection manager.

1.3 Further Readings

Remote Access Deployment – Part 2: Configuring RRAS as a VPN server

Remote Access Deployment – Part 3: Configuring RADIUS Server for remote access

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Remote Access Design Guidelines – Part 5: Where to place RRAS server

Hello Customers,

In this post, I will highlight on various placement requirements related to RAS server.

5.1 NAT Routers

A VPN server machine can sit behind a NAT router as long as following requirements are met:

• For SSTP, NAT port redirection or bi-directional should be configured on NAT router – to redirect the HTTPS packets coming in from Internet side to the VPN server. This includes SSTP based HTTPS packets (TCP port 443).
• For PPTP, NAT port redirection or bi-directional should be configured on NAT router – to redirect all the PPTP packets coming in from Internet side to the VPN server. This includes PPTP tunnel control packets (TCP port number 1723) and PPTP tunnel data packets (IP Protocol type as 47 i.e. GRE).

L2TP/IPSec or IKEv2 based VPN server can sit behind NAT router – though it is NOT RECOMMENDED – as pointed by this KB article 885348. In case (like for test lab), you need to do this, please follow this configuration: NAT port redirection or bi-directional should be configured on NAT router – to redirect the IPSec packets coming in from Internet side to the VPN server. This includes IKE packets (UDP port 500) and IPSec ESP packets (UDP port 4500).

Note: For L2TP/IPSec, IKEv2 and SSTP scenario requires VPN server configured with machine certificate, care must be taken to ensure it is provisioned with appropriate subject name i.e. subject name in the machine certificate on VPN server should match the <hostname OR IP address> configured as the VPN destination on the VPN client. This name or IP address in this scenario maps to the NAT router’s public interface.

On a similar note, a VPN client machine located behind a NAT router will be able to successfully establish a VPN connection as long as following requirements are met:

• For L2TP/IPSec or IKEv2, the NAT-T (or NAT traversal) is enabled on both ends i.e. VPN client and VPN server – which is indeed the case for Windows based VPN client and VPN Server
• For SSTP, no extra change is required as it works over HTTPS which by default is supported by all flavour of NAT router.
• For PPTP, the PPTP editor (or sometimes called as application level gateway) is enabled on NAT router.

5.2 Packet Filtering

A VPN server usually resides on the edge of the corporate network facing Internet and as it’s a boundary server, you should only open IP packets meant for VPN tunnel and drop the rest. This can be done by doing packet filtering in one of the following ways:

• Place a network based firewall between Internet and RRAS server. And allowing only specific ports destined to VPN server.
• Enable Windows based host firewall on the RRAS server.
• Enable stateless packet filtering on the RRAS server on the public interface.

The difference between Windows host firewall and RRAS packet filtering can be summarized in following table:

The ports that should be opened for VPN tunnels are: -

• VPN Reconnect or IKEv2: UDP Port 500 (IKE), UDP Port 4500 (NAT-T – Data) and IP Protocol 50 (ESP – Data)
• SSTP: TCP Port 443
• L2TP: UDP Port 500 (IKE), UDP Port 4500 (NAT-T – Data) and IP Protocol 50 (ESP – Data)
• PPTP: TCP Port 1723 (Control) and IP Protocol Type 47 (GRE –Data)

For further details, please refer to this blog on Firewall vs static filters and this post on port numbers.

5.3 Single NIC scenario

Usually VPN server has minimum two NICs – one towards public side (Internet side) through which client connects and other towards private side (Intranet side) connected to rest of intranet.

However RRAS based VPN server can also be deployed in single NIC scenario – specifically in small-medium businesses. In this scenario, RRAS server sits behind a NAT router and has only single NIC. This NIC is used as both public as well as private interface. Or in other words, the VPN tunnel packets come in from VPN client side via this network interface card, encapsulation is removed and then sent back on the same interface to rest of the intranet machines on the LAN. And on reverse side the packet goes back via RRAS server to the VPN client.

The advantage in this scenario compared to multiple NIC case is not by saving the cost of NIC, but on having single IP subnet behind your NAT router. This single IP subnet will be used by your LAN machines (say file server) as well as RRAS server and its connected remote access clients. . The advantage in this scenario is as RRAS server supports proxy ARP functionality, LAN clients automatically detects they need to send packets via RRAS server when trying to send packets to VPN clients – without any extra IP routes. And LAN clients or remote access clients can access Internet via your existing NAT router – thereby simplifying the deployment.

5.4 Load Balancing and High availability

With increased number of mobile users and telecommuters, 24x7 remote access service has becomes life-line to organizations and this mandates a need for high availability VPN server solution. Windows based RRAS server supports high availability using multiple options:

5.4.1 DNS Round robin

DNS Round Robin mechanism on DNS server enables – multiple servers to be registered with the same hostname but having different IP addresses. This way you can deploy a pool of VPN servers at the edge of your network with same server name (e.g. myvpnserver.contoso.com) which can be configured as destination VPN Server in the VPN client configuration. Whenever a VPN client tries to establish the VPN tunnel, it does a name look-up and gets the IP address list from the DNS server. And client picks the first one and establishes the VPN tunnel. The DNS server sends this list differently on each DNS query in a round-robin manner – thereby load balancing each VPN connection to a different server.

This mechanism works for all VPN tunnels and requires no changes on VPN server.

However, this mechanism has some limitations:

• It doesn’t take into consideration usage metrics of a given server – thereby may yield to different load on each server.
• Whenever a VPN server goes down, the DNS records in the DNS server need to be “manually” updated to reflect the change.

Note: For the VPN tunnels that requires machine certificate to be installed on the VPN server i.e. L2TP/IPSec, SSTP, IKEv2 – the subject name of the machine certificate MUST match the name given in DNS server (e.g. myvpnserver.contoso.com) and not the real machine name of the VPN Server. This is because the VPN client does the subject name validation of the machine certificate sent by VPN server against the name with which it connects – and this validation will fail otherwise.

5.4.2 Network Load Balancing

Network load balancing service (NLBS) inside Windows server is the implementation of stateless load balancing to provide high availability and scalability to different server roles. One advantage of using NLBS is that all the servers in a cluster monitor each other with a heartbeat signal, so there is no single point of failure.

For further details, refer to this article.

5.4.3 SSL Load Balancers (only for SSTP)

SSTP based VPN tunnel uses standard HTTPS protocol and hence traditional SSL load balancers (e.g. F5 BIGIP) can be used to terminate HTTPS connections coming from SSTP configured VPN clients and load balance it by sending each VPN connection to different RRAS based VPN servers.

Advantage of this approach:

• SSL load balancers terminates SSL and only sends HTTP packets to VPN server – thereby removing the encryption/decryption load from the VPN server.
• SSL load balancers are stateful in nature and keep track of the HTTPS sessions passing through it. This way a VPN server going down is discovered by load balancer which then removes that VPN server from its pool.

Note: This scenario requires RRAS server to be configured to accept HTTP connections listening on TCP port 80. The machine certificate required for SSTP connections is installed on SSL load balancer. And its certificate hash (or thumbprint) of this machine certificate needs to be configured on RRAS server for SSTP connections to succeed (this is an additional security cover). For further details, please follow this article.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Remote Access Design Guidelines – Part 4: IP Routing and DNS

Hello Customers,

In this post, I will walk through some aspects on IP addressing, routing and name resolution related design guidelines.

4.1 IP Addressing

The VPN client machine will have minimum two IP addresses – one that it gets from ISP through which it connects to VPN server (called as outer or internet IP address) and other is the one it gets from VPN server through which it connects to machines behind VPN server (called as inner or intranet IP address). And each of these addresses can be IPv4 or IPv6 or both.

All tunnels are supported over IPv4 Internet. However please note that L2TP/IPSec, SSTP and IKEv2 tunnels are supported over IPv6 internet and PPTP cannot be used in this scenario.

Both IPv4 as well as IPv6 addresses can be sent to VPN client by VPN server – for all tunnels. This way the VPN client machines can access IPv4 as well as IPv6 resources of Intranet. RRAS server can be configured in following ways - with an IP address pool that it will use to hand-out the (inner) IP address to the VPN clients:

• If handing out IPv4 address to the VPN client: IPv4 pool can be statically configured on the RRAS server using MMC, netsh OR it can be dynamically obtained from a DHCP server located on intranet interface of RRAS server. This address is passed to VPN client during PPP IP configuration (i.e. IPCP) stage or IKEv2 configuration payload stage.

For example, we have a RRAS server with two network interfaces – one towards internet (100.100.100.1/24) and one towards intranet (192.168.1.1/24). In this scenario, there are two options for VPN clients’ IP address pool: -

Option a) VPN client gets the IP address from the same intranet pool (i.e. 192.168.1.0/24). This scenario is common in small-medium businesses – as one IP subnet is sufficient for LAN as well as remote access clients. In this scenario – care must be taken to restrict the pool to appropriate IP addresses if statically configured on RRAS server – otherwise you may land into situations where same IP address is allocated to VPN client by RRAS server as well as a LAN client by the DHCP server. The advantage in this scenario is as RRAS server supports proxy ARP functionality, LAN clients automatically detects they need to send packets via RRAS server when trying to send packets to VPN clients. And you don’t need to configure any additional routes.

Option b) VPN client gets the IP address from a different pool which is not same as intranet interface (say 192.168.2.0/24). This is common in big organizations having large number of machines and subnets. In this scenario – you must ensure appropriate IP routing is done for this subnet on the LAN side i.e. LAN clients must be able to reach to the subnet which VPN clients belongs to (i.e. 192.168.2.0 in this example).

• If handing out IPv6 address to the VPN client: IPv6 pool can be statically configured on the RRAS server with a prefix length of 64 (e.g. 3000:1:1:2:: ). This prefix has to be different compared to RRAS server intranet interface. This prefix is passed to VPN client via IPv6 router advertisement once the PPP interface comes up or IKEv2 configuration payload stage.

For example, we have a RRAS server with two network interfaces – one towards internet (100.100.100.1/24) and one towards intranet (3000:1:1:1::/64). In this example, the IPv6 address pool for VPN client cannot be same as 3000:1:1:1::/64 and it has to be a different pool (say 3000:1:1:2:: ). You must ensure appropriate IPv6 routing is done for this prefix on the LAN side i.e. LAN clients must be able to reach to the prefix which VPN client belongs to (i.e. 3000:1:1:2::/64 for this example).

4.2 Name resolution

The intranet resources can be accessed by VPN clients using names (e.g. http://team/mysite). And names can be resolved to IP address using DNS based resolution (IPv4 as well as IPv6), WINS based resolution (only IPv4) and NetBIOS based broadcast resolution (only IPv4).

WINS and DNS based name resolution requires a server address to be provisioned on the VPN client. The WINS server can run on top of IPv4 based network only, whereas DNS server can have IPv4 as well as IPv6 address – or in other words VPN client can reach the DNS server over IPv4 or IPv6 based network.

The IP address of WINS and DNS server is provisioned on VPN client in one of the following ways:

· Statically configured inside VPN client configuration – inside Network Properties of VPN client.

· Dynamically obtained from the VPN server – during connection establishment. This handshake process varies between PPP based tunnels (aka PPTP, L2TP and SSTP) and IKEv2 based tunnel (aka VPN reconnect).

For PPP based tunnel, the WINS and DNS server’s IPv4 address picked up from VPN server’s private interface is passed via PPP IPv4 configuration stage (called as IPCP) to the VPN client. And the DNS server’s IPv6 address is passed via DHCPv6 Inform transaction after IPv6 prefix is assigned to VPN client via router advertisements. Note: This requires VPN server to be running DHCPv6 relay agent and DHCPv6 stateless server running on the network behind VPN server.

For IKEv2 based tunnel, the WINS and DNS server’s IPv4 as well as IPv6 address is picked up from VPN server’s private interface and is passed via IKEv2 tunnel establishment phase.

The NetBIOS based name resolution for IPv4 resources works as a broadcast – i.e. doesn’t require any server to be provisioned. It requires “Enable broadcast name resolution” to be enabled on RRAS based VPN server and “Enable NetBIOS over TCP/IP” setting to be enabled on VPN client.

4.3 Routing on VPN Client side

Once the VPN interface comes up, VPN client machine has two IP interfaces – one is the VPN interface and second is the internet interface on top of which the VPN connection is established.

Every TCP/IP packet goes through a route look-up to find the best matching route (longest prefix match) for the given destination. And for most practical cases, most of the resources don’t match a specific route and thereby matches the default route (i.e. routing table entry with destination as 0.0.0.0 for IPv4 and ::/0 for IPv6).

There are two choices for the “default route” on the VPN client machine:

• Default route over VPN interface: This means all the traffic (intranet as well as internet) will flow on top of VPN interface from client to server – except the local subnet traffic flowing over underlying internet interface.

To enable this scenario, “use default gateway” should be enabled inside IPv4 and IPv6 properties of VPN client configuration.

For example, the client machine has a LAN interface providing Internet connectivity with IP Address as 192.168.1.2 with default IPv4 route to a broadband router running NAT with IP address 192.168.1.1. On the LAN side, there is a printer too with IP address 192.168.1.3.

Once the VPN connection is successfully established, the client machine has a VPN interface with IP address as 10.0.0.100 with VPN server tunneled address as 10.0.0.1. And one more default IP route is added on the client machine “with lowest metric” (or in other words highest preference) – with gateway address as 10.0.0.1. Same thing happens if IPv6 prefix is assigned to the VPN client.

Whenever the client machine access any machines on the LAN side (i.e. 192.168.1.0/24), those IP packets goes directly over LAN without going over VPN tunnel. However, when the client machine accesses any resources behind RRAS server (i.e. intranet resources) or machines on the internet side (say http://www.microsoft.com), those packets traverses the VPN tunnel and reach the VPN server. And the VPN server based upon the destination routes the packet onto Internet or to Intranet side. Note: If private IPv4 address is given to VPN client, then NAT should be running on RRAS server or some machine in-front of RRAS server (i.e. between RRAS server and internet) to translate the private IP to public IP.

Note: This scenario requires DNS server on intranet side to resolve Intranet as well as Internet queries. And it is assumed that local subnet traffic is resolved via some broadcast resolution (like NetBIOS for IPv4 and LLMNR for IPv6).

• Default route over internet interface: This means only intranet traffic traverses the VPN tunnel and rest of all traffic (i.e. local subnet traffic OR Internet traffic) goes over underlying internet interface. This scenario is also called as “split-tunneling”.

To enable this scenario, “use default gateway” should be disabled inside IPv4 and IPv6 properties of VPN client configuration.

If we take the above example, once the VPN connection is successfully established, the default route remains untouched (i.e. continue to point to the underlying internet interface).

The VPN client can access the intranet machines which falls under the IPv4 subnet (i.e. 10.0.0.0/8) or IPv6 prefix that the client receives from the VPN Server. This may be well suited for small deployment (i.e. having one subnet or prefix range), however in case the intranet resources are divided into multiple subnets or prefixes, then that entire range needs to be provisioned on the VPN client using some mechanism (like using connection manager administration kit aka CMAK).

Note: This scenario requires DNS server on intranet side to resolve Intranet as well as Internet queries – as DNS queries may still go over VPN interface. And it is assumed that local subnet traffic is resolved via some broadcast resolution (like NetBIOS for IPv4 and LLMNR for IPv6).

Warning: As a security note, Internet connection sharing MUST be disabled on the VPN client machine – to prevent other users (behind VPN client machine or may be on Internet) to access the corpnet using the VPN client machine’s tunnel to the VPN server.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Remote Access Design Guidelines – Part 3: Tunnel selection, Authentication, Authorization and Accounting

Hello Customers,

In this post, I will walk through the most important topic – which authentication protocol, VPN tunnel to use, how to authorize access of your VPN users.

Lets have a look:

3.1 User Authentication

The remote access user is authenticated by the VPN server during VPN tunnel establishment phase.

The following table highlights the various recommended deployment options for user authentication. It highlights the deployment requirements for a given authentication protocol on the client side as well as the network side (RRAS server, Radius server end) - going down from highest security level to lowest level

To enable user authentication, RRAS server to be configured for Radius based authentication and Radius server is joined to Active directory domain in order to authenticate users. The Radius server itself may be running on the same server as RRAS or on a different server.

** The same authentication protocol must be configured on both ends of authentication i.e. VPN client as well as Radius server. Within Radius server, a policy should be created for NAS type as RRAS server. And within this policy, the specific authentication protocols must be configured inside policy “condition”. Additionally RRAS server must be configured to accept the specific authentication protocol.

Note: The above table doesn’t include certain third party EAP methods (like RSA SecurID) also supported by RAS based remote access solution.

3.2 Tunnel Types

There are different VPN tunnels that exist inside Windows OS. First, let us compare the different tunnels on general and network centric parameters

Now let us compare these VPN tunnels on the various security related parameters: 

Where,

* PPTP, SSTP tunnel does PPP based user authentication (password or certificate based as explained in earlier section including EAP as well as non-EAP based authentication protocols).

** L2TP/IPSec tunnel first does IPSec level machine authentication (pre-shared key or certificate based) followed by PPP based user authentication (password or certificate based as explained in earlier section – including EAP as well as non-EAP based authentication protocols). The machine authentication is done between VPN client and RRAS server, whereas user authentication is performed between VPN client and Radius server.

*** VPN reconnect (IKEv2) tunnel supports machine authentication (certificate only) or user authentication (only EAP based authentication using password or certificate based authentication as given in earlier section). The machine authentication is done between VPN client and RRAS server, whereas user authentication is performed between VPN client and Radius server.

**** The certificate requirements on the VPN client side or on the network side are additional to the authentication requirements that are described in user authentication section above. The certificates mentioned here are required for initial part of tunnel (like IPSec session for L2TP scenario or SSL session for SSTP scenario) to come up before performing user authentication. Please note: this doesn’t mean this requires separate set of certificates need to be managed for initial part of tunnel and subsequent user authentication (e.g. if PEAP is used with SSTP, then the root certificate on the client side for PEAP can be same as root certificate for SSL negotiation) – thereby easing out deployment. However, if RRAS server and Radius server are deployed on different machines, then different machine certificates are required - one on the RRAS server side (for L2TP/IPSec or IKEv2 or SSTP) for the initial part of tunnel negotiation and other on the Radius server side (for PEAP or EAP-TLS authentication). However the client side certificate remains the same.

3.3 Tunnel Selection

As described in the above section, there are different types of VPN tunnels that is supported by Windows based VPN client and server.

RECOMMENDATION: Based upon the feature set, our recommended tunnel types are IKEv2 followed by SSTP.

As a network admin, your main goal is to enable smooth migration of your existing PPTP or L2TP/IPSec users to IKEv2 followed by SSTP based deployment. But that requires each remote access user to change their operating system – which may not be possible at once. This means multiple tunnel types needs to be supported on the server side during the migration timeframe. This is where you can leverage the VPN tunnel strategy feature inside Windows VPN client that helps you specify the order in which VPN tunnels are tried – till a given tunnel type is able to successfully connect to the VPN server.

For further details, please read this blog.

3.4 Authorization

Authentication (as given above) allows a remote access user to identify itself to the remote access server and the remote access server verifying the user identity. Whereas, authorization that is done after the user authentication allows admin to specify what the remote access user can access. Some examples of authorization policies are: allow user to access specific IP subnets, allow VPN access during particular time of the day, allow access with x minute idle timeout, etc.

To enable user authorization, RRAS must be configured to use Radius based authorization provider. And on the Radius server side, within the authentication policy different authorization rules can be added as “constraints”. If there are multiple constraints, the authenticated VPN connection will be subjected (or enforced) to each of those constraints.

3.5 Accounting

The activities of the remote access users can be accounted using Radius based accounting. These activity logs include username, session start time, session end time, transmit/receive bytes and transmit/receive packets.

To enable user accounting, RRAS must be configured to use Radius based accounting provider. The Radius server must be configured to log accounting information in a file OR inside a database.

3.6 Health check

RRAS Server allows Network Access Protection (NAP) based health check (AUTHORIZATION) of the remote VPN users before they are granted access to the intranet. The health definition can be: checking VPN client machine running firewall and antivirus, enabled for Windows update, is running latest patches etc.

To enable VPN NAP deployment, VPN client and the Radius server policy must be configured for PEAP as authentication protocol with NAP quarantine check enabled inside PEAP configuration. Why only PEAP. This is because the client PC’s health information is relayed from the VPN client to the Radius server inside PEAP protocol and hence no other authentication protocols can be used. And within PEAP, any inner EAP method like EAP-MSCHAPv2 or EAP-Smartcard or user certificate can be used. This can also include other 3^rd party EAP methods like one-time password that plugs into RAS EAP framework. VPN NAP is supported for all VPN tunnel types i.e. PPTP, L2TP/IPSec, SSTP and IKEv2.

Radius server must be enabled for NAP based deployment. This includes creating of remote access policies for healthy as well as unhealthy clients and creating the appropriate connection request policy.

To restrict unhealthy clients to a quarantine zone hosting remediation servers (like antivirus signature server, patch update server), remediation server group must be created inside Radius server. Remediation server group allows you to specify the IPv4 and/or IPv6 address of the remediation servers. This list will be sent by Radius server to the RRAS server once it determines the VPN client is unhealthy and RRAS server applies this list as IP filters on that particular VPN sub-interface - means “allow packets to/from these IP addresses and drop rest”. Once the client becomes healthy, Radius server informs RRAS server which removes these filters from that particular VPN sub-interface. And if there are any other IP filters that are sent for the VPN interface (which have been added as “IP Filters” of remote access policy representing healthy clients), they will be applied.

To reiterate, remediation server group and the IP Filters configured inside given remote access policy have separate meanings on RRAS server. The former (i.e. remediation group) are used explicitly for NAP i.e. gets applied on specific VPN sub-interface on RRAS server when the VPN client is unhealthy and removed when the VPN client becomes healthy. However the later ones (i.e. IP filters) are added to VPN client even if NAP is not enabled OR applied when NAP is enabled but the VPN client has become healthy.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Remote Access Design Guidelines – Part 2: VPN client software selection

Hello Customers,

In this post, I will walk through the different ways in which you can enable VPN functionality on the remote access devices (desktops, laptops used by your remote access users).

Lets look at the various choices:

2.1 Operating Systems

The remote access users in your organization will normally be running different operating systems on their remote access devices (like PCs and laptops). The choice of operating system governs few important decisions regarding remote access deployment - mainly the VPN tunnel selection and the authentication protocol selection – as defined further in next few posts.

2.2 VPN Client Selection

There are three types of VPN client software that runs on Windows OS using Windows VPN stack (i.e. PPTP, L2TP, SSTP or IKEv2 VPN tunnel):

• In-built (or in-the-box) VPN client - created by end user using “Setup a connection or network” wizard inside “Network and Sharing Center” in Vista/Windows7.
• Connection Manager (CM) client created using Connection Manager Administration Kit (CMAK) software on the RRAS server. A CM client is created by the remote access server administrator and then shared to the end users via email or file/web server.
• 3^rd party VPN client software that has its own provisioning mechanism and user interface - however runs^** on top of the VPN stack of Windows OS. These clients can connect to Windows based RRAS servers or their own 3^rd party VPN servers. The functionality exposed by this type of VPN client varies from vendor to vendor and hence is kept outside the scope of this post.

** Please note: There are a lot of 3^rd party VPN clients which works on top of Windows OS but uses its own VPN client stack (like IPSEC X Auth based, SSL network connector driven) instead of Windows VPN stack. Hence all these clients are kept outside the scope of this post.

The following table summarizes the feature set between in-built VPN client and connection manager VPN client:

*** A DNS name can represent a set of VPN servers if deployed using DNS round-robin as discussed in a subsequent section. Hence the in-built VPN client does support multiple VPN servers using single hostname. And CM based client goes one step further allowing a list of VPN server names/IP address to be provisioned by admin of which end user can select one of them using CM client properties. However please note: in case of failure of connectivity to one server, the CM client doesn’t fallback or tries the next one.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]