Hello Folks,

I am sure you must have experienced VPN reconnect – a new IKEv2 based VPN tunnel that is added in Windows 7 that allows automatic and seamless switchover of an active VPN connection when the underlying Internet interface (connection) changes thus maintaining application persistence.

Isn’t that COOL – like VPN user moving from Wifi to WWAN and back -  giving a true mobile connectivity to corpnet ! Yes it is...

This means, Windows7 in-built VPN client and Windows 2008 R2 in-built VPN server (aka RRAS) supports following VPN tunnels:

·        PPTP

·        L2TP/IPSec

·        SSTP

·        VPN Reconnect (or IKEv2)

I am sure you must be wondering what is the need for 4 different tunnel types and which one to use in a given scenario. This blog helps to clarify the same.

Let us look at the technical specs which tries to summarize the tunnel features based upon different deployment factors:

First compare on network related parameters

Now lets compare on security related parameters

Where,

* All PPP based user authentication supports password (MSCHAPv2) as well as certificate (EAP based user certificate in local store or smart-card) authentication

** VPN reconnect supports machine cert based authentication as well as user authentication which can be password based (EAP-MSCHAPv2) or certificate based (EAP based user certificate in local store or smart-card).

*** OS prior to Vista supports 40/56/128 bit RC4 encryption for PPTP. Vista onwards supports 128 bit RC4 based encryption only.

**** OS prior to Vista supports DES, 3DES encryption for L2TP. Vista onwards supports 3DES and AES based encryption.

Note: All the other features like Winlogon over VPN (aka PLAP), Radius connectivity, NAP based health check continue to be supported on all the VPN tunnels.

Summary:

As you can see from the above table, the different deployment factors (like OS choices,  PKI infrastructure) and your deployment needs (like support for firewall traversal, support for mobility, need for machine authentication, remote access or site-to-site access)  will finally drive your VPN tunnel choice.

If you will like to simply ignore all technical jargons, a simple rule of thumb can be – use VPN reconnect wherever you can, else configure the fall-back to SSTP. This way you will get secured-uninterrupted-ubiquitous VPN connectivity via IKEv2 tunnel wherever it is possible (i.e. both endpoint supports IKEv2 and IKEv2 traffic is able to pass through between end-points). Else the VPN connectivity will fall-back to SSTP tunnel which can traverse any form of firewalls, NAT, web proxies. In my next post I will discuss further on how the tunnel fallback happens and how to configure the same.

If you are wondering, why I think VPN reconnect is better compared to L2TP – though both are running on top of IPSec, here is my thinking:

·        L2TP/IPSec requires machine authentication followed by user authentication. Assuming no-one uses pre-shared key, this puts a restriction of deploying machine certificates on every L2TP based VPN client machine (i.e. need of PKI infrastructure) – which increases the deployment cost.

However, VPN reconnect supports simple password based user authentication (EAP-MSCHAPv2), thereby  simplifying the deployment

·        VPN reconnect supports IP address persistence in case of underlying link goes down/up or new link comes up – via mobility manager. This way the applications running on top of VPN tunnel sees no break in connectivity (imagine your big download doesn’t stops in between - if underlying wireless link goes down-up).

·        VPN reconnect is faster in connection establishment phase (less round-trip-times) compared to L2TP/IPSec.

·        Do you need anything more ....

Have a happy remote access journey ...

Cheers,

Samir Jain

Senior Program Manager

Windows Networking

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

Hi Folks,

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

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

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

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

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

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

Why we would like to deprecate PPTP/L2TP?

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

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

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

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

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

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

Looking forward to hear back from you 

Cheers,

Abhishek Tiwari

Senior Lead Program Manager, RAS Team,

Windows Networking

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please note:

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

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

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

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

Now let us take some deployment scenario:

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

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

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

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

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

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

For further references:

Different VPN tunnel types in Windows

How automatic tunnel types work in Vista

Frequently asked Questions on IPv6 support of RAS

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

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 Folks,

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

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

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

1.       Change in method used to calculate MSK

Details of Enhancement

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

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

Impact

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

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

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

Details of Enhancement

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

Deployment Recommendation

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

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

           being validated by the client.

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

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

           store. The latter is highly recommended

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

Impact/Troubleshooting Tips

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

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

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

Hello Friends,

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

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

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

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

We sincerely appreciate your feedback.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

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 Friends,

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

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

Here are the steps you need to follow:

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

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

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

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

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

For L2TP/IPSec: No other configuration is required

For IKEv2 EAP authentication: No other configuration is required

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

Hope this posting helps you select the right certificate

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

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

Hello Customers,

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

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

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

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)

Hello Customers,

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

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

How to enable this scenario?

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

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

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

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

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

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

How does it work?

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

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

Let me know if that works for you too.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

Hello Customers,

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

1) Error Code: 800

2) Error Code: 609, 633

3) Error Code: 732, 734, 812

4) Error Code: 806

5) Error Code: 789, 835

6) Error Code: 766

7) Error Code: 691

8) Error Code: 809

9) Error Code: 13806

10) Error Code: 13801

11) Error Code: 0x800704C9

12) Error Code: 0x80070040

13) Error Code: 0x800B0101

14) Error Code: 0x800B0109

15) Error Code: 0x800B010F

16) Error Code: 0x80092013

17) Error Code: 0x800704D4

18) Error Code: 0x80072746

Further References:

Troubleshooting articles @ RRAS blog site

How to troubleshoot SSTP based connection failure in Windows

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

Cheers,

Dinesh Agarwal

Amit Kumar (WINDOWS)

Windows Networking

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

Problem:

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

Solution:

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

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

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

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

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

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

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

How it works:

The solution involves following elements:

1.       Remote access (RAS) APIs

2.       PowerShell script and XML configuration file

3.       Group Policy

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

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

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

Let us know your feedback

Cheers,

Rama Krishna Prasad S

Software Development Engineer

Windows networking

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