Routing and Remote Access Blog : Vista and LongHorn

Configuring IIS on the SSTP server - Implications and how to resolve

rrasblog — Thu, 08 Nov 2007 07:51:00 GMT

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

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

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

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

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

IP:port : 0.0.0.0:443

Certificate Hash : 3f399643ac981dd68726e4d99f90f7c5a349498a

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

IP:port : [::]:443

Certificate Hash : 3f399643ac981dd68726e4d99f90f7c5a349498a

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

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

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

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

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

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

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

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

So far, everything is fine.

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

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

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

IP:port : [::]:443

Certificate Hash : 3f399643ac981dd68726e4d99f90f7c5a349498a

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

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

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

Solution for this problem:-

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

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

Step 1) Remove the HTTPS site from the IIS.

Step 2)

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

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

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

net stop sstpsvc /y

net start remoteaccess

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

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

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

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

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

net stop sstpsvc /y

net start remoteaccess

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

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

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

f83e9044820269e698072e19880d30840689a1f9

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

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

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

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

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

net stop sstpsvc /y

net start remoteaccess

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

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

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

IP:port : 0.0.0.0:443

Certificate Hash : 3f399643ac981dd68726e4d99f90f7c5a349498a

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

IP:port : [::]:443

Certificate Hash : 3f399643ac981dd68726e4d99f90f7c5a349498a

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

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

Now, the SSTP based connections will go fine.

Thanks,

Amit Kumar

Software Design Engineer/Test,

Enterprise Networking Group, Microsoft.

Do you want to change the certificate used by the SSTP server - Read how

rrasblog — Thu, 08 Nov 2007 07:38:00 GMT

This blog is going to tell about how to change the Certificate to be used for the SSTP Server.

Although, the normal procedure of installing the certificate on RRAS Server for SSTP mentioned in the step by step guide works perfectly fine, this blog is going to talk about how to change the certificate which is being used on the Server for SSTP Connections.

Let's consider that the admin has successfully configured RRAS Server for SSTP using a Server Authentication Certificate SAC1 which is bound to the SSL listener setup on the server. So, the certificate SAC1 will be bound to the two IP:Port pairs 0.0.0.0:443 and [::]:443 as shown below. Here, the certificate hash shown is the SHA1 thumbprint of the certificate that you can see from the Certificates console of MMC under Certificate details.

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

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

IP:port : 0.0.0.0:443

Certificate Hash : 926af74453ad0fcbb3fe9ee62e8843329a84c6ac

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier :

Ctl Store Name :

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

IP:port : [::]:443

Certificate Hash : 926af74453ad0fcbb3fe9ee62e8843329a84c6ac

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier :

Ctl Store Name :

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Now, the admin thinks of changing the Server Authentication Certificate. So, he will issue a Server Authentication Certificate from the same CA in the name of same External IP address of the Server. Let's call this Certificate as SAC2.

Though the Subject (CN) name of these two certificates SAC1 and SAC2 are the same, the hashes of the two certificates will be different.

Wrong Way to Change the Server Authentication Certificate:-

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

The admin will delete the older Cert SAC1 from the Personal store and will store the new Certificate SAC2 in the Personal store of the Computer Account. Now, he will disable and then enable RRAS. Notice here that this will not touch the existing binding from the IP:Port pairs 0.0.0.0:443 and [::]:443.

When an SSTP based connection is made from the client to this server, the connection will go through and the admin will think as if everything went fine. Now, here is the catch. Since the HTTP stores the context of the certificate bound to the IP:Port pair, this connection has gone through using the previous certificate SAC1 which is not there anymore in the Certificate Store. The moment, admin reboots the machine, this HTTP context storage will go away and so, after the Server comes up again, when an SSTP based connection is made, it will FAIL. The admin will have no clue here why the connection is not going through now though it was going fine just before the reboot.

Correct Way to Change the Server Authentication Certificate:-

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

- Delete the Older Certificate SAC1 from the Personal Store of Computer Account of the Server.

- Add/Import the new Certificate SAC2 to the Personal Store of Computer Account of the Server.

- Execute the following set of commands

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

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

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

net stop sstpsvc /y

net start remoteaccess

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

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

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

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

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

net stop sstpsvc /y

net start remoteaccess

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

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

f83e9044820269e698072e19880d30840689a1f9

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

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

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

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

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

net stop sstpsvc /y

net start remoteaccess

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

G:\Users\Administrator>netsh http show ssl

SSL Certificate bindings:

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

IP:port : 0.0.0.0:443

Certificate Hash : f83e9044820269e698072e19880d30840689a1f9 <-------

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier :

Ctl Store Name :

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

IP:port : [::]:443

Certificate Hash : f83e9044820269e698072e19880d30840689a1f9 <-------

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

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier :

Ctl Store Name :

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Notice above that the hashes have changed to the Thumbprint of SAC2 Certificate. And hence, now the SAC2 Certificate is bound to 0.0.0.0:443 and [::]:443.

Now, if an SSTP connection is made from Client to this Server, it will go through by making use of the SAC2 Certificate which is what the admin wants.

Thanks,

Amit Kumar

Software Design Engineer/Test,

Enterprise Networking Group, Microsoft.

SSTP: Microsoft new VPN tunnel using SSL is coming - please get ready to try it out !

rrasblog — Thu, 13 Sep 2007 03:51:00 GMT

Hi All,

I am very happy to announce that SSTP will be first time released to all our TAP and techbeta customers via Vista SP1 beta and Windows Server 2008 RC0 release which was released on Sept 25th, 2007

To get your hands dirty with SSTP, work with your Microsoft TAP contact if you are part of Windows TAP program. If not, you can be a part of Windows techbeta program via enrolling to http://connect.microsoft.com/ and get the Windows beta bits.

To do a SSTP pilot or lab deployment, all you need is:

1) A machine running Vista SP1 beta or Windows server 2008 RC0 or later - acting as VPN client

2) A machine running Windows server 2008 RC0 or later - acting as VPN server

Please enroll and get your set-up ready.

Here is the SSTP step-by-step guide: http://download.microsoft.com/download/b/1/0/b106fc39-936c-4857-a6ea-3fb9d1f37063/deploying%20sstp%20remote%20access%20step%20by%20step%20guide.doc

For more questions on SSTP, see http://blogs.technet.com/rrasblog/archive/tags/SSTP/default.aspx

For any queries, feel free to connect with us via our email address as given above

Samir Jain
Lead Program Manager (samirj@online.microsoft.com **)
RRAS, Windows Enterprise Networking

** Remove the "online" to actually email me

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

How "Automatic" Tunnel type works in VPN

rrasblog — Thu, 07 Jun 2007 06:58:00 GMT

With the various previous blogs, we already know that SSTP (Secure Socket Tunneling Protocol) is a new VPN tunnel type which is added to the list of the already existing tunnel types, PPTP and L2TP. With this addition, there have been some changes in the definition of the existing tunnel type configuration options and some new tunnel type configuration options have been added to the list of existing ones.

This post is going to talk about two topics:-
1) The existing options for configuring tunnel types whose behaviour has changed with the addition of SSTP and addition of some new options for configuring the tunnel type for dialing the VPN connection from the client.

2) The connection establishment time it takes to transition from one tunnel type to another, if first one fails to connect.

The above topics are discussed in detail below.

The various new/changed options for Configuring tunnel types:-
-------------------------------------------------------------------------------------------
[1] With VPN connection created using "Connect to a network" wizard :-
With the addition of SSTP, the existing tunnel type "Automatic" means that PPTP will be tried first and if that fails L2TP is tried and then SSTP i.e., PPTP->L2TP->SSTP.

[2] With VPN creations created by CMAK (Connection Manager Administration Kit):-
With the addition of SSTP, in the CMAK based connectoid, there are two new values which can be assigned to VpnStrategy field in the .CMS file. The significance of these values are as follows:-

- VpnStrategy=5 :- This means "SSTP Only". In this case, only SSTP based tunnel will be tried.

- VpnStrategy=6 :- This means "SSTP First". In this case, SSTP will be tried first followed by PPTP then L2TP i.e., SSTP->PPTP->L2TP

Timings for transition from one tunnel type to another:-
---------------------------------------------------------------------------------
Consider the scenario where a connection is established using a particular tunnel type 'X'and then after this, this connection is disconnected and the connection is retried again with "Automatic" tunnel type and the connection is established using a different tunnel type 'Y' (where 'Y' is not equal to 'X') due to other tunnel types blocked/disabled on the server. This section is going to specify the aprroximate time taken in switching from tunnel type 'X' to tunnel type 'Y'.

Current Tunnel Type (X)	Final Tunnel Type (Y)	Tunnel Protocols blocked on server	Tunnel Protocols enabled on server	Switching Time taken
PPTP	L2TP	PPTP	L2TP, SSTP	21 Sec
L2TP	PPTP	L2TP	PPTP, SSTP	36 Sec
PPTP	SSTP	PPTP, L2TP	SSTP	57 Sec
SSTP	PPTP	SSTP	PPTP, L2TP	21 Sec
L2TP	SSTP	L2TP, PPTP	SSTP	57 Sec
SSTP	L2TP	SSTP, PPTP	L2TP	43 Sec

Things to note here :-
1) If currently, there is no established VPN connection and connection is tried using tunnel type as "Automatic", the tunnel sequence to be tried will be the default one which is PPTP->L2TP->SSTP

2) If a VPN connection is already established using a particular tunnel type 'X', then if this connection is retried with tunnel type as "Automatic", the tunnel type which is going to be tried first is 'X'. To be more specific,

- If PPTP is the current tunnel type, then PPTP will be the first tunnel type to be tried and the sequence of tunnel types to be tried will be the default one i.e., PPTP-> L2TP->SSTP.

- If L2TP is the current tunnel type, then L2TP will be the first tunnel type to be tried and the sequence of tunnel types to be tried will be L2TP->PPTP->SSTP.

- If SSTP is the current tunnel type, then SSTP will be the first tunnel type to be tried and the sequence of tunnel types to be tried will be SSTP->PPTP->L2TP.

Amit Kumar
Software Design Engineer/Test
RRAS, Windows Enterprise Networking

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

Accessing Network Shares Over a VPN Connection in Windows Vista

rrasblog — Mon, 04 Jun 2007 11:28:00 GMT

It is not possible to access network shares from a Windows Vista machine over a VPN connection if Net BIOS over TCP (NetBT) is disabled on one of the machines or port 139 is blocked. A fix for this problem is available from Microsoft Support. Customers just need to call support and quote the following KB number associated with the fix

933468: SMB (port 445) does not bind on Vista over RAS connection

If you need help with the problem or the fix please contact rrasblog@microsoft.com

Aanand Ramachandran

Program Manager, RRAS

How to prevent SSTP based VPN connections to be dialed out from my network

rrasblog — Fri, 01 Jun 2007 08:40:00 GMT

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

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

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

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

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

Hope this helps you to manage your networks more effectively!

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

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

Quick snap-shot of IPv6 scenarios and features supported in RRAS

rrasblog — Wed, 09 May 2007 05:40:00 GMT

Hi All,

In Longhorn, Routing and remote access server role supports IPv6 (in addition to IPv4). In this blog, I will give a quick summary on what are the scenarios that are supported and what changes are required to enable the same. This will also help you to decide a roll-out plan to enable you to migrate to IPv6.

Let us first look at what are the main scenarios for which customers deploy RRAS:

1) Enable remote access to their users - using dialup or VPN (i.e. over Internet) as the link-layer.

2) Enable site-to-site connectivity between their offices - using dialup or VPN (i.e. over Internet) as the link layer

Now let us look at what it means by IPv6 support in context with the above scenarios:

1) First look at your connectivity between end user PC to RRAS (i.e. remote access scenario ) or RRAS-RRAS (i.e. site-to-site connectivity):

a. If your connectivity is dial-up, then move to step 2).

b. If your connectivity is VPN i.e. a virtual tunnel over Internet, now look at whether you have IPv4 based ISP connectivity (which is most common today) or IPv6 based connectivity (which is gaining momentum and will become common soon).

i. If it is IPv4 connectivity, then you can use any form of VPN tunnel (PPTP, L2TP or SSTP) – just configure the hostname/IPv4 address of destination server inside your VPN client/originating router.

ii. If it is IPv6 connectivity, you can use L2TP/IPSec or SSTP based VPN tunnel to establish a tunnel between two ends and configure hostname/IPv6 address instead. Also ensure RRAS server public interface has the same IPv6 address which client connects to and the firewalls in-front of RRAS server are enabled to allow L2TP/SSTP packets destined to RRAS server IPv6 address.

2) Now let us look at your connectivity behind your RRAS server or networking connectivity within your Intranet

a. I am sure you will be having IPv4 connectivity there today. No changes required here (i.e. you can continue to support IPv4 as well as IPv6 in parallel).

b. Now if you are planning to migrate to IPv6 (i.e. your LAN machines will be having IPv6 address too), then you need to make the following changes.

i. Remote Access: Enable RRAS server as “IPv6 remote access server” and manually configure a /64 bit IPv6 prefix in it. This one prefix will be shared by all remote access clients. In addition, install and configure DHCPv6 Relay Agent present inside RRAS server. This will enable forwarding of DHCPv6 Inform packets coming from remote access clients onto DHCPv6 server running on Intranet side. This extra step is required to hand-out extra addressing parameters like DNS server IPv6 address, DNS suffix etc to the remote access clients.

ii. Site-to-site connectivity: Enable RRAS as “IPv6 Router” and then add a “demand-dial interface”. As a site-to-site server also acts as remote access server (to accept connections), follow the steps given above (except DHCPv6 relay agent).

The above steps will enable RRAS server to send IPv6 prefix to other end as well as forward IPv6 packets received on its dialup/VPN interface onto Intranet side and vice versa. The other end can be a remote access user or a site.

iii. Rest of your configuration – like authentication/authorization remain same as IPv4.

iv. Rest of your IPv6 deployment can continue to happen as planned. For example – if you want some servers (like your Radius server or Domain controller to be using IPv6), you can continue to enable them towards IPv6 at same or different times.

This really means RRAS server can be used to bridge IPv6 islands separated by IPv4.

References: Look at following blogs:

1) RAS IPv6 FAQ

2) How PPPv6 works

3) Cable guy article

Note: We will be soon adding link to step-by-step guide for IPv6 connectivity – stay tuned.

Feel free to share your comments

Cheers,

Samir Jain

Lead Program Manager (Windows Enterprise Networking)

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

Troubleshooting Vista VPN problems

rrasblog — Sun, 08 Apr 2007 17:59:00 GMT

Hello all. There have been quite a few questions/posts on the technet forums about issues you folks have seen with Windows Vista VPN clients. So we thought we would come up with a post on the common configuration issues and some troubleshooting tips. Hope this helps others who are facing the same issues.

If you are seeing an issue different from one of those below, please send a mail to rrasblog@online.microsoft.com** with a description of your issue, the Operating system on the VPN client and the server, and the RAS tracing logs from the VPN client and the VPN server(if you have access to the VPN server). The steps to generate the logs are described in another post in this blog. (http://blogs.technet.com/rrasblog/archive/2006/06/20/437481.aspx)

** Remove the "online." from this email ID to actually mail the logs.

1. Windows Vista VPN client does not support MS-CHAPv1 authentication method

Windows Vista no longer supports MS-CHAPv1 and we strongly recommend that customers move to MS-CHAPv2, which is more secure. MS-CHAPv2 has been available since Windows 2000 and is widely supported. Note that if your server is configured to accept connections only using MS-CHAPv1 as the authentication method, then Windows Vista clients will be unable to connect to your server.

VPN client errors that might indicate that this is potentially the issue you are seeing:

732 Your computer and the remote computer could not agree on PPP control protocols.
718 The connection timed out waiting for a valis response from the remote computer
734 The PPP link control protocol was terminated
736 The remote computer terminated the control protocol
919 The connection could not be established because the authentication protocol used by the RAS/VPN server to verify your username and password could not be matched with the settings in your connection profile

Resolution

Configure your server to allow clients to connect with MS-CHAPv2 as the authentication method. Update your VPN client connection settings to use MSCHAPv2 as the authentication method.

If you have a third-party VPN server which does not support MS-CHAPv2 as an authentication method and supports only MS-CHAPv1, you will need to use either CHAP or PAP to connect from the Windows Vista VPN client until the server you use starts supporting MS-CHAPv2.

Steps to follow for resolution

(1) Check if the Routing and Remote Access Server (RRAS) is configured to allow connections with MS-CHAPv2

[These steps apply if you are using Microsoft Windows Server only. If using any other server, you will need to follows steps appropriate to the server]

a. Open RRAS console on the VPN server. Start --> Run --> rrasmgmt.msc

b. Rightclick on the Servername --> Properties --> Security tab --> Click on 'Authentication methods'

c. Verify that MSCHAPv2 checkbox is checked. If not, check the checkbox next to MSCHAPv2 and click on Apply. Click on OK.

(2) Check if the RADIUS server policy supports MSCHAPv2 (This step is needed if you control access to clients using Remote Access Policies on the IAS/NPS server)

a. Open IAS console on the Radius server. Start --> Run --> ias.msc

b. Navigate to the 'Remote Access Policies' Node.

c. Doubleclick on the remote access policy - Connections to Microsoft Routing and Remote Access servers --> Click on 'Edit profile' --> 'Authentication' tab

d. Ensure that MS-CHAPv2 is selected in the list of authentication methods.

e. Click on OK.

2. Connection issues due to encryption mismatch

There have been some issues seen where the Vista VPN client experiences issues with connection due to encryption mismatch. You may face this issue if you are using Windows Vista VPN client to connect to a VPN server running an earlier version of Windows viz. Microsoft Windows 2003 Server and Microsoft Windows 2000 Server. This happens because Windows Vista does not support 40-bit and 56-bit encryption levels under the RC4 algorithm for PPTP and by default supports obly 128-bit encryption. This change is due to the security enhancements in Windows Vista. There is another post dedicated to these changes in this blog which describes this nicely (http://blogs.technet.com/rrasblog/archive/2006/11/01/vista-lh-security-changes-for-remote-access-scenarios.aspx).

VPN client errors that might indicate that this is potentially the issue you are seeing:

741 The local computer does not support the required data encryption type
829 The modem (or other connecting device) was disconnected due to link failure.

Resolution

Configure the remote access policy on your VPN server to accept 'Strongest encryption (MPPE 128 bit)'. Also make sure that encryption is selected to be negotiated in the client connection.

Steps to follow for resolution

The detailed steps to follow are given in the below KB article.

KB 929857 - You receive error code 741 when you try to make a PPTP-based VPN connection on a computer that is running Windows Vista

http://support.microsoft.com/kb/929857

3. VPN Client connections created on Windows Vista show up as Dial-up connections

Some people have been facing this issue in their Windows Vista VPN client installations. When a VPN client connection is created using the 'Get Connected wizard' or rasphone.exe, it shows up as a 'Dial-up connection' in the network connections folder. When you right click on the client connection created, click on Properties, it says 'Connect using Modem (removed)'

This might happen if the virtual WAN miniports for PPTP/L2TP are not installed. Also, these miniports might be uninstalled after installation due to one of the below several reasons:

· 3rd party VPN adapter or software install/uninstall

· 3rd party firewall software install/uninstall.

· System backup that didn’t restore properly.

· Corrupted or missing bindings.

· Manual or 3rd party software's improperly manipulation of registry values in the registry key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}.

You can verify if this is the issue by following the below steps:

a. Open Device Manager (Start -> Run -> devmgmt.msc)

b. Click on 'View' in the toolbar and select 'Show hidden devices'

c. Expand the machine name node.

d. Under 'Network Adapters' node, see if WAN Miniport (PPTP) and WAN Miniport (L2TP) are present. If they are not present then you are facing the issue mentioned above and you need to follow the resolution steps specified below.

Resolution

The resolution is to uninstall and install the miniports manually.

Steps to follow for resolution

Type the following commands in order from an elevated command prompt on the Windows Vista client.

Netcfg –u MS_PPTP

Netcfg –u MS_L2TP

Netcfg -l %windir%\inf\netrast.inf –c p –i MS_PPTP

Netcfg –l %windir%\inf\netrast.inf –c p –i MS_L2TP

4. Connection failure due to Windows Live OneCare Firewall blocking VPN traffic

Some Vista users have reported this issue where their VPN connection fails to go through when Windows Live OneCare is installed. The firewall from Windows Live OneCare by default blocks VPN traffic. You need to configure OneCare firewall to allow VPN traffic.

VPN client errors that might indicate that this is potentially the issue you are seeing:

800 Unable to establish the VPN connection. The VPN server may be unreachable, or security parameters may not be configured properly for this connection
809 The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g, firewalls, NAT, routers, etc) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem

Resolution

Configure Windows Live OneCare Firewall to allow VPN traffic by enabling the exception already present there.

Steps to follow for resolution

Go into Change One Care Settings à then open the Firewall Connection Tool from the Firewall tab à Check the box for “VPN” which is present there.

Signing off hoping this information helps you to troubleshoot your VPN client issues!

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

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

Setting up the SSTP listener and verifying it

rrasblog — Tue, 06 Mar 2007 19:03:00 GMT

We have seen the steps to configure a SSTP server in one of the previous posts. However, we will concentrate on on aspect of the configuration in this post in detail and the most important one too, because without this your server is not yet ready to accept SSTP connections - Setting up the SSTP listener and verifying if it is set up correctly.

As all of you know, SSTP works over HTTPS and so the SSTP listener that Routing and Remote Access Server sets up is very similar to a HTTPS site that you create using IIS. When you create a HTTPS site in IIS, you specify the IP address to listen on (default is INADDR_ANY), port to listen on and also the web server certificate that should be bound to the HTTPS site. Once you do this, a HTTPS listener is setup for the IP:port pair you specified and the certificate you specified to that IP:port pair.

Now, a similar thing happens when you configure Routing and Remote Access server using the steps given in the previous post. The HTTPS listener is setup. The IP:port pair on which it is setup and the certificate it binds to the listener are as follows:

The IP address for the listener is INADDR_ANY i.e. 0.0.0.0 for IPv4 and [::] for IPv6
The default port used is 443. However you can change this value to a different port using the registry value 'ListenerPort' at HKEY\Local Machine\System\CurrentControlSet\Services\SstpSvc\Parameters to the desired value if needed.
For the certificate to bind to this listener, it looks in the Local Computer --> Personal store and picks up the first valid certificate that is returned while querying the certificates in the store.

A valid certificate should satisfy the following:

- Enhanced key usage(EKU) should be either 'Server Authentication' or 'All purpose'

- The certificate should have a private key

Also, a certificate with EKU 'Server authentication' is preferred over a certificate with EKU 'All purpose'

As the certificate is mandatory to setup a HTTPS listener, if there is no valid certificate in the Local Computer -->Personal store when Routing and Remote Access starts, the listener will not be setup. And hence SSTP connections cannot be established to the server. This will be informed to the user through an event log.

Also, it is very important to see that the correct certificate is bound to the listener if there are more than one valid certificates in the Local Computer --> Personal store. This is because, the server sends this certificate bound to the listener to the client when it connects, just as it happens when we access HTTPS sites. When we access HTTPS sites, if the name of the website on the certificate i.e. its subject name is not the same as what we typed in the address bar, we get a warning as below:

"There is a problem with this website's security certificate.

The security certificate presented by this website was issued for a different website's address.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

We recommend that you close this webpage and do not continue to this website. "

The same can occur in the case of SSTP also. If we have a certificate whose subject name is say 'ServerName1' bound to the SSTP listener and we use the name 'ServerName2' for hostname in the client's VPN connection, then the certificate returned to the client will not have the subject name that it expects.

In the case of HTTPS sites, Internet explorer gives us the choice of continuing to the site inspite of knowing the security issue. However, in the case of SSTP connections, this might pose a greater risk as you are exposed to the full network access through the tunnel. If the subject name of the certificate does not match the hostname specified, the SSTP VPN connection cannot be established.

Troubleshooting the listener:

Keeping all the above points in mind, these are the issues that can occur

Default port - Is TCP port listening?
No valid certificate to bind to the listener
More than one valid certificate. Should check if the right one was picked up
The listener port specified is not available

Lets take up each one of these separately.

Default port - Is TCP port listening?

On a command prompt, type the command 'netstat -aon |findstr 443'. If you see the below line displayed, then the TCP port is listening for HTTPS requests. You can go to the next step now.

TCP [::]:443 [::]:0 LISTENING 4

No valid certificate to bind to the listener

On a command prompt, type the command, 'netsh http show sslcert'. If you see the message that there are no SSL certificate bindings, then it means that there was no valid certificate for SSTP to bind to the listener.

Look at the event viewer (Start --> Run --> eventvwr) under Windows Logs --> System for any log from RasSSTP. You will see an event if this was the case.

Install a valid certificate in the Local Computer --> Personal store and then restart the Routing and Remote Access server configuration.

More than one valid certificate. Should check if the right one was picked up

On a command prompt, type the command, 'netsh http show sslcert'. If a certificate is bound to the listener, you will see a message as below.

SSL Certificate bindings:
-------------------------

    IP:port                 : 0.0.0.0:443
    Certificate Hash        : c14e9c7ffe2f292ef4367eed10317f4c1ba20df0
    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}
    Certificate Store Name : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          :
    Ctl Store Name          :
    DS Mapper Usage    : Disabled
    Negotiate Client Certificate    : Disabled

    IP:port                 : [::]:443
    Certificate Hash        : c14e9c7ffe2f292ef4367eed10317f4c1ba20df0
    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}
    Certificate Store Name : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          :
    Ctl Store Name          :
    DS Mapper Usage    : Disabled
    Negotiate Client Certificate    : Disabled

If the Application ID is {ba195980-cd49-458b-9e23-c84ee0adcd75}, then it means that this is a binding added by SSTP. So this command shows that there is a certificate which is bound to 0.0.0.0:443 IP:port listener and also a certificate which is bound to [::]::443 IP:port listener. The certificate hash value specifies which certificate is actually bound. This is the SHA1 certificate hash of the certificate. Here, we see that the SHA1 certificate hash of the certificate is c14e9c7ffe2f292ef4367eed10317f4c1ba20df0

We will use this hash to verify if the correct certificate has been bound to the listener.

Open the Microsoft Management Console (Start --> Run --> mmc).
Add the Local Computer certificates snap-in (Click on File -->Add/Remove snap-in -->Select 'Certificates' from the list of Available snap-ins --> Click on Add --> Select 'Computer account' --> Click on Next --> Ensure 'Local computer' is selected' --> Click on Finish --> OK
Expand the 'Certificates (Local Computer)' node (Doubleclick on the node)
Expand the 'Personal' node ( Doubleclick on the node). Click on 'Certificates' subnode under this.
On the certificates pane, you will see a list of certificates in the store. Doubleclick on the certificate which you want to be bound to the SSTP listener i.e. the certificate with the subject name matching the hostname used in the client VPN connection.
Click on 'Details' tab. Make sure '<All>' is selected in the drop down for 'Show:'
Ensure that the value for the field 'Thumbprint Algorithm' is sha1
Note the value of the field 'Thumbprint'.
Compare to see if this value is the same as the certificate hash we saw in the netsh message.
If it is, then it means that the right certificate has been bound to the listener.
If it is not the same, then some other certificate has been bound to the listener. We can bind the required certificate to the listener using the following commands. These commands will delete the currently cound certificate and bind the certificate the we want to the listeners.

Say, the value of the 'Thumbprint' field for the required certificate is 'xxx', type the following command on an elevated command prompt:

netsh http delete sslcert ipport=0.0.0.0:443

netsh http delete sslcert ipport=[::]:443

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

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

The listener port specified is not available

If the listener port that you hav e configured in the registry is not available, SSTP will not be able to set up a listener on that port. There will be an event logged in the event viewer in this case. Open event viewer (Start --> Run --> eventvwr). Navigate to Windows Logs --> System and look for logs from RasSstp.

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

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

SSTP: Beta Program

rrasblog — Thu, 25 Jan 2007 04:30:00 GMT

Hi Everyone,

I have received overwhelming response from the community about SSTP, how it works and a lot of interest in participating in the beta program. Thanks a lot to all of you !! I am trying my best to get as many folks enrolled to the program. We are getting all set for delivering our beta bits and will keep you posted on the release status.

In terms of what infrastructure will be required to test and then deploy SSTP - we are writing a detailed step-by-step guide which will be a great help to you. This should be available sometime in Feb mid. Apart from that, we will be always present for you through various options (emails, newsgroups, chats, phone-calls) for any queries that you may have.

For SSTP pilot in the lab, you will need following infrastructure:

1) VPN Client PCs running Vista SP1 beta or Longhorn server RC0 bits. For VPN client configuration, please refer to http://blogs.technet.com/rrasblog/archive/2007/01/16/using-secure-socket-tunneling-protocol-sstp-for-vpn.aspx

2) VPN Server PC running Longhorn Server Beta bits. RRAS server role will be installed and configured on this PC. Machine certificate need to be installed on the RRAS server. I will soon add a link giving details to the VPN server configuration here.

3) Additional server roles like Active directory (if you want to authenticate against AD), Network Policy Server (if you want to use radius authentication) depending upon your requirement.

If you are familiar with RRAS server product in Windows 2000 or 2003 - you will not see any major additional step to enable SSTP. For more details on RRAS and Microsoft VPN, refer tohttp://www.microsoft.com/technet/network/rras/default.mspx, http://www.microsoft.com/vpn, http://www.microsoft.com/rras)

Please mail me, if you want to enroll into SSTP beta program or you can visit http://connect.microsoft.com/ and participate in Windows server 2008 (i.e. Longhorn) beta program.

Samir Jain
Lead Program Manager (samirj@online.microsoft.com **)
RRAS, Windows Enterprise Networking

** Remove the "online" to actually email me

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

Broadband connections and DHCPv6 Prefix Delegation in Windows Vista

rrasblog — Tue, 23 Jan 2007 08:13:00 GMT

Some Microsoft customers and partners have enquired about the support for Requesting-Router behaviour of DHCPv6 Prefix Delegation in Windows Vista. I have also seen attempts by some vendors to use prefix delegation to assign IPv6 addresses to Broadband/PPPoE interfaces. In this post, I’ll clarify our view of prefix delegation and outline the support available for it in Windows Vista.

RFC 3633 defines options for delegating IPv6 prefixes through DHCPv6. As the aptly termed phrase “requesting router” suggests, the prefix delegation mechanism is suitable for assigning a prefix to clients which will act as routers between networks.

The appropriate mechanism for assignment of addresses to PPPoE interfaces is through the use of IPv6CP to negotiate an interface-identifier and then using the prefix in a RA from the server to generate an IPv6 address. In the case of a broadband router which dials a PPPoE connection, we recommend that the router first obtain an IPv6 address for its PPPoE interface through this mechanism. It should then follow this with a DHCPv6 prefix delegation request on the PPPoE interface to obtain an IPv6 prefix from the service provider’s router. This prefix should then be used for Router Advertisements on its LAN interface.

In most cases, Windows Vista clients dialling a Broadband connection will use this connection for their own Internet connectivity. This is the reason that the Vista PPPoE client does not by default trigger DHCPv6 prefix delegation. Only when Internet Connection Sharing is enabled on Windows Vista, where the host needs to act as a router for other clients on a home network does Windows Vista trigger the requesting router behaviour of prefix delegation. In this scenario, the Windows Vista host will obtain the IPv6 prefix from the server and advertise it to other clients on the home network.

Santosh Chandwani

Windows Enterprise Networking

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

SSTP FAQ - Part 2: Client Specific

rrasblog — Wed, 17 Jan 2007 17:54:00 GMT

In this FAQ, I will cover client specific queries of SSTP

1) How to enable SSTP based VPN connection on the client side?

SSTP based -connection can be enabled on native RAS client UI (i.e. inside “network and sharing center”). For further details, refer to http://blogs.technet.com/rrasblog/archive/2007/01/16/using-secure-socket-tunneling-protocol-sstp-for-vpn.aspx

Connection manager administration kit (CMAK) is enhanced to support SSTP and hence CM profile can be used to establish SSTP based VPN connection.

2) How does Automatic VPN Tunnel type WORKS with SSTP?

On the client side, if the VPN tunnel type is selected as “Automatic”, then the order is PPTP->L2TP->SSTP. i.e. try PPTP first, if that fails try L2TP, if that fails try SSTP.

Note: The tunnel type which the client is able to successfully connect will be used for next reconnection and the automatic -tunnel selection logic is not retried till it fails. For example, first connection will be tried with PPTP->L2TP->SSTP and say SSTP is successful. On next re-connection, the client will retry SSTP first and if that fails then tries PPTP followed by L2TP.

3) What kind of NAT, Web proxy and firewall traversal is supported by SSTP client?

Outgoing SSTP connection can pass through any kind of NAT and firewalls – as long as TCP port 443 is allowed (which is normally the case).

If the VPN client is behind a web proxy, then outgoing SSTP connection can go through in normal web proxy. SSTP does not support “authenticated” web proxies (i.e. proxies which require some form of authentication during HTTP CONNECT request).

4) How to block SSTP based VPN connections to traverse out of corporate network?

For any reason, if the network administrator wants to block all outgoing SSTP based VPN connection, then it can be done at the web proxy level. If there is a web proxy (i.e. forward proxy) deployed inside the corporate network which can do filtering of different attributes inside HTTP CONNECT header, then SSTP based connections can be blocked as it adds a fixed field (SSTP_VERSION: *) inside the HTTP CONNECT header.

5) How to set proxy address in SSTP client?

SSTP client picks up the web proxy settings of current user’s context from Internet explorer.

6) Is WinLogon using SSTP based VPN connection is supported? If yes, how is it enabled?

Yes – Winlogon over SSTP based VPN connection is supported. The VPN connection should be created for “all users”.

Additionally if the VPN connection goes through a web proxy, then the web proxy settings need to be picked up from the system store. This is because in case of Winlogon – the user establishes the VPN connection first and then logs on. The web proxy settings can be configured inside the system store using “netsh winhttp set proxy” command

7) What is the authentication protocol used by SSTP? Is it done at HTTPS layer or PPP layer?

Client is not authenticated to server at the HTTPS layer. SSTP client is authenticated to server at the PPP layer. So various PPP authentication algorithm (like MSCHAPv2, EAP-MSCHAPv2, EAP-Smart-card, PEAP) can be used with SSTP. For further details, refer to http://blogs.technet.com/rrasblog/archive/2007/01/10/how-sstp-based-vpn-connection-works.aspx

8) Is the encryption done at MPPE layer or at HTTPS layer?

MPPE encryption at PPP layer is turned off when tunnel is SSTP (this is similar to L2TP/IPSec scenario). The encryption (or data confidentiality) is achieved at the SSL layer.

9) Which OS release will support SSTP?

SSTP client will be supported on Vista SP1 and Longhorn server (i.e. Windows server 2008). SSTP server will be supported on Longhorn server via RRAS and Vista SP1 via VPN "incoming connections".

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

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

SSTP FAQ - Part 1: Generic

rrasblog — Wed, 10 Jan 2007 14:36:00 GMT

Hi All,

I am sure lot of queries may be running in your minds related to SSTP. To clarify it further, I am starting a series of frequently asked questions (FAQ) related to SSTP. Please feel free to send your comments on the blog site or to our blog email address if you have further queries.

In this part, I will cover some generic queries related to SSTP

1) Can SSTP be deployed along with other VPN tunnels?

Yes – absolutely.

The same RRAS based VPN server can support all flavor of tunnels or any combination of these at the same time. In-fact L2TP/IPSec and SSTP can share the same machine certificate on the server side.

2) Can SSTP be used for site-to-site VPN tunnels?

No – SSTP is currently supported for remote access (or remote user) scenarios only.

3) What HTTP and SSL version is supported by SSTP?

HTTP 1.1 with 64 bit content length encoding and SSL 3.0

4) What encryption algorithms are supported by SSTP?

The same as supported by SSL - i.e. AES, RC4

5) What kind of certificate is required on client and server side?

On the server side a machine certificate is required in order for SSTP based connection to go through. The client gets this certificate as part of SSL hand-shake and validates the same. This certificate should be with EKU as server authentication.

On the client side, a certificate is required inside the trusted root CA machine store which goes back to the certificate chain on the server certificate. This will be used to validate the server certificate in addition to certificate validity, certificate expiry, certificate EKU and certificate revocation check.

6) Does SSTP support IPv6?

Yes – SSTP based VPN connection can be established on top of IPv6 based network (like Internet).

Also IPv6 (or PPPv6) can be carried on top of SSTP based VPN tunnel.

7) Will NAP be supported by SSTP? What changes are required to support it?

Yes – NAP VPN support remains same as PPTP/L2TP VPN tunnel. This is because NAP VPN support is enabled via PEAP authentication which is part of PPP stage and remains same as PPTP, L2TP or SSTP based VPN tunnel. This means same remote access policies inside NPS can be used to support all form of VPN tunnels - with no explicit extra configuration for SSTP. Same way same client configuration (PEAP, etc) can be used for all form of VPN tunnels.

In the next series, I will try to cover the server related FAQ. Stay tuned for more information and looking forward to hear from you too

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

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

How SSTP based VPN connection works

rrasblog — Wed, 10 Jan 2007 14:21:00 GMT

In this blog, I will explain how SSTP based VPN tunnel works - i.e. the data flow during VPN connection coming up and how data transfer occurs.

The flow to get VPN connection up looks like:

1) Client gets Internet connectivity and then establishes TCP connectivity to server over port 443. Let us say the IP address of client is 100.100.100.1 and server is 200.200.200.1.

2) Then on top of this TCP session, SSL negotiation takes place. Client gets the server certificate during SSL authentication phase and it validates the server certificate. If it is not valid, the connection is broken down. No client (or user) authentication happened on the server side at the SSL stage.

3) Client then sends HTTPS request on top of the encrypted SSL session to the server.

4) Client then sends SSTP control packets on top of the HTTPS session. Once SSTP state machine is up on either side, lower-link up indication is given to PPP layer on each ends.

5) PPP negotiation (on top of SSTP over HTTPS) takes place at both ends. As part of PPP authentication phase, client is authenticated to server and optionally (depending upon the authentication algorithm) server is authenticated to client.

6) Once PPP completes, it attaches as IP interface on both client and server side. Let us say the "inner IP" or the IP address given by VPN server to the client is 192.168.1.2 and the IP address of VPN interface on VPN server is 192.168.1.1

7) Now both ends are ready to send IP packets to each other.

Now let us try to understand how data path works: Lets say user does ping to VPN server IP address i.e. 192.168.1.1 in this example

1) Ping (i.e. ICMP echo request) packet will go over IP (with source IP as 192.168.1.2 and destination IP as 192.168.1.1) over PPP over SSTP.

2) SSTP sends to SSL layer which does the encryption and sends over TCP over IP (with source IP as 100.100.100.1 and destination IP as 200.200.200.1) over Internet interface.

Hope this helps for you to understand SSTP based VPN tunnel in detail and how it differs from PPTP and L2TP. The main thing to note is: PPP and above remains same on the protocol stack and SSTP adds a layer to encapsulate PPP packets over HTTPS session.

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

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

Advantages of SSTP based VPN tunnel

rrasblog — Fri, 22 Dec 2006 11:42:00 GMT

In last week blog, I wrote about SSTP - the new VPN tunnel which goes over HTTPS - hence increasing the coverage area of VPN connection to "everywhere". Today I am going to talk about advantages of SSTP compared to "network extension or full tunnel" solution delivered by other SSL products.

Note: I am not comparing web based access (i.e. clientless access) delivered by SSL vendors with SSTP.

* SSTP client will be available inside Vista SP1 clients and SSTP server will be available in LH Server OS.

* Integrated NAP support for client health-check. And NAP includes support for different kind of health check with extensibility by third party vendors (like antivirus, firewall etc).

* Full support for IPv6. SSTP VPN tunnel can be established across IPv6 internet. And IPv6 (or PPPv6) can be sent over SSTP based VPN tunnel.

* SSTP establishes single HTTPS channel from client to server - compared to two channel approach done by other vendors. This leads to better networ utilization (because outer TCP ACK/data can be piggy-backed) and load balancing story (every VPN session is one HTTPS session)

The good part of SSTP is it integrates with MS RAS client/server infrastructure seamlessly. For example, SSTP supports password + strong user authentication (like smart-card, RSA securID, etc) using various PPP authentication algorithm. Other features of RAS (like generating profiles using connection manager administration kit, remote access policies, etc) - just works - similar to other PPTP/L2TP.

This means just enable SSTP as a VPN tunnel on remote access client and RRAS server side and you are ready to go.

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

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