This blog is going to tell about how SSTP can be affected by configuring IIS Server on the same Server and how to get rid of this problem without moving the IIS Server to a different machine.

Let's us first know what kind of issue can arise if IIS is configured alongwith SSTP on the same server.

Let's say that SSTP is configured on the Server using a Server Authentication Certificate (SAC). The IP:Port binding will look like as follows:-

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

-------------------------

    IP:port                 : 0.0.0.0:443

    Certificate Hash        : 3f399643ac981dd68726e4d99f90f7c5a349498a

    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name  : MY

    Verify Client Certificate Revocation    : Enabled

    Verify Revocation Using Cached Client Certificate Only    : Disabled

    Usage Check    : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout   : 0

    Ctl Identifier          : (null)

    Ctl Store Name          : (null)

    DS Mapper Usage    : Disabled

    Negotiate Client Certificate    : Disabled

    IP:port                 : [::]:443

    Certificate Hash        : 3f399643ac981dd68726e4d99f90f7c5a349498a

    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name  : MY

    Verify Client Certificate Revocation    : Enabled

    Verify Revocation Using Cached Client Certificate Only    : Disabled

    Usage Check    : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout   : 0

    Ctl Identifier          : (null)

    Ctl Store Name          : (null)

    DS Mapper Usage    : Disabled

    Negotiate Client Certificate    : Disabled

----------------------------------------------

The SSTP based connections from the client to this Server will go fine.

Now, the admin decides to configure an HTTPS site using IIS Server on the same server machine using the same Certificate SAC which is used for SSTP.

IIS7 gives an option to bind a particular Certificate to the HTTPS site in the UI. However this binds the certificate only to the IPv4 listener i.e. 0.0.0.0:443 and not to the IPv6 listener [::]:443. This works fine for both IPv4 and IPv6 based access to the HTTPS site published because IIS uses the same certificate which is bound to IPv4:443 for IPv6 address based access also.

However, SSTP requires that the certificate bound to both the listeners be the same.

So, based on the above fact, admin binds the Certificate SAC to 0.0.0.0:443 which will try to do a fresh binding to the 0.0.0.0:443 with the same certificate SAC which was already done by SSTP. This will not disturb the Certificate binding to 0.0.0.0:443 and [::]:443.

So, the HTTPS site access using IPv4/IPv6 address and SSTP connection will go fine.

So far, everything is fine.

Now, admin decides to remove this published HTTPS site or wants to bind it to a different Certificate. This will result in the removal of the Certificate SAC binding from 0.0.0.0:443 by IIS, as it assumes that it is the only application which is using it. So, the IP:Port binding at this point will look like as follows:-

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

-------------------------

    IP:port                 : [::]:443

    Certificate Hash        : 3f399643ac981dd68726e4d99f90f7c5a349498a

    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name  : MY

    Verify Client Certificate Revocation    : Enabled

    Verify Revocation Using Cached Client Certificate Only    : Disabled

    Usage Check    : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout   : 0

    Ctl Identifier          : (null)

    Ctl Store Name          : (null)

    DS Mapper Usage    : Disabled

    Negotiate Client Certificate    : Disabled

----------------------------------------------

As you would notice above, the binding of the Certificate to 0.0.0.0:443 is gone. Now, if the admin tries to make an SSTP based connection using IPv4 address of this Server from a client, it will FAIL. The reason behind it is that, in the SSL phase, the Server will not find any certificate bound to the IPv4:443 (which is 0.0.0.0:443) and so, it will fail.

Solution for this problem:-

----------------------------------------------

If both SSTP and IIS are configured on the same server using the same certificate and if the HTTPS site needs to be removed, the admin needs to follow the below procedure :-

Step 1) Remove the HTTPS site from the IIS.

Step 2)

Case 1:- Server has only one Server Authentication Or All Purpose Certificate in the store:-

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

reg delete HKLM\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA256CertificateHash /f

net stop sstpsvc /y

net start remoteaccess

Case 2:- Server has more than one Server Authentication Or All Purpose Certificate in the store:-

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

reg delete HKLM\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA256CertificateHash /f

netsh http add sslcert ipport=0.0.0.0:443 certhash=<SAC2 Cert Thumbprint> appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

netsh http add sslcert ipport=[::]:443 certhash=<SAC2 Cert Thumbprint> appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

net stop sstpsvc /y

net start remoteaccess

<SAC2 Cert Thumbprint> : This value is present in the Certificate itself. To get this value, open the certificate by double clicking on it in the store and go to "Details" tab. Under it, there are multiple "Field" and "value" pair. Go to the last of this list. You will find something like this:-

Thumprint                      f8 3e 90 44 82 02 69 e6 98 07 2e 19 88 0d 30 84 06 89 a1 f9

Pick this value and remove the spaces in between. After that, it will look like

f83e9044820269e698072e19880d30840689a1f9

Use this value in place of <SAC2 Cert Thumbprint> as below

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

reg delete HKLM\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA256CertificateHash /f

netsh http add sslcert ipport=0.0.0.0:443 certhash=f83e9044820269e698072e19880d30840689a1f9 appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

netsh http add sslcert ipport=[::]:443 certhash=f83e9044820269e698072e19880d30840689a1f9 appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

net stop sstpsvc /y

net start remoteaccess

After executing the above mentioned command, the IP:Port binding will look like before as follows:-

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

-------------------------

    IP:port                 : 0.0.0.0:443

    Certificate Hash        : 3f399643ac981dd68726e4d99f90f7c5a349498a

    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name  : MY

    Verify Client Certificate Revocation    : Enabled

    Verify Revocation Using Cached Client Certificate Only    : Disabled

    Usage Check    : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout   : 0

    Ctl Identifier          : (null)

    Ctl Store Name          : (null)

    DS Mapper Usage    : Disabled

    Negotiate Client Certificate    : Disabled

    IP:port                 : [::]:443

    Certificate Hash        : 3f399643ac981dd68726e4d99f90f7c5a349498a

    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name  : MY

    Verify Client Certificate Revocation    : Enabled

    Verify Revocation Using Cached Client Certificate Only    : Disabled

    Usage Check    : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout   : 0

    Ctl Identifier          : (null)

    Ctl Store Name          : (null)

    DS Mapper Usage    : Disabled

    Negotiate Client Certificate    : Disabled

----------------------------------------------

Now, the SSTP based connections will go fine.

Thanks,

Amit Kumar

Software Design Engineer/Test,

Enterprise Networking Group, Microsoft.

Hello,

As you know in Windows server 2008 (WS08) we have removed “Basic Firewall” functionality in RRAS which exist in Windows Server 2003 (WS03). 

This leads to following security implications which you should be carefully consider when configuring RRAS on WS08:

1)      If you were running WS03 enabled for RRAS as a VPN server with inbound/outbound filters and you upgrade to WS08, after update:

a.       You don’t need to do anything extra in terms of RRAS inbound/outbound filter configuration (i.e. all your RRAS inbound/outbound filter settings will get migrated from WS03 to WS08)

b.      WS08 will be turned on with Windows firewall. Now you have two packet filtering engines that are enabled (RRAS inbound/outbound filters AND Windows Firewall). Read [1] to understand the differences between the two and in which scenario to use which one.

2)      If you were running WS03 enabled for RRAS as a NAT router with “Basic Firewall” and you upgrade to WS08, after upgrade:

a.       Manually turn on Windows Firewall (Note: This happens because in WS03, Windows firewall will be turned off as RRAS was enabled with Basic Firewall; and Basic firewall is removed in WS08). Open Windows Firewall clicking on Start->Control Panel->Windows Firewall->Change Settings. Click on “On”

b.      Validate all the “exemptions” that are added inside Windows firewall.  As Windows firewall settings are global to the machine, all the ports that are opened as exemptions will be visible from pubic as well as private NICs of RRAS. 

In case of RRAS, following ports are opened to allow traffic from remote access users using different forms of VPN tunnels:

                TCP Port 1723: PPTP control traffic

                IP Protocol 47: PPTP data (GRE) traffic

                UDP Port 1701: L2TP traffic

                UDP Port 500 and 4500: L2TP/IPSec IKE traffic

IP Protocol 50: L2TP/IPSec data (ESP) traffic

                TCP Port 443: SSTP control and data traffic

Additionally, following ports are opened to allow remote manageability of VPN servers

                TCP Port 135: RPC Endpoint mapper service

                Dynamic RPC port: Dynamic ports opened by RPC service  for DCOM traffic

c.       If you will like to block ports from the public side (let us say the remote manageability ports), you can do so in “Windows Firewall with advanced security”. 

1)      Click on Start->Administrative Tools->Windows Firewall with Advanced security.

2)      Go under Inbound rules. Search for the two rules with names starting with “Routing and remote access remote management”. View the properties of the rules.

3)      Add two new rules by clicking on “New Rule” under Action tab. Give all the properties of this rule same as  “Routing and remote access management” rules,  but add it with specific “Local Address” equal to public NIC IP address AND action as “Block the connections” (i.e. block remote manageability to RRAS public NIC’s address).

OR alternate way is to disable both the rules with names starting “Routing and remote access remote management” and create new rules with properties similar to the disabled rules and in addition set the local address to the IP address of the private NIC and set remote address to specific subnet from which to accept remote manageability requests.

4)      Repeat steps 2 and 3 for Outbound rules

3)      If you do a fresh install of WS08, install RRAS role via server manager and configures the RRAS role.

a.       If you have configured RRAS wizard with inbound/outbound filters that drops all traffic except VPN traffic -  you don’t need to do anything extra (because RRAS opens only VPN traffic on the public interface which anyways is required as a VPN server role)

b.      If you have configured RRAS without inbound/outbound filters (let us say enabled for NAT scenario and inbound/outbound filters don’t co-exist with NAT), you need to follow steps 2b) and 2c) as given above.

For any queries, feel free to write to us at the email address given above

References:

[1] RRAS Server in Windows server 2008: Which one to use - Windows firewall or RRAS filters

[2] Ports affecting the VPN connectivity

[3] RRAS static packet filters - do's and don'ts

[4] Which ports to unblock for VPN traffic to pass-through

Cheers,

Samir Jain
Senior Program Manager
Windows Enterprise Networking

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

Folks,

    The deployment guide for VPN Reconnect is now available at

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

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

regards

   Aanand

Hi Folks,

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

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

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

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

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

Pic. 1 Certificate Selection UI

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

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

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

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

c) Choose default option in the drop down menu.

Pic 2: Error Dialog in case of certificate mismatch

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

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

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

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

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

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

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

Netsh Command to configure the cert for SSTP:

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

OR

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

Netsh Command to see the current configured cert for SSTP:

netsh ras show sstp-ssl-cert

Netsh command to see and delete the current SSL binding:

netsh http show sslcert

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

With Regards,

Dhiraj Gupta

Software Design Engineer

Windows Networking Group

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

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

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

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

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)

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

'Routing and Remote Access' service that is available as part of Windows Server 2000, Windows Server 2003 and Longhorn server can be configured as a VPN Server with single Network Interface Card (NIC). This configuration is primarily used when there is a Network Address Translator (NAT) (or Firewall) machine sitting on the edge and the VPN server is part of the internal network.

For configuring 'Routing and Remote Access' service with single NIC, the administrator should choose the 'Custom Configuration' in the Configuration Wizard (Note that the other options would expect a minimum of 2 NICs to be availabe on the server). Other configuration parameters like authentication methods, static address pool, etc., can be set by right-clicking on the server name in the 'Routing and Remote Access' MMC console and selecting Properties.

If the configuration has a NAT router, the administrator needs to set the port forwarding on the NAT router.

Check www.microsoft.com\vpn for more information on VPN support in Windows.

Hi All,

Setting up VPN NAP using RRAS may seem overly complex in thoughts, but is not so. We now have great step-by-step guide available which walks you though the concepts + each and every step involved to set it up in the lab enviroment, test it and get a feel for it. This is not a deployment guide or recommended configuration for VPN NAP, but a jump-start for you to evaluate the power of "NAP"

Thanks to Joseph Davies to get it out. You can view the document at:

Title: Setting Up Virtual Private Network Enforcement for Network Access Protection in a Test Lab

http://www.microsoft.com/downloads/details.aspx?FamilyID=729bba00-55ad-4199-b441-378cc3d900a7&displaylang=en

Please feel free to drop in your comments, suggestions and improvement.

For more information on NAP, visit

http://blogs.msdn.com/nap

http://www.microsoft.com/nap

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

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

Approach 1:

On Security stand point use Default Gateway in the remote network else create batch file to add route on each client. The batch file can be created using Client Management Administration Kit (CMAK). CMAK can be used to save or export VPN Client for other computers.  

Firstly; To install CMAK:

1. Click on Start> Control Panel> Add or Remove Programs.

2. Click on Add/Remove Windows Components option in the Add or Remove Program dialog box.

3. Mouse select the Management and Monitoring Tools component from the Windows Component wizard with out selecting the check box option against it and click on Details button.

4. This would launch the Accessories and Utilities dialog box select the check box against the Connection Manager Administration Kit and click OK.

5. Click Next in the Windows Component wizard dialog box and on completion of installation click on the Finish button in the Windows Component wizard.

Secondly; To create the profile using CMAK:

1. Click on Start> All Programs> Administrative Tools> Connection Manager Administration Kit

2. Click Next and then select New profile option in the Service Profile Selection page of the Connection Manager Administration Kit Wizard. Click Next.

3. Provide the Service name and File name (executable file for the profile) in the Service File Names page of the Connection Manager Administration Kit Wizard. Click Next.

4. By default Do not add realm name to the user name option will be selected in the Realm Name page of the Connection Manager Administration Kit wizard. Click Next.

5. If you wish to merge any old profile information then you can achieve the same in the Merging Profile Information page of the Connection Manager Administration Kit wizard. Otherwise if it is the first time profile creation then there would not be any profile available for merging. Click Next.

6. In the VPN Support page of the Connection Manager Administration Kit wizard, you can make this profile to support VPN connections for remote access to private networks over the Internet. One can associate a phone book for the profile for the user to dial a phone number from the same phone book. This is achieved by selecting the Phone book from this profile option and you can always connect to a VPN Server by providing the VPN Server name or IP Address by selecting the Always use the same VPN Server option or provide a list of VPN Server (.txt) file by selecting the option Allow the user to choose a VPN server before connecting. You can also use the same user name and password for the dial-up and VPN connections by selecting the check box for Use the same user name and password for VPN and dial-up connections. Click Next.

6. Phone book file for the profile can be associated to the profile in the Phone Book page of the Connection Manager Administration Kit wizard. Click Next. If you want the phone book updates to downloaded automatically select the check box Automatically download the phone book updates. Click Next.

7. Phone Book Updates page of the Connection Manager Administration Kit is part of the wizard as check box Automatically download the phone book updates was selected in the previous page (Phone Book) of the wizard. For automatic download to happen we need to provide the Phone book name and the server from which the phone book updates will be downloaded in the Connection Point Services Server field. Click Next.

8. In the Dial-up Networking Entries page of the wizard one can edit the profile for the following:

            a. DNS and WINS addresses can be either obtained from the server or can be provided manually for all the clients.

            b. Security settings can be configured: Basic settings – Select authentication method (allow any method; require a secured password; require a Microsoft secured password) and Advanced settings – Select Data encryption (No encryption; Require encryption; Optional encryption) and the following Logon security – Select EAP (MD5-Challenge; Smart Card or other certificate) and select Authentication methods (PAP; SPAP; CHAP; MS-CHAP; MS-CHAPv2). Click Next.

9. Routing Table Update page of the wizard is where we could associate a routing table file (.txt) by selecting the Define a routing table update option and URL to the route file can be provided in the URL to a route file field or routing table should not be changed then select the Do not change the routing tables option. Click Next.

10. Automatic Proxy Configuration page of the wizard can be used to automatically configure proxy settings by the profile for the clients using this profile for connections. Select the Automatically configure proxy settings option and associate the txt file which has information on the proxy settings. Profile can also take care to revert back to the old proxy settings after the disconnection by selecting the check box against Restore the users previous proxy settings after disconnecting. Click Next.

11. Custom Actions page of the wizard can be used to configure certain actions under the following action type (Pre-init; Pre-connect; Pre-dial; Post-connect; monitored; disconnect; on cancel; on error or all). Click Next.

12. Logon Bitmap page of the wizard enables the user to select the display graphic in the Connection Manager logon dialog box. Click Next.

13. Phone Book Bitmap page of the wizard enables the user to select the display graphic in the phone book dialog box. Click Next.

14. Icons page of the wizard enables the user to select the custom icons or default icons to display in the Connection manager user interface. Click Next.

15. Notification Area Shortcut Menu page of the wizard to create a shortcut menu for Status and Disconnect which will be display icon in the notification area of the taskbar. Click Next.

16. Help File page of the wizard enables the user to select Default Help file or Custom Help file. Click Next.

17. Support Information page of the wizard enabled the user to direct to the support of the service provider. This is handled by providing the telephone contact number in the Support Information field. Click Next.

18. Connection Manager Software page of the wizard enables the user to Install Connection Manager with the service profile. And all the previous versions of Connection Manager will be upgraded to the current/newer version. This is achieved by selecting the check box against the Install Connection Manager 1.3 with this service profile. Click Next.

19. License Agreement page of the Connection Manager Administration Kit wizard can be used by the user add a license agreement to this profile. Client will not be able to continue with installation until the agreement is accepted. This is achieved by selecting the license agreement (.txt) file in the File Name field. Click Next.

20. Additional File page in the wizard is to include additional files in the profile. Click Next.

21. Ready to Build the Service Profile page in the wizard is the last but one stage to build the service profile. Click Next will not be possible to change any of the previous settings. However in this page by selecting the Advanced Customization check box user can modify the files that are included in this profile by their version or value in the Advanced Customization page in the wizard. Click Next.

22. Build of the service profile is through and the wizard’s last page Completing the Connection Manager Administration Kit wizard will display the executable file and its path. Click Finish.

Thirdly, To install and run the created Connection Manager Service Profile:

1. Go to the path where the profile is been created typically this will be under \Program Files\Cmak\Profiles\<name of the profile> of the localhost.

2. Double click on the file <name of the profile>.exe and Click Yes.

3. It would prompt for connection to be available for All users/My use only select the appropriate option. If a shortcut is required on the desktop then select the check box against Add a shortcut on the desktop. Click OK. This would install the service profile.

4. Go to Network Connections and under the Connection Manager double click on the connection object with <name of the profile> and provide the user name and password and click Connect.

Approach 2:

Route list can also be set on the DHCP Server and setup the VPN Server to send the routes from DHCP Server to your VPN Clients upon connection. With the last approach we do not have to set the default gateway on the remote network.

Mahesh Narayanan
Program Manager
RRAS, Windows Enterprise Networking
[This posting is provided "AS IS" with no warranties, and confers no rights.]

I have seen this a common customer query: My 2K, 2K3 server was working as DNS, DHCP, AD etc and stopped working after RRAS is installed.

The main reason for this is because: When RRAS server is configured using RRAS configuration wizard and you select VPN path, it enables static filters on the public interface - to allow "only" VPNtraffic to pass through. This is to protect the RRAS box from the Internet side. This can be optionally disabled while you configure RRAS using RRAS configuration wizard (by unchecking the checkbox "Enable static filters on the selected interface" while selecting Internet interface), but ensure your box is protected by some firewall running infront of RRAS server.

Lot of customers deploy RRAS in a single NIC scenario (i.e. behind a NAT router) - hosting multiple roles (like DNS, DC, NAT for LAN clients and VPN server for internet based remote access clients). In such a scenario, if you enable static filters on RRAS server to allow only VPN traffic, then all the other roles (like DNS, DC) will not function properly - as their packets will be dropped. In such a scenario, you need to add all the relevant ports for those services in RRAS static filters.

To quickly find out whether RRAS is running run the following commands from the command prompt: (after logging in as administrator on the RRAS server box):

1) sc query remoteaccess

2)sc query rasman

If the state of above two commands output is shown as "Running" (as given below), then it means RRAS is running on that box

C:\>sc query remoteaccess

SERVICE_NAME: remoteaccess
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
                                (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

3) netsh routing ip show filter

The above command shows the number of filters added inside RRAS static filter - for each interface. Filters gets applied only if RRAS is running (i.e. remoteaccess and rasman services are running).

Example output:

Input           Output          Demand-dial     Frag. Check     Interface
---------       ----------      -------------   --------------  ----------------

1   (DROP)      0   (FORWARD)   0   (FORWARD)   Disabled        Local Area Connection 6
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   Disabled        Local Area Connection 5

For more info on single NIC scenario:

http://blogs.technet.com/rrasblog/archive/2006/06/19/437171.aspx

For more info about static filter:

http://blogs.technet.com/rrasblog/archive/2006/06/14/435839.aspx

For more info about port numbers used by VPN server:

http://blogs.technet.com/rrasblog/archive/2006/06/14/435826.aspx

For more info about ports used by Microsoft Server:

http://www.microsoft.com/smallbusiness/support/articles/ref_net_ports_ms_prod.mspx

Cheers,

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

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

Are you interested in setting up your Windows based client OS (like Vista, Windows7)  as VPN server (aka ‘Enabling Incoming Connections’)?

I have seen some queries as where to find ‘Incoming Connection’ wizard in Vista and hence this post.

The Incoming Connection link in Vista is little hidden. To reach out to the link,  follow:

- From Control Panel, open Networking and Sharing Center
- Click Manage Network Connections from left menu
- Press Alt key, and select File menu  (or press Alt F)
- From File menu, Select New Incoming Connection

It would lead you to the ‘Incoming Connection’ setup wizard. In order to configure ‘Incoming Connection’ you need to have administrative privilege (part of Administrators group).

To know about how to setup VPN Client connection on Vista, follow:
http://windowshelp.microsoft.com/Windows/en-US/Help/8bcd8c4c-7c00-451b-91db-465cfd7484a51033.mspx

Dinesh Agarwal
SDE
RRAS, Windows Enterprise Networking

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

By now, all of you would be aware of what SSTP is and would also have got your questions answered in the FAQ column. We also saw in this blog, how to configure a SSTP client connection.

   In this post, let's quickly look at the steps required to configure the VPN server as a SSTP server. We will use Routing and Remote Access on Longhorn server for this.

   The VPN server will have two interfaces - public interface facing the internet and the private interface facing the intranet.

Step 1: Configuration of server authentication certificate on VPN server to be used for SSL

• The server authentication certificate can be obtained either by auto enrollment if the server is joined to domain or manually using web enrollment from the certification authority's certificate issue website.
• This certificate should have the Extended key usage (EKU) as "Server Authentication" or "All purpose". Certificates with any other EKU cannot be used.
• The certificate should not have expired and should be valid.
• The certificate's subject name should exactly match the hostname used by the client to connect to the server. [For eg. if the certificate is issued to the FQDN name of the server, then the client should use the FQDN name of the server in the VPN connection while connecting]
• This certificate should be installed in the 'Personal store' in the 'Local Computer' store of the VPN server. This certificate should be trusted by the Certification authority (CA) and the root CA certificate should be present in the 'Trusted Roots store' in the 'Local Computer' certificate store. The same root CA certificate should be deployed on the client in the 'Trusted Roots' store in the 'Local Computer' certificate store.
• When the client connects to the server, it will receive this server certificate through SSL and it needs to perform revocation check for that certificate. For this, the CRL distribution point should be published on the internet side so that the client can access it.

Step 2: Configuring the VPN server

The next step is to configure the RRAS server for VPN. Given below are the different steps that need to be done in order.

• Install the RRAS server role on the machine. Goto Start --> Administrative tools --> Server Manager --> Add roles --> Network policy services and install the Routing and Remote Access role.
• Open the Routing and remote Access console from Start --> Administrative tools.
• Right click on the server, Click on Configure Routing and Remote Access. This will open the Routing and Remote access configuration wizard. Click Next.
• Select 'Remote access (VPN or dialup)' from the menu and click Next. Select 'VPN' and click Next. Select the interface which is the public interface facing internet, then click Next. Then select how you want to assign addresses to VPN clients. If you choose static addressing, then you will need to specify the IP address pool. Click Next. Then choose how to perform authentication - either locally (windows authentication) or on another RADIUS server (RADIUS authentication), Then click Next. Click on Finish to complete the configuration.
• Ensure you have set appropriate remote access policies. If you have used windows authentication, click  "Remote Access Logging and Policies" inside routing andremote access console. Right click and select "Launch NPS". Select "Network Policies" and double click on "Connections to Microsoft Routing and Remote Access Server" and ensure "Policy Type" is "Grant access". Ensure all the conditions and settings matches your requirements. If you have used Radius authentication, you may be doing the same - but on the radius server (like NPS).
• RRAS is now configured as a VPN server to accept PPTP and SSTP connections.

As you can see - all the steps given above except need of machine certificate remains same for RRAS server configuration that accepts PPTP connection. Infact the exact same steps are required for RRAS server configuration that accepts L2TP connection (because L2TP/IPSec requires machine certificate to be installed on RRAS server).

Additional troubleshooting and configuration points:

• After performing these steps, execute the command "netstat -aon |findstr 443" to see if the TCP 443 port is in LISTENING state to accept SSTP client connection requests.
• Check the event viewer logs after configuration for information about failures in configuration (if any). 
• The RRAS server can be joined to domain if required (like for Windows authentication scenario to authenticate the clients against domain controller). If RRAS server is configured for Radius authentication, then it is not required to join it to domain - but can remain in workgroup and instead radius server can be joined to domain.

Soon - we will be publishing a step-by-step guide which will explain the entire setup in detail.

Janani Vasudevan
Software Design Engineer/Test
RRAS, Windows Enterprise Networking

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

By now, from all the other posts you might be aware of steps required to configure SSTP server to accept HTTPS connections. SSTP also supports being configured behind a SSL terminator (HTTP Reverse Proxy scenario). With this setup, a SSL terminator can be configured to terminate the SSL session and direct the plain HTTP request to a server behind (in this scenario the SSTP server or the RRAS server accepting SSTP based VPN connections).

So the setup will look like this:

 [Clients] ==========[Internet]===========[SSL Terminator]----[SSTP Server]---[Intranet]

Before you begin, you will need the following information:

1. The certificate that has been configured on the SSL terminator (which will be sent to the client during SSL hand-shake phase).
2. The IP address of the SSTP Server (to which redirect the SSTP sessions)

For this configuration, some changes will have to be made on the SSL terminator as well as the SSTP server.

On the SSL terminator:

1) Configure the SSL terminator to redirect requests coming for URI /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ to the SSTP server. This is the URI for which SSTP will be listening on the SSTP server.

2) The HTTP method to look for will be SSTP_DUPLEX_POST. This is the verb that SSTP uses (which is similar to GET/PUT/POST).

These two conditions will ensure only SSTP traffic is being redirected to SSTP server and rest all traffic can be redirected to something else - say to a farm of web servers (i.e. single SSL load balancer for web hosting as well as VPN connections). This should be the rule that will be used to redirect the traffic to the SSTP server. The traffic should be redirected as HTTP behind the SSL terminator.

On the SSTP server: 

Once the SSL terminator is configured, you need to configure the SSTP server to accept HTTP connections instead of the default HTTPS connections. For this, go to the registry HKLM\System\CurrentControlSet\Services\SstpSvc\Parameters. Change the value of ‘UseHttps’ from 1 to 0.

This change will cause the SSTP to listen on port 80 instead of the default port 443 for accepting HTTP connections instead of the HTTP connections.

As an added security measure, in order to ensure that the SSTP connections coming to server are from the configured SSL terminator, SSTP will validate through the protocol that the hash of the certificate received by the client during SSL phase (and passed as a part of SSTP protocol) is the same as the hash of the certificate configured on the SSL terminator. For this, the SSTP should be manually configured with the hash of the certificate that is configured on the SSL terminator. The hashes supported can be either SHA1 hash or the SHA256 hash.

The steps to get the certificate hash will be handled as a part of separate blog. The corresponding registry keys to be used are as follows. All the values are under the HKLM\System\CurrentControlSet\Services\SstpSvc\Parameters.

The values supported are:

·         SHA1Enabled    REG_DWORD               1 – SHA1 based certificate hash validation is supported

                                                             0 – SHA1 based certificate hash validation is NOT supported. SHA1CertificateHash registry value will not be required

·         SHA1CertificateHash     REG_BINARY   This is 20-bytes in length and will indicate the SHA1 hash of the certificate configured on the SSL terminator.

·         SHA256Enabled            REG_DWORD   Same as SHA1Enabled – this will indicate whether SHA256 based certificate validation is allowed or not.

·         SHA256CertificateHash REG_BINARY               This is 32-bytes in length and it indicates the SHA256 hash of the certificate configured on the SSL terminator.

SHA256 is the preferred hash algorithm. By default, if SHA256Enabled value is not explicitly specified in the registry, SSTP will assume it to be 1. SHA1Enabled value on the contrary will be assumed to be 0 if it is not explicitly defined in the registry.

Note that if SHA1 or SHA256 is implicitly assumed to be 1, their corresponding hash values must be specified for SSTP to function. The client side also honors SHA1Enabled and SHA256Enabled (including the implicit assumption as stated above) and based on these values, will send the appropriate certificate hash to the server for validation. On the client side, the SHA1CertificateHash and SHA256CertificateHash will be ignored since the hashes will be computed directly from the certificate received from the server.

Once the certificate hash and UseHttps flag is also configured correctly for the SSTP, restart RemoteAccess service. The server should now be capable of accepting SSTP connections behind a SSL terminator.

Kadirvel C. Vanniarajan

Software Design Engineer

RRAS, Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm]

 The steps to configure a RAS client connection using SSTP were listed in one of the previous posts. However, the good news is that Connection Manager can also be used to establish SSTP connections. This makes deploying client connections easier and transparent to the user.

    To enable clients to connect using Connection Manager, we need to be able to build a Connection Manager profile that uses SSTP. The Connection Manager Administration Kit (CMAK) in Microsoft Windows Longhorn Server has been enhanced to help you build SSTP enabled Connection Manager profiles. Let us look at the steps required to acheive this.

So we are back with a post on SSTP - the tunnelling protocol that can help you traverse through NATs and firewalls.

SSTP is sure a great way to establish VPN connections in cases where PPTP and L2TP will not work due to the presence of NATs and firewalls. However, some network administrators may not want any form of outgoing L3 VPN connections going out of their network due to security reasons.

As the admin of your managed network, if you want to ensure that there are no SSTP VPN connections going out of your network, then this post will help you. Though all other SSL VPNs doesn't provide a mechanism to accomplish this, SSTP does allow a way to do this.

The assumption made here about your network is that you have a web-proxy  deployed in your network through which all HTTP connections go out.  In such cases, the SSTP VPN connection will also go through the proxy as it is over HTTPS. The SSTP VPN client will send a HTTP "CONNECT" request to the proxy which is configured in the settings of the 'Internet Explorer' for the user initiating the connection.

This CONNECT request sent by the SSTP client has a custom HTTP header named "SSTPVERSION" with value "1.0". On the web-proxy, you can add a rule which inspects the CONNECT requests for this particular header. If this header is present, then it signifies that it is an SSTP connection request which is coming from within the managed network. You can choose to drop/block this request if you do not want users to establish SSTP connections from within your network.

 Hope this helps you to manage your networks more effectively!

Janani Vasudevan
Software Design Engineer/Test
RRAS, Windows Enterprise Networking

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