Routing and Remote Access Blog : IKEv2

Enhancements to VPN Reconnect in W7 RC

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

Hello Folks,

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

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

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

1. Change in method used to calculate MSK

Details of Enhancement

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

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

Impact

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

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

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

Details of Enhancement

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

Deployment Recommendation

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

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

being validated by the client.

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

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

store. The latter is highly recommended

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

Impact/Troubleshooting Tips

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

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

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

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

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

Hello Customers,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please note:

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

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

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

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

Now let us take some deployment scenario:

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

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

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

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

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

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

For further references:

Different VPN tunnel types in Windows

How automatic tunnel types work in Vista

Frequently asked Questions on IPv6 support of RAS

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

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

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

Hi Folks,

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

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

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

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

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

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

IKEv2

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

2. Integrates well with all EAP based methods

3. Leverages the security strength provided by IPsec

4. Better in connectivity time compare to L2TP/IPsec

5. Provide mobility switchover support (mobility manager)

Windows 7 & WS08 R2 onwards

SSTP

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

2. Integrates well with all EAP based methods

3. Leverages the security strength provided by SSL protocol

4. Provides firewall traversal

Vista SP1 & WS08 onwards

Why we would like to deprecate PPTP/L2TP?

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

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

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

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

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

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

Looking forward to hear back from you

Cheers,

Abhishek Tiwari

Senior Lead Program Manager, RAS Team,

Windows Networking

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

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

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

Folks,

The deployment guide for VPN Reconnect is now available at

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

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

regards

Aanand

Different VPN tunnel types in Windows - which one to use?

rrasblog — Fri, 30 Jan 2009 12:56:00 GMT

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

Tunnel Type	OS support	Scenario	IP Addressing	Traversal	Mobility Enabled
PPTP	XP, 2003, Vista, WS08, W7, WS08 R2	Remote Access Site-to-Site	Works over IPv4 network Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT via PPTP enabled NAT routers	No
L2TP/IPSec	XP, 2003, Vista, WS08, W7, WS08 R2	Remote Access Site-to-Site	Works over IPv4 as well as IPv6 network Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT	No
SSTP	Vista SP1, WS08, W7, WS08 R2	Remote Access	Works over IPv4 as well as IPv6 network Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT, Firewalls, Web Proxy	No
VPN Reconnect	W7, WS08 R2	Remote Access	Works over IPv4 as well as IPv6 network Relay IPv4 as well as IPv6 traffic on top of tunnel	NAT	Yes

Now lets compare on security related parameters

Tunnel Type	Authentication	Data Confidentiality
PPTP	User authentication via PPP*	RC4***
L2TP/IPSec	Machine authentication via IPSec *followed* by user authentication via PPP*	DES, 3DES, AES****
SSTP	User authentication via PPP*	RC4, AES
VPN Reconnect	Machine or user authentication via IKEv2**	3DES, AES

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

Known issues in VPN reconnect mobility manager in Windows 7 beta release

rrasblog — Fri, 30 Jan 2009 00:00:00 GMT

Hi folks,

Hope you all are in good health.I believe that you must be enjoying the new VPN reconnect feature in Windows 7 and more importantly the mobility experience it provides. Aren't you? I am writing this blog to list the known issues with mobility manager and their workarounds. These issues have been fixed in Windows 7 RC milestone.

Issues

The Mobility Manager does not start for the first VPN reconnect connection after reboot.

Mobility manager is expected to start as soon as the first mobility enabled VPN reconnect connection is established. This bug is typically seen for the first connection after system boot.

Workaround:

Open taskschd.msc
Navigate to Microsoft\Windows\Ras folder and locate mobility manager task ( as shown here ).
Right click and start the task by selecting 'Run'.

I will keep this blog updated with any new issues found .

With Regards,

Arpan Kumar Asthana,

Software Development Engineer,

Windows Networking Group.

VPN Reconnect: A New Tunnel for Mobility

rrasblog — Wed, 14 Jan 2009 08:56:00 GMT

VPN Reconnect: A New Tunnel for Mobility

Has your file download or a Line of Business application (LOB) ever got interrupted just because your internet connection went down momentarily and you had to start it all over again ?

You will never have to do that with the IKEv2 tunnel of “VPN Reconnect” feature available in windows 7.

Read on to find out what other exciting scenarios can be made possible with VPN reconnect feature.

Look at the following scenarios:

Melissa is a Mobile Information Worker (MIW) who is mostly on the move and uses Wireless Wide Area Network (WWAN) (costly and lower speeds) while she is mobile and Wireless Local Area Network (WLAN)/LAN when at customer locations and when at home or office. As a part of her day to day activities she has to download lots of huge documents from her office server and some LOB applications need uninterrupted connection. As a result she always uses her rather slow and costly WWAN connection even though she has access to high speed WLAN access at different customer locations. She wonders how productive and economical it would have been if she were able to switch to WLAN without her existing applications and downloads getting interrupted.

Sondra is a release manager of a software company whose offices are distributed across different cities and she has to regularly talk to different project teams across different cities as a part of her day to day job. To reduce long distance telephone costs her company has decided to use Voice call over Office communicator instead of long distance calls over cellphones. While she appreciates the clarity of voice she gets using office communicator, she rues the fact that calls get disconnected as he moves between meeting in different buildings and the WiFi access points change. She wonders if should could have the same roaming feature with office communicator as she has with traditional cell phones.

Ichiro is a network admin of an Internet service provider contoso.com Contoso.com does not own any physical infrastructure but leases internet connectivity from different regional service providers and give a single country wide solution to all its customers. The reason contoso’s service offers more value for the money is because they will be able harness the cheapest internet service available in that region. If a particular city has low cost WLAN encompassing all areas, contoso’s customers can connect to this WiFi service instead of the costly WWAN service. One complaint contoso has from its customers is that whenever the local service provider changes, the IP address of the customers changes and all their applications get disconnected. Contoso cannot use Mobile IP as it does not own the network infrastructure. Contoso is looking for a simple solution for this problem

IKEv2 tunnel of VPN Reconnect solves above scenarios and the problems whenever the underlying network changes.

How it works:

VPN Reconnect is built on IPsec Tunnel Mode (RFC 4301) that uses IKEv2 (RFC 4306) for key negotiation and transmits ESP (RFC 4303) packets. MOBIKE (RFC 4555) is used to switch the tunnel end points when the underlying interface changes.

The following diagram illustrates a scenario of VPN Reconnect.

The mobile user initially connects to an IKEv2 compatible server to access corpnet over Wired LAN.

The user then starts using a client application that communicates with the application servers in the corporate network. Now if the user disconnects his wired LAN connection and connects to WiFi hotspot his VPN connection persists and his client application continues its communication with the application server un-interrupted. Let us see how to achieve this and how it works

Configuring IKEv2 Client:

1. Specifying the VPN server address /name:

In the general tab of RAS connectoid properties, specify the VPN server destination. You can specify the IPv4 address, IPv6 address or the Fully Qualified Domain Name (FQDN) of the VPN server .

2. Specifying the tunnel options:

On the security tab select IKEv2 from the dropdown menu of Type of VPN

VPN Reconnect supports different encryption options ranging from no encryption to AES256.

VPN Reconnect supports two types of Authentication:

a. Extensible Authentication Protocol (EAP)(RFC 3748)

b. X.509 Machine Certificates (RFC 2459)

3. Enabling Mobility:

In the advanced properties tab there is a Mobility check box. By default this check box is enabled for VPN Reconnect. If the check box is unchecked the client cannot switch its local tunnel endpoint.

4. Selecting IPv4 and IPv6

VPN Reconnect supports both IPv4 and IPv6 internal addresses.

5. Connecting:

Once the configuration is done all you need to do is click connect.

6. Status:

On the details tab of the status page of the connection. The local and remote addresses are shown.

In the above page the vpn connection is over the interface “ Local Area Connection” with IP address 172.23.90.42. The Destination address of the VPN server is 172.23.90.71.

The Client IPv4 address 172.23.90.89 is the address to which all the application sockets bind to. VPN Reconnect makes sure that even if the Origin address changes the Client Internal IPv4 address remains same and hence the connection is persisted.

When the LAN interface goes down, mobility manger switches to the next available interface, in the diagram below the new interface is “Wireless Network Connection” with IP address 10.86.52.186.

You can observer that in both the cases the Client Ipv4 address did not change and remained same 172.23.90.89 as a result the applications that bind to 172.23.90.89 will not see any change in the interface going down and hence all the applications are persisted.

Variations:

In addition to the above illustrations VPN Reconnect persists the connection the following scenarios as well:

Switch from IPv4 to IPv6 address

If the server and client have both IPv4 and IPv6 connectivity, the client can first connect over IPv6 Internet address and switch to an IPv4 Internet address and vice-versa.

Switch from Internet to Corpnet

If the client first connects to corpnet from Internet and then connects to corpnet, VPN Reconnect switches the VPN connection from the Internet facing address of the server to the Internal corpnet address of the server. So if a user starts a voice conversation using Office Communicator over VPN when connected to the internet, he can continue the conversation without any interruption as he walks into his office and connects to Corporate network. This possible even if the corporate network firewall does not allow IKE/ESP packets going out of its Internet gateway because mobility manger tries all combinations of VPN server internal and external addresses when the underlying network goes down.

Switching when the IP Address of an Interface changes

If the IP address of an interface changes, VPN Reconnect ensures that the connection is persisted. So if user connects to his corporate network over WiFi network, his VPN connection stays up even if his WiFi access points change and the IP address of this WiFi interface changes.

Persistent Connection amidst frequent disconnections

If you have a lossy WWAN connection with frequent disconnections and you are want to watch streaming media, every time the connection gets disconnected you will have to re-start the streaming and the buffered data is lost. With IKEv2 tunnel if the WWAN connection gets disconnected and reconnected (even with a new IP address) the connection persists and streaming downloads get resumed for the point of disconnect.

Uma Mahesh Mudigonda

Developer, Routing & Remote Access

The Mobility Manager - managing mobility for VPN reconnect connections (IKEv2 based VPN connections)

rrasblog — Tue, 30 Dec 2008 22:52:00 GMT

Hi folks,

It's again that exciting time of the year when the next version of Windows is going to make it to the markets. Win7 boasts of several cool features that promise to transform the lives of people and make computers more effective and easier to use. So are you ready to grab a glimpse of these cool features that highlight Win7?

Present VPN tunnels do not provide mobility support. By mobility I mean that if the interface on which the VPN connection is established, gets disconnected, your VPN connection gets disconnected too. You have to re-dial the connection over the next available interface and undergo the time consuming authentication process and security checks. This leads to waste of your time, puts undue burden on the VPN servers and causes annoyance. Isn't it? Now imagine if there is some mechanism by which the switch is automatically performed to the next available Internet capable interface and the same VPN connection stays as it is. Excited? This is exactly what we are trying to achieve through this new component. Let me introduce you to the Mobility manager. It is a component which seamlessly switches over the VPN connection (VPN connection hereafter refers to a connection using new VPN tunnel called IKEv2) to next available interface, when the lower layer interface gets disconnected. In this post I will go through the general behavior, configuration, scenarios and limitations of this component. So let's get started!!!

Mobility manager primarily targets a roaming user and provides her continuous corporate connectivity when she moves across various networks. It also provides for seamless switching of a VPN connection from one interface to another when the interface, on which the VPN connection is established, goes down, hence providing continuous connectivity to a static user also. Some of the real life scenarios can be -

A connected user remains connected when she moves across wireless access points (coffee shops/hotels).
A user connected from home (through WWAN/GPRS) remains connected when she comes inside the corporate network (i.e. comes to office).
A connected user remains connected if the underlying interface goes down and some other interface (with network connectivity) is available.
A connected user remains connected if the underlying interface is flaky. In this case other VPN connections get disconnected, but the IKEv2 based VPN connection stays up.
A connected user remains connected if she moves from an IPv4 enabled network to an IPv6 enabled network and vice versa, provided the server supports IPv6 addresses.

One major characteristic of the switchover is that during the switchover the IKEv2 connection is itself not redialled or re-authenticated, only the external endpoints change.So you need not redial the connection and re-enter your credentials. After the switch is performed, the VPN tunnel will start using the new interface. The applications using this connection see no change and continue to work the same way as before without breaking. That's what you call a seamless switch, isn't it?

How to make your VPN connection mobility enabled

Follow the following steps to make an IKEv2 based VPN connection mobility enabled

Open VPN connectoid properties
Go to the security tab
Click on Advanced Settings.
Check the mobility checkbox to enable mobility.

Behavior of Mobility manager

IKEv2 based VPN connection exhibits three states-

Connected
Dormant - When the underlying interface through which IKEv2 is connected to the corporate network goes down/ or the access point changes.
Waiting to reconnect - When the mobility manager is trying to switch the connection to the next available interface or access point.

These states can be explained with an example. Consider a scenario when you are home with a IKEv2 based VPN connection to corporate network over a broadband (PPPoE ) connection. Also assume you have a disabled wireless network that can also provide Internet connectivity.

Initially the VPN connection is connected.

Now if the broadband connection gets disconnected ( and with wireless disabled) , the VPN connection goes into a dormant state as shown below

Now if you enable the wireless network, the mobility manager tries to switchover the VPN connection over the wireless network. While the switchover is in progress, the VPN connection is in a 'waiting to reconnect' as shown below

After a successful switchover the VPN connection is happily reconnected.

Some points to note about mobility manager's behavior-

The dormant VPN connection will start using a new Internet capable interface in a few milliseconds.
In case no new Internet capable interface is available on the system, mobility manager performs a switch as soon as one is available.
In case system has no network connectivity and there are dormant connections on the system, mobility manager tries to switch the dormant connections at regular intervals.

Troubleshooting mobility manager

Mobility manager runs as a task having local service privileges. It gets triggered when the first mobility enabled IKEv2 connection is connected and continues to run till there is one available. It can manage any number of IKEv2 connections on the system.

Mobility manager is a robust and reliable component and typically user would not face any issues, but in case some problem happens , you can do the following checks

Check if mobility manager is running-

Run taskschd.msc
Open \Microsoft\Windows\Ras task and verify that mobility manager is running.

2. Enable log collection:

To enable logs, run the following command from the administrator command prompt.

netsh ras diagnostics set tracefacilities enabled

Limitations

Some of the downsides of Mobility manager can be -

No provision for cost based switching. User cannot specify the costs associated with the interfaces. One crude way to specify cost is manually setting the interface metric instead of automatic setting.
It only supports make after break scenarios meaning that a switch is performed only if the current IKEv2 based VPN connection becomes dormant.

With Regards,

Arpan Kumar Asthana,

Software Development Engineer,

Windows Networking Group.