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.