Routing and Remote Access Blog : L2TP

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

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

Verification of Additional Fields in Peer Certificates during IKE Negotiation in Windows Vista for L2TP/IPSec Tunnel Connections

rrasblog — Thu, 08 Mar 2007 14:04:00 GMT

In Windows Vista IKE Layer authentication for L2TP/IPSec tunnel connections using machine certificates has been strengthened
by verifying additional fields in the certificate presented by the peer during the IKE negotiation apart from validating that
the certificate chains to the correct root certificate specified in the IPSec policy. These additional checks are

1. Verification that subject-alternative-name or the subject-name field on the certificate correspond to the name
(or IP address) of the peer with which the client machine seeks to communicate.
2. Verify EKU field to ensure that the certificate presented by the peer was assigned for authentication purpose.

These additional checks are enabled by default on Windows Vista clients.

The checks could however cause IKE negotiation to fail even in scenarios where a Vista client is trying to
connect to an authentic down-level RRAS server if the machine certificate deployed on the RRAS server does not have one
or all of the verified fields set correctly. As a result L2TP tunnel connection setup also fails. Changing the machine
certificate on a working deployment is not a viable solution to resolve this problem. In such a situation an administrator
might want to disable these additional checks all-together. Following are the different ways to disable the checks

Method 1: Through rasapi32 RASENTRY Structure
A new flag named RASEO2_DisableIKENameEkuCheck has been added to the dwfOptions2 member of RASENTRY structure. If this flag
is set to 1 additional checks during IKE validation will not be done. An application developer can create a VPN dialer with
additional checks disabled using this flag.

Method 2: through CMAK
Additional checks during IKE validation can be disabled for a CM VPN dialer when the profile is created through CMAK wizard.
A new key called DisableIKENameEkuCheck is explicitly added while creating the profile through CMAK’s Advance Customization.
The key is added in the .cms file under Networking&TunnelDUN section. If the value of the key is set to 1 additional checks
are disabled for the profile.

Method 3: through Network Connections Window
For VPN dialers created through the Network Connections wizard on Windows Vista, the additional checks during IKE validation
can be disabled in the properties window of the dialer through the Verify name and usage attributes of the server’s
certificate check-box. This checkbox can be found under
properties->networking->IPSec Settings->user certificate for authentication radio button
Changing this setting causes the DisableIKENameEKUCheck key in the rasphone.pbk file to change. When additional checks are
disabled the value of the key is set to 1 and when additional checks are enabled the value of the key is set to 0.

Method 4: through Registry
A new registry setting can be created called DisableIKENameEkuCheck to control the additional checks during IKE validation
for all VPN dialers on the machine. The key is created under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters.
When this registry key is set to 1 the additional checks are globally disabled for all VPN dialers on the machine.
Modifying or creating registry keys is not a recommended procedure though.

Additional checks during IKE validation is disabled if any of the methods that are described in this article are used
to disable the checks.