Routing and Remote Access Blog

Provisioning VPN client settings using Group Policy

rrasblog — Mon, 31 Aug 2009 15:38:00 GMT

Problem:

Today, Microsoft VPN client can be configured in two ways as discussed in this article – a) in-built VPN client b) CM based VPN client. The first method requires end user to know the VPN settings and then create a VPN connection – which needs to be repeated by each user and prone to errors. The second method requires VPN server administrator to create a VPN connection package (called as CM profile) and then send to end user through some mechanism (like uploading to a web server). The end user then manually installs the CM profile. The problem in this mechanism is end user may forget to do the same step when the configuration changes and VPN server administrator has no way to automatically push the changes.

Solution:

In this article we will discuss a group policy (GP) based provisioning solution for Microsoft VPN client. The key point of this solution is that it works as long as client machine is running following Windows OS releases: Windows XP, Windows 2003, Windows Vista, Windows Server 2008, Windows7, Windows 2008 R2.

The steps to create the VPN connection for a VPN server administrator are fairly simple:

1) Configure all the settings required by VPN client (like VPN server hostname) in an XML file.

2) Place a powershell script and the above mentioned XML file in a file server location on the network .

3) Create a group policy object (GPO) that points to network location containing the powershell script and XML file. Add the necessary end users/machines to the GPO.

Whenever the remote users logs on to their domain, they get group policy update and the VPN client gets created on their machine.

The details of the entire solution (along with the powershell script and sample XML file) can be seen here

How it works:

The solution involves following elements:

1. Remote access (RAS) APIs

2. PowerShell script and XML configuration file

3. Group Policy

The VPN server administrator configures a powerShell script to be run as a logon script in the Domain Controller. The instructions required for configuring VPN client settings are inside the script. The script takes the VPN client settings as input in form of a XML file which is configured by VPN server administrator.

When a domain user logs on to the machine, the group policy settings get applied on the client. As part of that process, the powershell script is run. The script reads the configuration from XML file and configures the VPN client entries on the client machine by calling RAS APIs.

The end users can then use the VPN client connection to connect to VPN servers.

Let us know your feedback

Cheers,

Rama Krishna Prasad S

Software Development Engineer

Windows networking

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

Troubleshooting common VPN related errors

rrasblog — Wed, 12 Aug 2009 14:27:59 GMT

Hello Customers,

If you are seeing errors while establishing VPN connection using Windows in-built VPN client, you have reached the right place. This article will help you to easily troubleshoot some of the common VPN related errors.

1) Error Code: 800

Error Description: The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly.

Possible Cause: This error comes when the VPN tunnel type is ‘Automatic’ and the connection establishment fails for all the VPN tunnels.

Possible Solutions:

a> If you know which tunnel should actually be used for your deployment, try to set the ‘Type of VPN’ to that particular tunnel type on the VPN client side. [This can be set by clicking the ‘Network Connections’ icon on the bottom right of the task bar, Select your Connection, Right Click -> Properties -> Securities Tab -> Under ‘Type of VPN’ select the interested VPN tunnel type ]

By making VPN connection with a particular tunnel type, your connection will still fail but it will give a more tunnel specific error (for example: GRE blocked for PPTP, Certificate error for L2TP, SSL negotiation errors for SSTP, etc.)

b> This error usually comes when the VPN server is not reachable or the tunnel establishment fails.

i. Make sure the VPN server is reachable (try to PING the server).

ii. If interested in PPTP, make sure PPTP port (TCP 1723) or GRE Port (47) is not blocked on in between firewalls.

iii. If interested in L2TP, make sure

1. Correct pre-shared key or machine certificate are present both on client and server.

2. L2TP port (UDP 1701) is not blocked on any of the firewalls.

iv. If interested in IKEv2 based VPN tunnel, make sure

1. IKE port (UDP port 500, UDP port 4500) is not blocked.

2. Correct machine certificate for IKE are present both on client and server.

v. If interested in SSTP, make sure correct machine certificate is installed on the server and correct trusted root certificate is installed on the client machine.

2) Error Code: 609, 633

Error Description:

609: A device type was specified that does not exist.

633: The modem (or other connecting device) is already in use or is not configured properly.

Possible Cause: This error usually comes when the connecting VPN device (aka miniport) is not configured properly.

To confirm the issue: From the elevated command prompt, type the following command to confirm the presence of miniport: -

netcfg.exe –q <miniport name>

Following is the Miniport Device name for different tunnels:

PPTP Tunnel: MS_PPTP

L2TP Tunnel: MS_L2TP

SSTP Tunnel: MS_SSTP

VPN Reconnect (IKEv2) Tunnel: MS_AGILEVPN

Possible Solution:

1. In Windows 7, a built-in diagnostic with repair is provided for the ‘miniport missing’ issue for locally created VPN connections. A ‘Diagnostic’ button is shown on the Error page of the VPN connection. By clicking this button, it will give a ‘repair’ option if it finds the issue to be miniport missing which if clicked will automatically try to fix the issue.

2. On Vista or below OS, if the miniport device is missing, you can run the following command from ‘elevated’ command prompt:

a> netcfg.exe -e -c p -i <miniport name>

Details of the <miniport name> is given above.

b> Stop and Start ‘rasman’ (‘Remote Access Connection Manager’) service.

3) Error Code: 732, 734, 812

Error Description:

732: Your computer and the remote computer could not agree on PPP control protocols.

734: The PPP link control protocol was terminated.

812: The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

Possible Causes: One of the prime causes for the above error is: when the *only* allowed authentication protocol configured on VPN server (or Radius server) is MS-CHAP and the VPN client is Vista or above OS platform (like Windows7). Note: due to security reasons MS-CHAP was removed from Vista and above OS platform and hence the connection fails.

Error 812 comes when Authentication protocol is set via NPS (Network Policy and Access Services) otherwise Error 732/734.

Event log 20276 is logged to the event viewer when RRAS based VPN server authentication protocol setting mismatches which that of the VPN client machine.

Possible Solution: Configure a more secured authentication protocol like MS-CHAPv2 or EAP based authentication on the server – which matches the settings on the client side.

4) Error Code: 806

Error Description: 806: The VPN connection between your computer and the VPN server could not be completed. The most common cause for this failure is that at least one Internet device (for example, a firewall or a router) between your computer and the VPN server is not configured to allow Generic Routing Encapsulation (GRE) protocol packets. If the problem persists, contact your network administrator or Internet Service Provider.

Possible Cause: PPTP uses GRE (Generic Route Encapsulation) protocol to encapsulate the VPN payload in a secure manner.This error generally comes when some firewall in path between client and server blocks GRE Protocol (i.e. IP protocol number 47).

Possible Solution: Allow both outgoing and incoming Protocol 47 (GRE) on any in between firewalls. If that is not possible, deploy SSTP based VPN tunnel on both VPN server and VPN client – that allows VPN connection across firewalls, web proxies and NAT.

5) Error Code: 789, 835

Error Description:

789: The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer.

835: The L2TP connection attempt failed because the security layer could not authenticate the remote computer. This could be because one or more fields of the certificate presented by the remote server could not be validated as belonging to the target destination.

Possible Causes: This is a generic error which is thrown when the IPSec negotiation fails for L2TP/IPSec connections.

Possible causes for this issue could be:

a> L2TP based VPN client (or VPN server) is behind NAT.

b> Wrong certificate or pre-shared key is set on the VPN server or client

c> Machine certificate or trusted root machine certificate is not present on the VPN server.

d> Machine Certificate on VPN Server does not have 'Server Authentication' as the EKU

Possible Solution: Make sure correct certificate is used both on client and server side – for further details refer to this blog. In case Pre Shared Key (PSK) is used, make sure the same PSK is configured on the client and the VPN server machine.

6) Error Code: 766

Error Description: 766: A certificate could not be found. Connections that use the L2TP protocol over IPSec require the installation of a machine certificate, also known as a computer certificate.

Possible Cause: This error usually comes when their is no valid machine certificate on your client machine.

Possible Solution: Make sure the correct machine certificate for L2TP validation is installed on your client machine - for further details refer to this blog.

7) Error Code: 691

Error Description: 691: The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.

Possible Cause: This error is given when the authentication phase erred out because of wrong credentials being passed.

Possible Solution:

a> Make sure correct username and password is typed.

b> Make sure ‘Caps Lock’ is not turned ON while typing credentials.

c> Make sure the authentication protocol as selected on the client is permitted on the server.

8) Error Code: 809

Error Description: 809: The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g, firewalls, NAT, routers, etc) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.

Possible Cause: This error usually comes when some firewall between client and server is blocking the ports used by VPN tunnel

a> PPTP port (TCP port 1723) is blocked by a firewall/router. [Applicable to tunnel type = PPTP]

b> L2TP or IKEv2 port (UDP port 500, UDP port 4500) is blocked by a firewall/router. [Applicable to tunnel type = L2TP or IKEv2]

Possible Solution: Enable the port (as mentioned above) on firewall/router. If that is not possible, deploy SSTP based VPN tunnel on both VPN server and VPN client – that allows VPN connection across firewalls, web proxies and NAT.

9) Error Code: 13806

Error Description: 13806: IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

Possible Cause: This usually happens when there is no machine certificate or no root machine certificate present on the VPN Server.

Possible Solution: Please contact your VPN server administrator to verify and fix the issue - for further details refer to this blog.

10) Error Code: 13801

Error Description: 13801: IKE authentication credentials are unacceptable.

Possible Causes: This error usually comes in one of the following cases:

The machine certificate used for IKEv2 validation on RAS Server does not have 'Server Authentication' as the EKU (Enhanced Key Usage).
The machine certificate on RAS server has expired.
The root certificate to validate the RAS server certificate is not present on the client.
VPN Server Name as given on client doesn’t match with the subjectName of the server certificate.

Possible Solution: Please contact your VPN server administrator to verify and fix the above issue - for further details refer to this blog.

11) Error Code: 0x800704C9

Error Description:

Possible Cause: This issue may occur if no SSTP ports are available on the server.

Possible Solution: To troubleshoot this issue, verify that the RAS server has sufficient ports configured for remote access. To do this, follow these steps:

Start the Routing and Remote Access MMC snap-in.
Expand the server, right-click Ports, and then click Properties.
In the Name list, click WAN Miniport (SSTP), and then click Configure.
Modify the number that appears in the Maximum ports list, as appropriate for your requirements, and then click OK.
Note By default, 128 ports are available for this device.
In the Port Properties dialog box, click OK

12) Error Code: 0x80070040

Error Description:

Possible Cause: This issue may occur if a server authentication certificate is not installed on the RAS server.

Possible Solution: Make sure the machine certificate used by RAS server for SSL has ‘Server Authentication’ as one of the certificate usage entries. For further details refer to this blog. For changing the SSTP machine certificate, please refer to this blog if on VPN server is running Windows server 2008 R2, else refer to this blog

13) Error Code: 0x800B0101

Error Description: 0x800B0101: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.

Possible Cause: This issue may occur if a server authentication certificate is not installed on the Routing and Remote Access server.

Possible Solution: Make sure the machine certificate used by RAS server for SSL has ‘Server Authentication’ as one of the certificate usage entries and the certificate is not expired. For further details refer to this blog. For changing the SSTP machine certificate, please refer to this blog if on VPN server is running Windows server 2008 R2, else refer to this blog

14) Error Code: 0x800B0109

Error Description: 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Possible Cause: This issue may occur if the appropriate trusted root certification authority (CA) certificate is not installed in the Trusted Root Certification Authorities store on the client computer.

Note: Generally the VPN client machine is joined to the active directory based domain and if you use domain credentials to log on to the VPN server, the certificate is automatically installed in the Trusted Root Certification Authorities store. However, if the computer is not joined to the domain or if you use an alternative certificate chain, you may experience this issue.

Possible Solution: Make sure root certificate is installed on the client machine in the Trusted Root Certification Authorities store.

15) Error Code: 0x800B010F

Error Description: 0x800B010F: The certificate's CN name does not match the passed value.

Possible Cause: This issue may occur if the host name of the server that is specified in the VPN connection does not match the subject name that is specified on the SSL certificate that the server submits to the client computer.

Possible Solution: Verify that the certificate which RAS server uses for SSL has the correct subject name. For example, if the VPN client is configured to use FQDN name to connect to the VPN server, the certificate used by VPN server must have FQDN in the subject name. Same thing if the client is configured to use IP address (IPv4 or IPv6) of VPN server. If the appropriately-named certificate is not present on the RAS server, you must obtain a new certificate for the RAS server.

For changing the SSTP machine certificate, please refer to this blog if on VPN server is running Windows server 2008 R2, else refer to this blog

16) Error Code: 0x80092013

Error Description: 0x80092013: The revocation function was unable to check revocation because the revocation server was offline.

Possible Cause: This issue may occur if the client computer fails the certificate revocation check for the SSL certificate that the client computer obtained from the VPN server.

Possible Solution: To troubleshoot this issue, verify that the server that hosts the Certificate Revocation List (CRL) is available to the client – before VPN tunnel is established. This means that the CRL server is available to the client over the Internet because the client computer runs the CRL check during the establishment of the SSL connection and the CRL check query is sent directly to the CRL server.

17) Error Code: 0x800704D4

Error Description: 0x800704D4: The network connection was aborted by the local system

Possible Cause: This error comes when the hostname of the VPN server is not resolved by the forward proxy in-front of the VPN client.

Possible Solution: Check your proxy settings inside the Internet explorer. If the settings are correct, please ensure you are able to access other web sites (e.g. www.microsoft.com) using the browser. If that also works through, try accessing the URI which SSTP uses internally i.e. https://vpn_server_name/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ - please replace vpn_server_name with actual VPN server name. If you see error “the website cannot be found” inside your browser, that validates the hostname resolution failure. If you know the IP address of VPN server, try connecting with that. Else contact your network administrator (who is responsible for managing the web proxy – most probably your ISP) – giving them the details of the problem (i.e. hostname resolution is failing for that particular hostname).

18) Error Code: 0x80072746

Error Description: 0x80072746: An existing connection was forcibly closed by the remote host.

Possible Cause: This error comes when the server machine certificate binding to HTTPS is not done on the VPN server OR the server machine certificate is not installed on the VPN server.

Possible Solution: Please contact your VPN server administrator – to check whether relevant machine certificate is installed on the VPN server. If installed correctly, check the HTTPS binding by running following command at the VPN server command prompt - “netsh http show ssl”. For further details, please refer to this blog.

Further References:

Troubleshooting articles @ RRAS blog site

How to troubleshoot SSTP based connection failure in Windows

Please send in your feedback via email, in case we are missing some errors that you encounter most commonly in your deployment.

Cheers,

Dinesh Agarwal

Amit Kumar (WINDOWS)

Windows Networking

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

How to deploy RRAS based VPN server that gives dedicated IP to remote users/machines and allow them to access Internet using a dedicated public IP address

rrasblog — Thu, 30 Jul 2009 17:21:00 GMT

Hello Customers,

In this blog, I will go through the steps to enable the following scenario:

Let us say you have a bunch of remote application servers that should be exposed to Internet only after routing them via a central server (which does accounting/firewall etc). And as they are application servers, you will like to reserve a public IP address for each of them – so that their external name to public IP address mapping is maintained.

How to enable this scenario?

You can deploy Windows based RRAS server role as a VPN server plus a NAT router and configure it in such a way that a dedicated public IP address is allocated to each VPN clients (i.e. your application servers in this case). The way we will do this is: Enable NAT router functionality on the VPN server to redirect public IP addresses to private IP addresses using 1o1 mapping. Then enable VPN server to assign each VPN username a dedicated private IP address. And then create VPN client on the application server with different username.

Let me walk you through the quick steps to do this:

Install Windows server on one of your edge machine at the central site. And connect it to Internet.
Obtain a range of public IP addresses from the ISP – let us say IP1, IP2, IP3 .... IP10 - first one (i.e. IP1) by VPN server and rest nine (IP2 to IP9) for remote application servers that are exposed by this VPN server.
On this Windows server machine:
- Configure all the IP addresses given by ISP to Ethernet interface facing Internet (i.e. IP1 to IP10 in this example) – let us call this interface as “Internet Interface”.
- Open “Server Manager” and install Routing and Remote Access server role.
- Click on “Routing and Remote Access” MMC snap-in, configure RRAS as VPN server by following the steps 2.1 to 2.3 given in this blog – using “Internet Interface” as the public interface. Note: Please ensure you have not selected “Enable security on the selected interface by setting up static packet filters” on the wizard. Because RRAS static filters and NAT doesn’t work together.
- Now install the NAT component. On the MMC snap-in, select “IPv4” and “General”. Right click and select “New Routing Protocol” and select “NAT”. You will then see “NAT” node under IPv4.
- Now configure the NAT component with a pool of public IP addresses. Right-click on NAT node and select the “Internet Interface”. Click OK. Select Interface Type as “Public Interface connected to the Internet” and select “Enable NAT on this interface”.
- Click on “Address Pool” tab at the top, click on “Add” and enter the range of IP addresses that you have allocated for your remote application servers (i.e. IP2 to IP10 in this example). Ensure you have entered the network mask correctly. Once done click OK.
- Now do a 1-to-1 mapping of each public IP address to a private IP address – that you will assign to your remote application servers when they establish VPN connection to this machine. Let us say the private IP addresses are – IPA, IPB, ... IPI. Click on “Reservations” button on “Address Pool” tab and add the reservation – e.g. public IP2 mapped to private IPA; public IP3 mapped to private IPB and so on.... Once done click OK.
- The above step gets your NAT router mapping ready for one public IP address to one private IP address and vice-versa.
- Now configure the NAT component with VPN interface as the private interface. Right-click on NAT node and select the interface named “Internal” (this is the pseudo interface created by VPN server which is representing the interface on which all clients connect). Select Interface Type as “Private Interface connected to private network”.
- Now you need to configure the VPN server to ensure each remote application server when connects to this machine over VPN – gets a dedicated private IP address (one of IP address in IPA to IPI pool in this example) . This way after VPN connection, when these remote machine send packets to any machine beyond VPN server (say on Internet), their IP packets gets rightly translated – e.g. for appserverA – it is translated from IPA to IP2 when going out to Internet and vice versa when coming in from Internet.

To enable this, click on “Users and Groups” snap-in (i.e. lusrmgr.msc) on the machine where the usernames are created with which each application server will establish a VPN connection. This can be a local machine OR the active directory machine (if RRAS server or its Radius server is joined to the domain). Open the snap-in, click on the username (e.g. appserverA), click on “Dial-in” tab, select “Network Access Permission” as “Allow access”, select “Assign Static IP Addresses” and then enter the static IPv4 address – i.e. private IP address assigned to this machine i.e. IPA.

Repeat the same step for all the other username for other application servers (e.g. appserverB to appserverI) – with different private IP addresses (i.e. IPB to IPI).

Create VPN client connection on each of your application server machine – giving destination IP address of VPN server (i.e. IP1) and corresponding username (e.g. application server A using appserverA as the username).
Once the above steps are done – you are all set.

How does it work?

Remote application servers working as VPN client connect to VPN server at the edge of your network.
The VPN client machine gets a private IP address assigned to them – e.g. application server A connecting with VPN username as appserverA gets IP address IPA.
When the machine sends an IP packet on Internet, the IP packet goes with inner IP header having source IP address as private IPA till the VPN server. When it reaches VPN server, it removes the outer IP header, looks at inner IP header and does NAT translation to change the source IP address from private IPA to public IP2. And then send it on public Interface onto Internet.
The packet reaches the peer machine on internet. When the return IP packet traverses the Internet, the ISP forwards the packet to the VPN server machine.
VPN server receives the packet on Internet interface, looks at the NAT mapping and then changes destination IP address in IP header from public IP2 to private IPA. And then sees the private IPA is assigned to a VPN client. And it sends the packet on “Internal” interface which sends over VPN tunnel, adds outer IP header and the packet finally reaches the VPN client with destination IP address as IPA.

Thanks to Aria Fahimipour from Aria servers for providing me the required details about this common usage scenario which has worked for them.

Let me know if that works for you too.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

How to configure Network Load Balancing (NLB) based cluster of VPN Servers

rrasblog — Thu, 02 Jul 2009 13:37:00 GMT

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

rrasblog — Wed, 10 Jun 2009 14:36:00 GMT

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

rrasblog — Wed, 10 Jun 2009 13:52:00 GMT

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.]

How to configure RRAS based SSTP VPN server behind F5 BIGIP SSL load balancer

rrasblog — Tue, 26 May 2009 12:50:00 GMT

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

Connect to F5 BIGIP management console web interface. Go to Local Traffic
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).
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.
Nodes: Create nodes specifying IP address of each of the VPN servers (i.e. RRAS server’s IP address facing towards BIGIP or Internet).
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.
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.
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
Resources: Add the iRule created in step 6 – i.e. SSTP_iRule to the virtual server.

Configuring RRAS as SSTP VPN server

On WS 2008 or later OS, using Server Manager, install RRAS server role inside “Network Policy and Access server” node.
Once installed, configure RRAS server as VPN server – using RRAS configuration wizard (details given in SSTP step-by-step guide - in references).
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).
Once you have set the regkeys, restart RRAS server.
Follow the same steps on all the RRAS servers hosted behind F5 BIGIP (i.e. for all the nodes created on BIGIP).
And you are all set-to-go and test the stuff.

Testing

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.
Install the trusted root certificate on the client machine
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.
For further troubleshooting, look at F5 logs and RRAS event logs.

References

Step-by-step guide: Deploying SSTP Remote Access
KB947030: How to deploy SSTP based VPN server behind SSL load balancer
KB947054: Registry entries that RRAS adds in WS08
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

rrasblog — Wed, 13 May 2009 14:22:07 GMT

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

rrasblog — Mon, 11 May 2009 16:30:00 GMT

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

3rd party VPN client compatibility with Windows 7 and Windows Server 2008 R2

rrasblog — Tue, 05 May 2009 14:39:00 GMT

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

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPsec VPN	Final	x86, x64	V7.6.2	Click Here	Found heap corruption issue in the VPN client. Not a blocking issue, and was present on Windows Vista. AT&T working on resolving the issue.	7000

Checkpoint

VPN client	Release	Platform	Version	Download URL	More information
IPsec VPN	Final	x86	NGX R60 HFA2	Expected availability: April 2007 Click Here	Clean installation working with limited testing.
SSL VPN	Final	x86, x64	SNX R66 HFA 01	Expected availability: June 2009 Click Here	SSL Network Extender: Clean installation working with limited testing. Upgrade scenario has been flagged for upgrade block. Click Here
Endpoint Connect	Final	x86	NGX R66	Expected availability: June 2009 Click Here	Clean installation working with limited testing.
Endpoint Connect	Final	x64	NGX R66	Expected availability: June 2009 Click Here	Clean installation working with limited testing.

CISCO

VPN Client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 Build
Cisco AnyConnect VPN Client (SSL VPN)	2.3.x	x86	2.3.x	Click Here	You must have a Cisco.com user account to download.	7048
Cisco AnyConnect VPN Client (SSL VPN)	2.3.x	x64	2.3.x	Click Here	You must have a Cisco.com user account to download.	7048
Cisco VPN Client (IPsec)	Final	X86	5.0.5+	Click Here
Cisco VPN Client (IPsec)	5.0.5+	x64	5.0.5+	Click Here	No official support for this version planned by Cisco. Use the Cisco AnyConnect VPN Client for both Windows 7 and x64 support	7048

Citrix

VPN client	Release	Platform	Version	Date	Download URL	More information	Tested on Windows 7 build
SSL VPN	Final	x86	Access Gateway Standard Edition 4.5.8	Available now	Click Here	VPN client must be re-installed after upgrading from Vista	7000
SSL VPN	Final	x64	Access Gateway Standard Edition	Planned	Not yet available	In development
SSL VPN	Final	x86	Access Gateway Advanced Edition 4.5 HF4	Available now	Click Here	VPN client must be re-installed after upgrading from Vista	7000
SSL VPN	Final	x64	Access Gateway Advanced Edition	Planned	Not yet available	In development
SSL VPN	Final	X86	Access Gateway Enterprise Edition 9.0	Available now	Click Here	Requires server build 9.0.68 or later.	7000
SSL VPN	Final	x64	Access Gateway Enterprise Edition	Planned	Not yet available	In development

F5

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
SSLVPN	Build Stage	x86	Post v.6.03	Expected availability: Q3 2009 Click Here		7000
SSLVPN	Build Stage	x64	Post v.6.03	Expected availability: Q3 2009 Click Here		7000

VPN client

Release

Platform

Version

Download URL

More information

Tested on Windows 7 build

SSLVPN

Build Stage

x86

Post v.6.03

Expected availability: Q3 2009

Click Here

7000

SSLVPN

Build Stage

x64

Post v.6.03

Expected availability: Q3 2009

Click Here

7000

Juniper

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPSec VPN	Final	x86	6.5R1 or 6.5Rx	Expected availability: Q3 2009 Click Here	You must have a Juniper.net customer or partner user account. Contact a Juniper sales representative.	7000
SSL VPN	Final	x86	Not shared	Expected availability: Q3 2009 Click Here	You must have a Juniper.net customer or partner user account. Working with limited testing. Juniper’s QA has reported that there are no issues seen, both with upgrade and new install scenarios. For more information: Click Here	7000
	Final	X64		Not yet available	Contact a Juniper sales representative.

NCP

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPsec VPN	Beta	x86	9.12		Contact NCP or an NCP dealer representative.	7000
IPsec VPN	Beta	x64	9.12		Contact NCP or an NCP dealer representative.	7000
SSL VPN	Beta	x86	8	Expected availability: April 2009	Contact NCP or an NCP dealer representative.	7000
SSL VPN	Beta	x64	8	Expected availability: April 2009	Contact NCP or an NCP dealer representative.	7000

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.

VPN client	Router	Platform	Version	More information	Tested on Windows 7 build
IPSec	FVX538	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	FVS338	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	DGFV338	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	FVS336G	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	FVG318	x86, x64	V2.1.3-10	Expected availability: Sept 2009 Click Here	7000
IPSec	SRXN3205	x86, x64	V3.0.3-19	Expected availability: Sept 2009 Click Here	7000

Nortel

VPN client	Release	Platform	Version	Date	Download URL	More information	Tested on Windows 7 build
IPSec VPN	Beta	x86	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact your Nortel Representative	7000
IPSec VPN	beta	x64	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact your Nortel Representative	7000
SSL VPN	Beta	x86	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact your Nortel Representative	7000
SSL VPN	beta	x64	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact a Nortel Representative	7000

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.

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPSec Toolkit	Final	x86, x64	QuickSec	Expected availability: Q4 2009 Click Here	Click Here	7000

VPN client

Release

Platform

Version

Download URL

More information

Tested on Windows 7 build

IPSec Toolkit

Final

x86, x64

QuickSec

Expected availability: Q4 2009

Click Here

7000

Sonic Wall

VPN client	Release	Platform	Version	Date	Download URL	More information	Tested on Windows 7 build
IPsec VPN	Final	x86	4.2.6.0305	Beta Available	Click Here	You must have a mysonicwall.com user account to download.	7000
IPsec VPN	Final	x64	4.2.6.0305	Beta Available	Click Here	You must have a mysonicwall.com user account to download.	7000
IPsec VPN	Final	x86	4.0.0.830	10/8/2007	Click Here	You must have a mysonicwall.com user account to download. Requires reinstall after Windows upgrade. Upgrade advice will be shown to the user for this client version. Clean Installation works.

Issues, Resolutions, and Status

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

Client Application Name	VPN Vendor	Client Application Version	Known Issue	Solution
Cisco VPN Client	CISCO	5.0.05.0280	Blue screen crash on reboot after installation.	Fixed.
Secure Client	CheckPoint	NGX_R60_HFA2	Upgrade Issue - flag for block.	Not a regression. An upgrade notice is shown during upgrade because the client uses .NET class drivers which are not migrated during upgrade. Users can uninstall and reinstall after upgrade.
Citrix Access Gateway	Citrix	Citrix access gateway (CAG) client version 4603301	Citrix VPN Client is not giving IP address.	Reported on MS-Connect site for 64-bit version. Though we cannot currently reproduce this, our ISV engagement team is working work with Citrix to investigate the issue. Citrix has confirmed that their client works on clean installation. Citrix is in the planning/development stage for 64-bit.
Citrix Access Gateway	Citrix	Citrix access gateway (CAG) client version 4603301	CAG unable to complete connection setup and hangs while Applying Network Policy	Not a regression. An upgrade notice is shown during upgrade because the client uses .NET class drivers which are not migrated during upgrade. Users can reinstall (without having to first uninstall) after the upgrade.
Soft Remote	SafeNet	10.8.4 (32-Bit)	Failed to install adapter due to hard version check in the driver. The VA does not function properly.	Not a regression. An upgrade notice is shown during upgrade that this client application will not work as the client is supported on Windows Vista only. SafeNet’s IPsec toolkit called QuickSec is scheduled to support Windows 7 in 2009 Q4.
		11.1.2 (32-Bit)	While installing, qsfilter.sys crashes.
		11.1.2 (64-Bit)	Fails to install. due to a hard version check.
Global Network Client Managed VPN	AT&T	7.6.0.3005	Network access client does not work.	AT&T working on the fix. Not Windows 7specific issue
SonicWall Global VPN Client	SonicWall	4.0.0	Get an error: Failed to open the IPSec driver	Not a regression. Users can uninstall and reinstall after upgrade. Clean installation on works fine.
Secure Entry Client	NCP	8, 9.12	Version check issue	Fixed by NCP.

Smart Defaults for VPN Strategy and Authentication Protocol in CMAK

rrasblog — Thu, 09 Apr 2009 20:42:00 GMT

In W7 the CMAK wizard can be used to create CM profiles that can run on both Vista and W7 machines (a separate profile is still required for XP). When creating the profile if a VPN strategy or authentication protocol is specified which is not supported by Vista then CMAK automatically assigns default values for these settings for Vista. In this blog i will explain what these smart default values are

· If ‘Try IKEv2 only’ or ‘Try IKEv2 First’ VPN strategy is chosen then by default ‘Try SSTP first’ and ‘Try PPTP first’ are assigned for Vista SP1 and Vista RTM respectively

· With any of the VPN strategies if the authentication protocol chosen is EAP-MSCHAPv2 then by default MSCHAPv2 is assigned for Vista SP1 and Vista RTM

The above settings can be changed through the Advanced Customization option in the CMAK wizard

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

rrasblog — Wed, 25 Mar 2009 11:42:00 GMT

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.

3.3 Further Readings

Remote Access Deployment – Part 1: Configuring Remote Access Clients

Remote Access Deployment – Part 2: Configuring RRAS as a 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 Deployment – Part 2: Configuring RRAS as a VPN server

rrasblog — Wed, 25 Mar 2009 11:31:00 GMT

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.

2.8 Further Readings

Remote Access Deployment – Part 1: Configuring Remote Access Clients

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 Deployment – Part 1: Configuring Remote Access Clients

rrasblog — Wed, 25 Mar 2009 11:11:00 GMT

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 Design Guidelines – Part 1: Overview

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

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

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

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

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

rrasblog — Tue, 17 Mar 2009 14:50:00 GMT

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:

	Windows Firewall	RRAS Packet Filter	Comments
Type of Filtering	Stateful	Stateless	Applications which dynamically opens ports like RPC – requires stateful packet filtering
Enforcement point	All IP packets destined to or originated from the machine	Can be applied on a per-interface basis – like specific LAN interface (e.g. Internet interface), particular VPN client sub-interface	RRAS packet filtering is used during NAP enforcement to restrict unhealthy client to a specific quarantine zone
NAT support	Can co-exist with same machine working as NAT router	Cannot co-exist with same machine working as NAT router	NAT requires stateful packet filtering

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.

5.5 Further Readings

Here are the references to other relevant posts

Remote Access Design Guidelines – Part 1: Overview

Remote Access Design Guidelines – Part 2: VPN Client Software Selection

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

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

Remote Access Deployment – Part 1: Configuring Remote Access Clients

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 4: IP Routing and DNS

rrasblog — Tue, 17 Mar 2009 14:36:00 GMT

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.

4.4 Further Readings

Here are the references to other relevant posts

Remote Access Design Guidelines – Part 1: Overview

Remote Access Design Guidelines – Part 2: VPN Client Software Selection

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

Remote Access Design Guidelines – Part 5: Where to place RRAS 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

rrasblog — Tue, 17 Mar 2009 14:30:00 GMT

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.

Authentication Protocol**	VPN Client	Network Side
PEAP with inner method as EAP-smartcard EAP-smartcard	Smart-Card is populated with relevant user certificate and root certificate	Radius server is joined to domain, deployed with relevant machine certificate and the root certificate
PEAP with inner method as EAP-TLS (certificate on this computer) EAP-TLS (certificate on this computer)	User certificate store is populated with relevant certificate in “Personal” store and root certificate in “trusted root CA” store	Radius server is joined to domain, deployed with relevant machine certificate and root certificate
PEAP with EAP-MSCHAPv2	User or Machine certificate store is populated with root certificate in “trusted root CA” store. VPN client is configured with username/password	Radius server is deployed with relevant machine certificate and root certificate
EAP-MSCHAPv2 MSCHAPv2	VPN client configured with username/password	Radius server requires no certificate in this scenario.

** 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

Tunnel Type	OS support	Scenario	IP Addressing	Traversal	Mobility Enabled
PPTP	XP, 2003, Vista, WS08, W7, WS08 R2	Remote Access Site-to-Site	Works over IPv4 based Internet Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT via PPTP enabled NAT devices	No
L2TP/IPSec	XP, 2003, Vista, WS08, W7, WS08 R2	Remote Access Site-to-Site	Works over IPv4 as well as IPv6 based Internet Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT if configured for NAT-T	No
SSTP	Vista SP1, WS08, W7, WS08 R2	Remote Access	Works over IPv4 as well as IPv6 based Internet Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT, Firewalls, Web Proxy (as it uses TCP port 443)	No
IKEv2 (VPN Reconnect)	W7, WS08 R2	Remote Access	Works over IPv4 as well as IPv6 based Internet Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT if configured for NAT-T	Yes

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

Tunnel Type	Authentication	VPN Client Requirement****	Network Side Requirement****	Data Confidentiality
PPTP	User authentication via PPP*	None	None	RC4
L2TP/IPSec	Machine authentication via IPSec and** user authentication via PPP	Machine certificate store must be populated with the machine certificate in “Personal” store and the root certificate in “trusted root CA” store	RRAS server is deployed with machine certificate and the root certificate	DES, 3DES, AES
SSTP	User authentication via PPP*	Machine certificate store must be populated with the root certificate in “trusted root CA” store.	RRAS server is deployed with the machine certificate and the root certificate	RC4, AES
IKEv2 (VPN Reconnect)	User authentication via IKEv2***	Machine certificate store must be populated with the root certificate in “trusted root CA” store.	RRAS server is deployed with the machine certificate and the root certificate	3DES, AES
IKEv2 (VPN Reconnect)	Machine authentication via IKEv2***	Machine certificate store must be populated with relevant machine certificate in “Personal” store and the root certificate in “trusted root CA” store	RRAS server is deployed with the machine certificate and the root certificate	3DES, AES

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.

3.7 Further Readings

Here are the references to other relevant posts

Remote Access Design Guidelines – Part 1: Overview

Remote Access Design Guidelines – Part 2: VPN Client Software Selection

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

Remote Access Design Guidelines – Part 5: Where to place RRAS 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 2: VPN client software selection

rrasblog — Tue, 17 Mar 2009 14:14:00 GMT

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:

Feature	In-Built VPN client	CM VPN client
Creation	On the client device – using ``Network and Sharing Center” – usually done by end users	On network side – using CMAK tool – usually done by administrators
Change	Entire configuration can be changed by end user – using VPN client ``Properties”	Minimal configuration change possible by end user – using CM. However administrator can change the profile – using CMAK and then send back to end users
IPV4, IPV6 Support	Both	Both
Authentication & Tunnel Selection	All	All – though tunnel selection order is fine-grained in CMAK – with additional options of PPTP first, L2TP first and SSTP first.
NAP Support	Supported	Supported
Multiple VPN servers	Partially allowed – only one host name*** or IP address of VPN server can be configured.	Allows a list of VPN servers to be provisioned and end user can select one from the drop-down
IP Routes	Ability to select default route addition on client machine after VPN interface comes up	Allows a list of IP routes (including default route) to be provisioned on client machine after VPN interface comes up
Web Proxy Address	Not allowed – user need to explicitly configure intranet web proxy address inside IE for the VPN interface	Allows web proxy address to be provisioned inside CM package. This will be configured inside IE after VPN interface comes up
Customization	Not allowed	Allows icons, help message text, pre connect and post connect code to be added to the VPN package

*** 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.

2.3 Further Readings

Here are the references to other relevant posts

Remote Access Design Guidelines – Part 1: Overview

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

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

Remote Access Design Guidelines – Part 5: Where to place RRAS 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 1: Overview

rrasblog — Tue, 17 Mar 2009 14:04:00 GMT

Hello Customers,

In last few releases, we have added plenty of “cool” features in RAS – like NAP based health check, SSTP based SSL tunnel, IPv6 support in Vista SP1/WS08 and IKEv2 based IPSec tunnel in Windows 7/WS08 R2.

As a result, we have seen a lot of interesting questions from you- about various design and deployment choices that exists, which one to choose what, when etc.

In the next few posts, I will walk you through some of the questions that comes in when you designing your remote access solution. The answer to these questions will help you to make informed decisions and make correct choices when deploying RAS based remote access solution.

Once I finish on these posts on the design side, I will go through configuration and day-to-day management of RAS.

As always, I will love to hear back from you – your comments/thoughts/need for more articles, etc.

So lets start the journey. Here is my first post on this topic

1.1 Overview

VPN based remote access solution is used to provide access to users connecting network resources over public network. For example, all sizes of companies deploy VPN server at their edge. The employees who work@home or on road connect to the VPN server from their PCs/laptops over Internet. This process establishes a VPN tunnel that virtually places their client PCs/laptops inside intranet and they can now access the intranet resources.

A remote access solution includes multiple devices– the remote access client devices (PCs, laptops, smart mobile), the remote access server or VPN gateway, network policy server (Radius server), authentication directory or database (Active directory), DHCP server and DNS server.

My coming posts will be broken in different sections that will assist you in choosing between the various options that may exist in your deployment scenarios and answer some of the important design questions that you may have while choosing those options:

Which VPN client software to use on the remote access devices?
Which VPN tunnel and authentication protocol to use?
How to enforce different authorization policies?
How to enforce health check of the remote access user devices before providing access to the network? How to restrict the unhealthy clients to a quarantine zone?
What should be the IP subnet that should be allocated to VPN clients? How will the IP routing happen between VPN clients and rest of the network? How will the VPN clients access Internet?
Where to place the firewall on the VPN server side. Which TCP/UDP ports must be opened to allow VPN tunnels to come in?
How to provide a high availability solution to the remote access server?

1.2 Definition

Few definitions which I will be referring in my coming posts:

Term	Description
DHCP Relay Agent	A VPN server acts as an IP router – forwarding IP packets between VPN clients and rest of intranet machines. To forward DHCP inform requests (for parameters like DNS server address) originated by VPN clients towards the DHCP server on intranet side, DHCP relay agent need to be enabled on VPN server. DHCP relay agent and VPN client supports both the IPv4 and IPv6 transport.
Intranet	Machines sitting on private network side – behind VPN server – that are accessed by VPN client over the VPN tunnel – like file servers, web servers, business application servers etc.
Internet	Machines facing public internet – like the VPN servers.
Remote Access	Technology that enables remote access users to access their remote network – using different technologies like dial-up, VPN etc
Remote access user	User that accesses the remote network using VPN client
RRAS	Routing and Remote Access Service – a server role that is part of Network Policy and Access server role inside Windows based server.
VPN	Virtual Private Network – technology that enables remote access users to access their remote network (like office network) over a public network (like Internet)
VPN client	Client software that enables remote access user to connect to their remote network – initiator or originating endpoint of VPN tunnel
VPN server	Server software (e.g. RRAS server) that enables remote access user to connect to their remote network – terminating endpoint of the VPN tunnel.

1.3 Further Readings

Here are the references to other relevant posts

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

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

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

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

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

Change in username format to UTF8 to handle International Characters

rrasblog — Fri, 13 Mar 2009 16:06:00 GMT

As the usage of non-English languages in usernames becomes more and more popular it is important to use the right kind of format for the characters so that the entire character set in these international languages is correctly represented. In Vista/LH ANSI format was used for usernames. ANSI can only represent characters in the 0-127 character set correctly. Extended characters (128-255) are not represented correctly by ANSI. To support complete internationalization the NPS (Microsoft RADIUS server) in Win2K8 R2, by default, expects the characters in the username to be in the UTF-8 format for all authentication protocols. As a result of this change RAS connections from W7 and older RAS clients could fail in certain scenarios, if a Win2K8 R2 NPS is used for authentication. Following are the details of the scenarios that will fail and the workaround to solve the problem

1. The client is running a version of Windows older than Windows 7 and is using Extensible Authentication Protocol (EAP). Windows 7 clients are not affected because by default RAS client in Windows 7 uses UTF-8 format for EAP-based authentication protocols

2. The client is running any version of Windows and is using a non-EAP authentication protocol. This is because the RAS client on Windows 7 and earlier versions of Windows uses only ANSI format for non-EAP authentication protocols

The above problems can be solved by configuring the NPS to accept ANSI format instead of UTF-8. This can be done by setting a registry key.

a) Click Start, click Run, type regedit, and then click OK.

b) Locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\Configuration

c) Click Edit, click New, and then click DWord Value.

d) Type IdentityEncodingFormat, and then press ENTER.

e) Click Edit, click Modify, type the value 0x1, and then click OK.

f) Exit the Registry Editor.

The above configuration change would however result in EAP-based authentication from a Windows 7 client to fail. To fix this case, the same registry key (shown above) can be set on the Windows 7 client so that the Windows 7 client uses ANSI format for EAP-based authentication protocols too.

If you have a mix of remote access clients, you can use this registry setting to configure all servers and clients to use ANSI until you can upgrade all of the clients to a version of Windows that supports UTF-8 for the authentication methods you need to use.

Aanand Ramachandran

Program Manager, RRAS

VPN tunnel strategy - defining the connection order between various tunnel types

rrasblog — Wed, 11 Feb 2009 11:54:00 GMT

Hello Customers,

As I wrote in this blog, there are four types of VPN tunnel supported by Windows 7 based VPN clients. In this blog I will focus on following things: how do you configure tunnel types on the client, how to decide on the tunnel type order while establishing connection, ...

Lets understand why multiple tunnel types are required. The following factors impact which tunnel gets used for the VPN connection:

· What is the tunnel type supported (at the OS level) and configured at both ends i.e. VPN client and VPN server?

· Is there any intermediate agents (like firewalls, NAT, proxies) between both ends - which can block a given tunnel type?

· What is the tunnel strategy (which I will discuss in this document) configured on the client side

Our recommended tunnel types for Windows 7 and above OS clients are IKEv2 followed by SSTP. And as an admin, you must be wondering – how do you migrate your existing PPTP or L2TP/IPSec users to IKEv2 followed by SSTP based deployment because you must be having clients with different OS versions thereby supporting specific tunnel types, you may have different VPN servers which needs to be migrated, etc. This is precisely the scenario where you can use the VPN tunnel strategy feature on the client side which helps you to specify the order in which VPN tunnels are tried – till a given tunnel is able to successfully connect to the VPN server.

There are two types of VPN client supported inside Windows OS:

· In-built Microsoft VPN client that is created using “Setup a connection or network” in “Network and Sharing Center”. This is also called as GCW client (get connected wizard). This is normally done by end-users.

· Connection Manager (CM) client created using Connection Manager Administration Kit (CMAK). This is normally created by administrators and then shared to end users via email or upload to a file server or a web server.

Note: There may be VPN clients built by 3^rd party vendors. These 3^rd party VPN clients can be of two types – first one which calls Microsoft VPN client stack using RAS APIs and second one who install their entire VPN client stack on Windows OS. For sake of simplicity, I am not discussing the behaviour of VPN tunnel strategy by 3^rd party clients.

Now let us see how the tunnel strategy feature works for both types of clients:

· Using in-built VPN client, you can configure following types of tunnel strategy - going inside Connection Properties -> Security tab -> Type of VPN

o Automatic: Try IKEv2 first – if that fails try SSTP next – if that fails try PPTP next - if that fails try L2TP/IPSec last. If that fails – stop connection establishment and report error.

o PPTP: Try PPTP and if that fails – stop connection establishment and report error.

o L2TP/IPSec: Try L2TP/IPSec and if that fails – stop connection establishment and report error.

o SSTP: Try SSTP and if that fails – stop connection establishment and report error.

o IKEv2: Try VPN Reconnect and if that fails – stop connection establishment and report error.

· While creating the CM client, the admin can configure following types of tunnel strategy using CMAK

o IKEv2 first: Try IKEv2 first – if that fails try SSTP next – if that fails try PPTP next - if that fails try L2TP/IPSec last. If that fails – stop connection establishment and report error.

o IKEv2 only: Try VPN Reconnect and if that fails – stop connection establishment and report error.

o SSTP first: Try SSTP first – if that fails try IKEv2 next – if that fails try PPTP next - if that fails try L2TP/IPSec last. If that fails – stop connection establishment and report error.

o SSTP only: Try SSTP and if that fails – stop connection establishment and report error.

o PPTP first: Try PPTP first – if that fails try IKEv2 next – if that fails try SSTP next - if that fails try L2TP/IPSec last. If that fails – stop connection establishment and report error.

o PPTP only: Try PPTP and if that fails – stop connection establishment and report error.

o L2TP first: Try L2TP/IPSec first – if that fails try IKEv2 next – if that fails try SSTP next - if that fails try PPTP last. If that fails – stop connection establishment and report error.

o L2TP only: Try L2TP/IPSec and if that fails – stop connection establishment and report error.

Please note:

· For a given VPN tunnel type, let us say the tunnel establishment phase succeeds but the entire VPN connection fails - due to authentication issue OR IP address negotiation issue. This doesn’t mean VPN client will try the next tunnel type based upon the tunnel strategy. The VPN client tries different tunnel types only if the tunnel establishment fails. This can happen because VPN server is not configured/supports given tunnel type OR packets for a given tunnel type are getting dropped.

· The time it takes to try next tunnel – varies between each tunnel – based upon the retries. For example, IKEv2 tunnel sends 3 retries for first IKEv2 packet spaced at 1, 2 and 4 seconds – hence it will take atleast 7 seconds before next tunnel type is tried. SSTP tunnel takes 10-20 seconds (depending upon the connection is going through a proxy enabled for WPAD or not) to detect failure. And so on.

· If a given tunnel is reachable via IPv4 as well as IPv6 and VPN client is configured with “hostname” of VPN server, then both IPv4 and IPV6 addresses are tried before trying the next tunnel type as given in VPN strategy.

· For in-built VPN clients, the last successful VPN tunnel type is tried next time for “Automatic” tunnel type and if that fails it follows the order (as given above) again. However for CM based VPN clients, every VPN connection tries the same order.

Now let us take some deployment scenario:

· Assume you have WS2003 VPN servers configured for PPTP and have different VPN users (XP, Vista, Windows 7). And you plan to move users to IKEv2 and SSTP tunnel scenario. You can follow this deployment plan:

o Upgrade all your VPN servers to Windows 7 Server and configure PPTP, SSTP and IKEv2 on the server side.

o Create different CM package for XP and Windows 7. In the XP package give PPTP only as the VPN Strategy and in W7 package give IKEv2 first as the VPN strategy. Note: W7 package if installed on Vista machine automatically switches to SSTP first (as IKEv2 is not available on Vista).

o Send the XP package to XP users and W7 package to Vista + W7 users. And you are all set.

· Now as part of deployment plan – you may want to upgrade your VPN servers one-at-a-time. In that case at some point you may be having WS2003 (enabled for PPTP) and Windows 7 server (enabled for PPTP, SSTP, IKEv2) running at the same time. This may mean any client (XP, Vista, Windows 7) may connect to either of the VPN Servers. It should not be a connectivity establishment problem with the above CM package – however Windows 7 users may face “longer connection establishment time” (like 30 seconds) if they connect to Windows 2003 VPN servers as it tries IKEv2 followed by SSTP followed by PPTP.

To summarize, the VPN tunnel strategy helps your VPN client to try different tunnel types in a given order and thereby helping you to migrate your remote access users to newer secured tunnel types. Hope this blog helps you in that direction.

For further references:

Different VPN tunnel types in Windows

How automatic tunnel types work in Vista

Frequently asked Questions on IPv6 support of RAS

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

How to change certificate on SSTP server - in Windows server 2008 R2

rrasblog — Wed, 11 Feb 2009 09:38:00 GMT

Hi Folks,

Very soon Windows 7 and Windows Server 2008 R2 will be released and it is very exciting that beta version of these new operating system is available for public download. So, go ahead and start using it and provide your valuable feedback to us.

In this blog I will talk about a new feature in RRAS for SSTP tunnel. In WS08, we added SSTP tunnel as a new VPN tunneling mechanism which allow enterprises to have the VPN available even though the user [remote access client] is behind the firewall or NAT device. This eases lot of deployment and support calls wherein the users were not able to connect to the enterprise due to firewall\NAT related issues.

Currently, SSTP by default picks up a certificate available in the cert store and do the SSL binding of the same and cache that information to do the crypto biding for inbound connection. This certificate selection by SSTP is not very intuitive for administrators, as administrator does not know which certificate is currently used by SSTP as there is no display available, also it does not provide a mechanism to the RRAS administrator to select specific certificate for the SSL binding by the SSTP. In case of mismatch between SSL binding and Crypto hash, SSTP will not function properly.

To enhance the deployment ease, we have provided UI and net shell interface to handle the certificate selection to the user, here is the new scenario\behavior.

To be able to see the certificate selection UI, please do the following steps: Open the rrasmgmt.msc, select the targeted server and right click. Click on the properties option, this will open a tab based dialog box, select the Security Tab. In the Security tab, you will see the SSL certificate binding option at the bottom of the page as illustrated in pic 1. Administrator selects one of the provisioned certificates for SSL binding here on this page, Refer to the UI below. RRAS UI picks up and displays the valid certificates in the Certificate drop-down menu from Local M\c personal cert store. User can check currently provisioned certificate using certificate snap-in the WS08 R2. Once user selects\configures a certificate, UI will prompt for restarting the Remote access service (including SSTP service). SSL (SSTP service) binds to selected certificate once remote service is restarted. If remote access service is not running then binding will take place whenever remote access (SSTP service in particular) comes up.

Pic. 1 Certificate Selection UI

Note 1: In case of default certificate selection in the drop down menu, SSTP service will pick a certificate from the local computer personal store and do the binding.

Note 2: In case if the currently SSL is bound to some certificate and that binding is done by some other application, UI will throw an error as illustrated in Pic 2. Administrator needs to correct this anomaly manually. Please see the netsh commands to see\delete\add the SSL binding in the netsh section below. There are 3 ways to fix it.

a) Let the other application also use the same certificate as used by SSTP

b) Choose the same certificate as used by the other application.

c) Choose default option in the drop down menu.

Pic 2: Error Dialog in case of certificate mismatch

Note 3: In case when the selected certificate is deleted after the SSTP is configured by admin, when admin open the security tab, an error will be thrown stating that the certificate is missing as shown in Pic 3.

Pic 3: Error Dialog in case of certificate is deleted after configuring SSTP

With this UI, we also support configuration for SSTP in reverse proxy scenario. This can be done by having the check box “Use Http” checked. This configures SSTP to receive the plain HTTP packet as SSL is offloaded to proxy. In this case, user needs to manually configure the Certificate Hash in the registry manually, as done in Windows Server 2008

RAS administrator can also use net shell command to do the same thing (selecting the certificate). Behavior is same as described above.

· Each time remote access service is started SSL will bind to certificate configured (in RAS) if any. If certificate configured is not present in cert store then RRAS will cleanup the SSL cert binding. An ERROR event (Shown below) will also be logged in this case.

· SSTP service would continue to bind the certificate for both IPV4 & IPV6. This behaviour is same as LH. It is irrespective of whether administrator has selected the certificate or the certificate is chosen based on existing logic (SSTP logic of selecting certificate from store) or choosing the same certificate as current SSL binding (If SSL is already bound by some other web server applications).

While Configuring the certificate for SSL binding if the SSL binding already exist with some other cert by some application, UI\Netsh will inform the user about the mismatch so that user can select some other cert or remove the incorrect existing binding using the netsh command

Netsh Command to configure the cert for SSTP:

Netsh ras set sstp-ssl-cert name=<Cert Name>

Netsh ras set sstp-ssl-cert hash=<Cert SHA-1 hash>

Netsh Command to see the current configured cert for SSTP:

netsh ras show sstp-ssl-cert

Netsh command to see and delete the current SSL binding:

netsh http show sslcert

netsh http delete sslcert ipport=<v4\v6 Address>:443

With Regards,

Dhiraj Gupta

Software Design Engineer

Windows Networking Group

Do we still need PPTP & L2TP/IPsec after Windows 7

rrasblog — Tue, 10 Feb 2009 14:40:00 GMT

Hi Folks,

Our team member Samir Jain has posted a nice blog on how you should decide which tunnel to use/deploy for your scenario. The details for the same are given at which tunnel to use.

In this blog, I would like to understand further on a possibility of deprecating PPTP & L2TP/IPsec VPN tunnels going forward - i.e. after Windows 7. This leaves in-the-box Microsoft VPN component supporting SSTP (SSL based ) and IKEv2 (IPsec based) VPN tunnel.

Please do not panic ! This has not happened yet. I am just trying to get your feedback and learn more about your deployment plans going forward.

Why do I think you should migrate to IKEv2/SSTP?

IKEv2 (VPN Reconnect) is a standard based tunnel that should work with any third party servers so interoperability should not be any less if compare to PPTP or L2TP. SSTP allows SSL based firewall traversal thereby supporting ubiquitous VPN connectivity.

Both tunnels are on par or better with L2TP/IPsec as well as PPTP - in terms of security, performance, connection establishment experience etc.

IKEv2

1. Does not require client side PKI deployment or pre-shared key.

2. Integrates well with all EAP based methods

3. Leverages the security strength provided by IPsec

4. Better in connectivity time compare to L2TP/IPsec

5. Provide mobility switchover support (mobility manager)

Windows 7 & WS08 R2 onwards

SSTP

1. Does not require client side PKI deployment or pre-shared key.

2. Integrates well with all EAP based methods

3. Leverages the security strength provided by SSL protocol

4. Provides firewall traversal

Vista SP1 & WS08 onwards

Why we would like to deprecate PPTP/L2TP?

1. Enables better usability (less # of tunnel choices confusing admins) & better troubleshooting/diagnostics support

2. Reduces the support: Reduces the footprint and the number of updates.

3. Better focus from Microsoft: Our development team can focus mainly on these two tunnels and focus on improving the remote access connectivity experience.

I do understand that PPTP is a highly deployed VPN tunnel followed by L2TP/IPSec and Windows 7 will take sometime before it is wide-spread inside organizations (like XP is today). However, we do feel announcing now and deprecating PPTP/L2TP after Windows 7 would have provided ample time to our customers to migrate to SSTP (Vista SP1 & WS08 onwards) and IKEv2 (available Windows 7 & WS08 R2 onwards).

Again - to re-iterate, there is no official plan in this direction and this blog post is purely a feedback gaining mechanism to hear from our enthusiastic remote access customers about their deployment and migration plans to our newer OS supporting exciting new VPN tunnels.

Please share your feedback - either as comment or by sending us an email.

Looking forward to hear back from you

Cheers,

Abhishek Tiwari

Senior Lead Program Manager, RAS Team,

Windows Networking

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

RRAS Performance results

rrasblog — Mon, 09 Feb 2009 14:06:00 GMT

Hello Customers,

A lot of you have requested directly or through the field channels about performance results of RRAS for different VPN tunnel types – specifically SSTP. I am writing this blog to share the results for the tests done internally by our test team (thanks Sai and other test team members).

First, a few guidelines to help you better interpret the test and results:

· The main goal of this performance test is to validate a target VPN server deployment in terms of the performance requirements i.e. x number of simultaneous VPN connections doing y Mbps of aggregated data transfer on a specific hardware.

· The number of simultaneous VPN connections and aggregated VPN server throughput that we have used in the test are some of our internal benchmark numbers – based upon our understanding of common customer deployment scenarios of RRAS. This by no means is the only deployment scenario of RRAS.

· The performance numbers without hardware specification is meaningless. Hence, we have shared the details of server hardware used in our performance lab. However, this should not be read as Microsoft recommended hardware platform for RRAS.

· All our tests are done inside our lab environment which means minimal delay (< 10msec) and close to zero % data loss. You may say that is not close to real deployment. And the way I see this – the delay and loss may change the data throughput numbers as experienced by a VPN client for a given tunnel type. However delay and loss doesn’t drastically change the aggregated throughput as seen on VPN server and our focus has been on VPN server performance – hence this set-up.

· This blog is focussed on Windows server 2008 as the VPN server and performance is compared between PPTP and SSTP. I will extend this blog with Windows 7 results shortly – including results for “VPN reconnect” or IKEv2 based VPN tunnel.

Setup:

· 1 VPN server: HP DL 165 G5 server with two AMD Opteron™ 2352 Quad Core Processor 2.10 GHz, 16GB RAM, two 1 Gig Ethernet port – running Windows server 2008 released version.

· 10 machines - code changed to emulate n VPN client connections per machine. Each of these machines are running internal tools to manage VPN connection management and generated data load.

· All machines connected on a Gigabit Ethernet switched network.

Performance Test 1:

· Generate 100 Mbps data load using 1000 VPN clients. Measure the average CPU utilization on the VPN Server.

Tunnel Type

Average CPU usage (sum of CPU usage per core/no of core) – in %

Data Throughput (on VPN server) – in Mega bits/sec

PPTP

13.23

100

SSTP

33.65

100

Performance Test 2:

· Generate maximum data load from a single VPN client connection. Measure the aggregate data throughput and average CPU utilization on the VPN server

Tunnel Type	Average CPU usage (sum of CPU usage per core/no of core) – in %	Maximum Data Throughput (on VPN server) – in Mega bits/sec
PPTP	40.29	644.78
SSTP	71.44	685.96

Performance Test 3:

· Generate a constant background data load (0, 25 Mbps, 100 Mbps) using 1000 VPN clients and in parallel start a 580 Mega byte file transfer from one of the VPN client to machine behind VPN Server. Measure the file transfer time and average CPU utilization on the VPN Server.

Tunnel Type	Average CPU usage (sum of CPU usage per core/no of core) – in %	Time taken to transfer 580 MB file - in seconds
PPTP with 0 Mbps of traffic	26.42	14
PPTP with 25 Mbps of traffic	27.24	20
PPTP with 100 Mbps of traffic	33.08	30
SSTP with 0 Mbps of traffic	30.38	13
SSTP with 25 Mbps of traffic	40.91	18
SSTP with 100 Mbps of traffic	61.22	18

I hope that the above performance results helps you better understand and evaluate RRAS performance and do capacity planning for your deployment.

The performance measurement is a difficult field with various factors affecting numbers. My recommendation is to evaluate the performance in view of your WAN bandwidth of VPN server and number of clients connecting to it – as these parameters are closest and most important to a practical deployment. I will like to hear back from you, so feel free to send in your comments on this blog or send us email to our blog link as mentioned above.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

Deploying VPN Reconnect: Step-by-step guide available at

rrasblog — Sun, 01 Feb 2009 19:46:00 GMT

Folks,

The deployment guide for VPN Reconnect is now available at

http://download.microsoft.com/download/8/9/0/890C2C54-EE49-4743-A5B0-1F3AD7C36721/Step-by-Step_Deploy_Remote_Access_with_VPN_Reconnect.doc

The guide covers the various requirements for deploying VPN Reconnect and detail steps to configure the various Network Elements. If you have any questions please feel free to post them on this blog or email rrasblog

regards

Aanand

Tunnel Type	Average CPU usage (sum of CPU usage per core/no of core) – in %	Data Throughput (on VPN server) – in Mega bits/sec
PPTP	13.23	100
SSTP	33.65	100