Routing and Remote Access Blog

Provisioning VPN client settings using Group Policy

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

Troubleshooting common VPN related errors

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

2) Error Code: 609, 633

3) Error Code: 732, 734, 812

4) Error Code: 806

5) Error Code: 789, 835

6) Error Code: 766

7) Error Code: 691

8) Error Code: 809

9) Error Code: 13806

10) Error Code: 13801

11) Error Code: 0x800704C9

12) Error Code: 0x80070040

13) Error Code: 0x800B0101

14) Error Code: 0x800B0109

15) Error Code: 0x800B010F

16) Error Code: 0x80092013

17) Error Code: 0x800704D4

18) Error Code: 0x80072746

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

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

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

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

How network load balancing cluster enhances scalability of vpn server?

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

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

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

How to configure a NLB cluster?

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

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

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

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

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

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

Install & Configure NLB in vpn-servers:

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

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

a) Add new host to the cluster:

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

b) Host parameter configuration:

c) Configuring the cluster parameter

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

d) Configuring Port Rules:

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

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

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

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

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

a) Add new host to the cluster

b) Host parameter configuration

c) Configuring Port Rules

d) Configuring load weight for the host

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

Verification after configuring nlb cluster for vpn server:

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

8. Give nlb drainstop on vpn-server1.

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

10. Give nlb drainstop on the vpn-server2.

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

12. Give nlb start.

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

With Regards,

Anupam Chakraborty (SDET, Windows Networking)

SSTP support on Forefront TMG server

Hello Customers,

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

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

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

What type of certificate to install on the VPN server

Hello Friends,

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

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

Here are the steps you need to follow:

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

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

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

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

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

For L2TP/IPSec: No other configuration is required

For IKEv2 EAP authentication: No other configuration is required

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

Hope this posting helps you select the right certificate

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

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

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

Hello All,

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

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

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

Configuring F5 BIGIP

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

Configuring RRAS as SSTP VPN server

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

Testing

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

References

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

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

when HTTP_REQUEST {

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

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

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

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

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

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

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

pool SSTP-Pool

# disable the HTTP profile for the rest of the connection

HTTP::disable

} else {

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

drop

}

}

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

Cheers,

Samir Jain

Senior Program Manager

Windows Networking

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

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

Hello Friends,

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

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

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

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

We sincerely appreciate your feedback.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

Enhancements to VPN Reconnect in W7 RC

Hello Folks,

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

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

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

1.       Change in method used to calculate MSK

Details of Enhancement

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

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

Impact

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

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

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

Details of Enhancement

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

Deployment Recommendation

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

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

           being validated by the client.

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

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

           store. The latter is highly recommended

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

Impact/Troubleshooting Tips

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

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

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

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

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

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

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

Notes

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

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

·      AT&T

·      Checkpoint

·      CISCO

·      Citrix

·      F5

·      Juniper

·      NCP

·      NetGear

·      Nortel

·      SafeNet

·      Sonic Wall

Ashish Jain

Program Manager

Routing and Remote Access

AT&T

Checkpoint

CISCO

Citrix

F5

Juniper

NCP

NetGear

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

Nortel

SafeNet

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

Sonic Wall

Issues, Resolutions, and Status

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

Smart Defaults for VPN Strategy and Authentication Protocol in CMAK

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

Aanand Ramachandran

Program Manager, RRAS

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

Hello Customers,

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

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

3.1 Installation of server role

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

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

3.2 Configuration of Radius server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello Customers,

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

5.1 NAT Routers

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

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

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

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

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

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

5.2 Packet Filtering

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

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

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

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

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

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

5.3 Single NIC scenario

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

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

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

5.4 Load Balancing and High availability

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

5.4.1 DNS Round robin

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

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

However, this mechanism has some limitations:

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

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

5.4.2 Network Load Balancing

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

For further details, refer to this article.

5.4.3 SSL Load Balancers (only for SSTP)

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

Advantage of this approach:

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

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

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