Routing and Remote Access Blog : SSTP

How to configure RRAS based SSTP VPN server behind F5 BIGIP SSL load balancer

rrasblog — Tue, 26 May 2009 12:50:00 GMT

Hello All,

In this blog, I will discuss how to load balance SSTP based VPN servers using a F5 BIGIP SSL load balancer.

Lets look at the deployment scenario first: You are having a pool of RRAS based VPN servers hosted behind F5 BIGIP load balancer. The F5 BIGIP load balancer terminates the HTTPS connections coming in from different SSTP based VPN clients, load balances the same by sending HTTP connections to one of the VPN server from this pool of RRAS based VPN servers.

I will walk-through a sample lab set-up, however you can modify the same according to your own deployment.

Configuring F5 BIGIP

Connect to F5 BIGIP management console web interface. Go to Local Traffic
SSL Certificates: Import the SSL certificate that will be used during HTTPS negotiation. Please note: the subject name (CN) of the certificate should be same as the VPN destination name as configured inside VPN client. This can be either hostname or IP address – depending upon the VPN client configuration. Also note: The thumbprint of this certificate will be configured inside RRAS server (under Sha1CertificateHash and Sha256CertificateHash registry keys as given in step 3 under Configuring RRAS as SSTP VPN server).
Profiles: Create two profiles: a) Name: SSTP_Http profile derived from the existing parent template `HTTP’. This profile will be attached to the virtual server so that we can add an iRule to do HTTP filtering based on SSTP URI. b) Name: SSTP_Client profile derived from the existing parent template `ClientSSL’. This will be configured with the certificate imported in step 2 and will be used to terminate the HTTPS connections coming in from the client side.
Nodes: Create nodes specifying IP address of each of the VPN servers (i.e. RRAS server’s IP address facing towards BIGIP or Internet).
Pools: Create a pool with name SSTP-Pool that contains the node we created in step 4. Enter the name of the pool, add gateway_icmp health monitor, select the nodes and select the service port as 80 or any other value that is configured on SSTP based VPN server to listen for incoming HTTP connections.
iRules: This is the best part of F5 BIGIP – without doing any firmware code change, we were able to get SSTP VPN server getting load balanced – by creating a new iRule with name: SSTP_iRule as given in the end of this article.
Virtual Server: Create a new Virtual server – name: SSTP_VirtualServer. Specify the destination IP address, service port as 443 (HTTPS), configuration as `Basic’. For HTTP profile – select SSTP_Http and SSL client profile – select SSTP_Client
Resources: Add the iRule created in step 6 – i.e. SSTP_iRule to the virtual server.

Configuring RRAS as SSTP VPN server

On WS 2008 or later OS, using Server Manager, install RRAS server role inside “Network Policy and Access server” node.
Once installed, configure RRAS server as VPN server – using RRAS configuration wizard (details given in SSTP step-by-step guide - in references).
By default SSTP based VPN server is configured to listen for HTTPS connections coming in from VPN clients – however in this scenario it is required to be configured for accepting HTTP connections. To configure RRAS VPN server to listen for HTTP connections, configure UseHTTPS, ListenerPort, Sha1CertificateHash and Sha256CertificateHash registry keys (details given in KB947030 and KB947054). Basically – you need to specify UseHTTPS as 0 (i.e. listen for HTTP connections), ListenerPort as 80 or some other value on which you will like to listen on HTTP connections (the same MUST be set inside F5 pool), Sha1CertificateHash and Sha256CertificateHash with the thumbprint of the certificate installed on F5 BIGIP (which will be sent to the client during HTTPS connection establishment phase).
Once you have set the regkeys, restart RRAS server.
Follow the same steps on all the RRAS servers hosted behind F5 BIGIP (i.e. for all the nodes created on BIGIP).
And you are all set-to-go and test the stuff.

Testing

Create a SSTP VPN client on Vista SP1 or later OS – give the destination name as the name/IP address of F5 BIGIP virtual server. Note: This must be same as the subject name of SSL certificate installed on the F5 BIGIP SSL certificate.
Install the trusted root certificate on the client machine
Click connect. The HTTPS connection must go through F5 BIGIP virtual server terminating HTTPS connection and redirecting HTTP connection to one of the RRAS server.
For further troubleshooting, look at F5 logs and RRAS event logs.

References

Step-by-step guide: Deploying SSTP Remote Access
KB947030: How to deploy SSTP based VPN server behind SSL load balancer
KB947054: Registry entries that RRAS adds in WS08
Here is the iRule with name SSTP_iRule that must be created on F5 BIGIP to redirect SSTP client connections to a pool of VPN servers:

##################################

when HTTP_REQUEST {

log local0. "HTTP Method: [HTTP::method]"

log local0. "HTTP URI: [HTTP::uri]"

log local0. "HTTP Host: [HTTP::host]"

log local0. "Content Length: [HTTP::header Content-Length]"

if { ([HTTP::method] eq "SSTP_DUPLEX_POST") and

([HTTP::uri] eq "/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/") } {

log local0. "Found SSTP Request, routing to sstp_servers pool"

pool SSTP-Pool

# disable the HTTP profile for the rest of the connection

HTTP::disable

} else {

log local0. "Non SSTP Request, dropping connection. You can change it according to your use"

drop

}

}

##################################

Cheers,

Samir Jain

Senior Program Manager

Windows Networking

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

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

How to change certificate on SSTP server - in Windows server 2008 R2

rrasblog — Wed, 11 Feb 2009 09:38:00 GMT

Hi Folks,

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

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

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

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

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

Pic. 1 Certificate Selection UI

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

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

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

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

c) Choose default option in the drop down menu.

Pic 2: Error Dialog in case of certificate mismatch

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

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

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

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

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

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

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

Netsh Command to configure the cert for SSTP:

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

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

Netsh Command to see the current configured cert for SSTP:

netsh ras show sstp-ssl-cert

Netsh command to see and delete the current SSL binding:

netsh http show sslcert

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

With Regards,

Dhiraj Gupta

Software Design Engineer

Windows Networking Group

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

SSTP support on SBS 2008

rrasblog — Tue, 16 Dec 2008 09:09:00 GMT

Hello,

As you know SSTP support in Windows Server 2008 allows you to configure RRAS server role as SSL based L3 VPN server - which allows VPN clients (currently Vista SP1, WS08 and later releases) to connect from anywhere - behind firewalls/NAT.

If you would like to run Small business server (SBS) on top of WS08 server and will like to use SSTP functionality, here is a good blog which gives you the exact steps required to achieve the same

http://www.c7solutions.com/blog/2009/03/configuring-sstp-vpn-on-small-business_31.aspx

(Special thanks to Yuta Kawamoto for pointing me out of this issue and Brian Reid @ C7 solutions to document the steps out)

With Regards,

Samir Jain

Sr. Program Manager

Windows Networking Group

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

Publishing SSTP based VPN server using ISA2006 Firewall

rrasblog — Fri, 14 Mar 2008 07:47:00 GMT

Hello,

If you will like to use SSTP based VPN server (which is part of RRAS server in Windows server 2008) behind a ISA2006 Firewall, please refer to following articles – Thanks a bunch to Thomas Shinder

http://www.isaserver.org/tutorials/Publishing-Windows-Server-2008-SSL-VPN-Server-Using-ISA-2006-Firewalls-Part1.html

http://www.isaserver.org/tutorials/Publishing-Windows-Server-2008-SSL-VPN-Server-Using-ISA-2006-Firewalls-Part2.html

Samir Jain
Senior Program Manager
Windows Enterprise Networking

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

SSTP Remote Access Virtual Lab Available @ TechNet

rrasblog — Tue, 26 Feb 2008 09:58:00 GMT

Hi All,

Virtual Lab for deploying the SSTP Remote Access is available at http://go.microsoft.com/?linkid=8316925 or http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032370149&EventCategory=3&culture=en-US&CountryCode=US.

Cheers,

Abhishek Tiwari (abhisht@online.microsoft.com **)

Sr. Lead Program Manager

Windows Core Operating System Networking Division

** Remove the "online" to actually email me

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

Getting Certificate from third party Certificate Authorities for SSTP

rrasblog — Thu, 03 Jan 2008 12:46:00 GMT

SSTP as you know requires a machine certificate to be installed on the VPN server.

Most of the times, when the administrators need this machine certificate, they can configure a CA Server and get the certificates from this CA. But for this to work, the CDPs (CRL Distribution Point) need to be published on some server located on the Internet so that the client machines can access it for doing the Certificate Revocation Check during the SSL phase.

If you don't plan to deploy your own CA as well as CDP servers, you can obtain a machine certificate from a third party Certificate Authority.

These third party Certificate Authorities need a Certificate Request file to generate the Certificate requested.This blog is going to tell about how to generate this Certificate Request file on the Windows Server 2008 machine.

Here are the steps to generate the Certificate Request File.

- Go to any Windows Server 2008.

- Open MMC.

- Add the Certificate Snap-in for the “Computer Account”.

- Now, do a right click on the “Peronal” and select “All tasks”->”Advanced Operations”->”Create custom request” as shown below:-

- You will see the following GUI :-

Press “next” on this GUI. You will get the following GUI:-

Press Next on this window. Now, you will get the following GUI which will be used to configure the various properties of the Certificate:-

Click on the “Details” tab which will show the “Properties” tab. Click on this “Properties” tab to set the properties of this Certificate. This will pop up the following new GUI:-

Enter the Certificate’s Friendly name and description of your choice. Sample name and description are entered above.

Press on the “Subject” tab present at the top of this window.. You will see the following GUI:-

On this window, you will need to specify the Subject name of the certificate. Select “Type” as “Common Name” in the Subject Name and then enter the name of the Certificate in the “Value” field. In the above sample, I have entered the IP address of the SSTP Server. You can specify any name also here. Now Press “Add” button.

Now click on the “Extensions” tab present at the top of this window.. You will see the following window:-

In this window, click in front of the “Extended Key Usage (application policies)”. You will have to select the EKU (Extended Key Usage) of the Certificate. This will be “Server Authentication” for SSTP. Select “Server Authentication” and then Press “Add” button.

Now Click on the “Private Key” present at the top of this window. You will see the following window:-

Here, click in front of “Key Options” and then Check the “Make private key exportable”. Press “Apply” button and then Press the “OK” button.

Now press “Next”. You will be shown the following window where you will have to specify the path of the Certificate Request file :-

After specifying the name and path of the certificate request file, press “Finish” button.

A Certificate Request File will be generated in the location you have specified above.

- If you open it with Notepad, it will somewhat look like as follows:-

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIChjCCAe8CAQAwFzEVMBMGA1UEAwwMMTAuMTMxLjEwLjEyMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQC3unAcoIxAx+y5xWB7NXhZlJlvfWes30w9FFmnlpXp
RR56FyQLmtc1H4KtEY/UJNQ/ud/Bi0VL039WaRnISC18gjAlDhFTNX0H14x55PGy
FrX4/0UPdp2opSeI9En8FiPIBYHGP9exjXuLoanWowhluu/pXtdL/vZZzAOxliEG
wQIDAQABoIIBLTAaBgorBgEEAYI3DQIDMQwWCjYuMC42MDAxLjIwRQYJKwYBBAGC
NxUUMTgwNgIBBQwMc3JhLXN0cmVzcy00DBpTUkEtU1RSRVNTLTRcQWRtaW5pc3Ry
YXRvcgwHTU1DLkVYRTBgBgkqhkiG9w0BCQ4xUzBRMBMGA1UdJQQMMAoGCCsGAQUF
BwMBMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwEwHQYDVR0OBBYEFPvbYdsW
c5+59cqXEi9cmQDsnaqPMGYGCisGAQQBgjcNAgIxWDBWAgEAHk4ATQBpAGMAcgBv
AHMAbwBmAHQAIABTAG8AZgB0AHcAYQByAGUAIABLAGUAeQAgAFMAdABvAHIAYQBn
AGUAIABQAHIAbwB2AGkAZABlAHIDAQAwDQYJKoZIhvcNAQEFBQADgYEAMVbeX7Nm
UqRusxQmvKX0OFsfHCRYqGGI73REiKkVskh+Cl1yjgIK0zx14Fzm3Y5PDz8iaKrS
No/jTCPUG4voyjYPFB4YaP2ARBI+InO/a62U9oNYazxzSHmellW9C8PHOs7EtzIu
kFMwB+DxcJ1hGdcCzZMw/fYK2qS6nxmYZHU=
-----END NEW CERTIFICATE REQUEST-----

You will have to make use of this certificate request content to generate the certificate on the Public Certificate Authority.

Thanks,

Amit Kumar
Software Design Engineer/Test (amkuma@online.microsoft.com**),
RRAS, Windows Enterprise Networking, Microsoft.

** Remove the "online" to actually email me

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

How to deploy SSTP based VPN server and IIS on the same machine

rrasblog — Thu, 08 Nov 2007 10: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.

How to change machine certificate on the SSTP server

rrasblog — Thu, 08 Nov 2007 10: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.

Deploying SSTP: Screencast available at

rrasblog — Thu, 11 Oct 2007 06:49:00 GMT

Hi All,

SSTP screencast is available at http://www.microsoft.com/downloads/details.aspx?FamilyID=fc4d7d3f-0376-45bf-9544-ec35329a2fc1&DisplayLang=en

Thanks a bunch, Jim for pulling it through !

This will give screen-by-screen view of how to set-up SSTP in a pilot-lab environment.

Cheers,

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 to restrict SSTP connection to specific IP address (instead of all IP address) on RRAS server

rrasblog — Thu, 04 Oct 2007 17:42:00 GMT

SSTP by default is configured to listen on all the interfaces (i.e. 0.0.0.0 for IPv4 or ::/0 for IPv6). This means RRAS server by default will allow VPN connections to come in from “all” the IPv4 as well as IPv6 addresses that are available on the server machine. The RRAS server sets the machine certificate to HTTPS listener with 0.0.0.0:PortNum and [::]:PortNum.

Background of the problem:
If you want to block SSTP connections to come from specific IP address (v4 or v6) or specific interface, this post helps might be useful for you.

Steps to follow:
This can be done in one of the two ways:
1) By setting the appropriate packet filters inside RRAS or in firewall in-front of RRAS server.

Open RRAS MMC console, go under IPv4 node, click General, select the specific interface (say “Local Area Connection 2”) where you want to block the incoming VPN connections. Double click on the interface and add Inbound filters to drop the TCP connection with destination port 443 and the interface’s own IPv4 address. Do the similar blocking under the IPv6 node. Alternatively this can be configured on some firewall sitting in-front of RRAS.
In this scenario, the HTTPS listener may be listening on all IP addresses:443, but the packet filters will restrict the HTTPS traffic to a specific IP address:443.

OR
2) Configure the HTTPS listener to listen on specific IP address and port

2.1) Find out which machine certificate is configured for the SSTP based VPN connection. This can be done using netsh http show sslcert command. Please look at the certificate with IP:Port pair as 0.0.0.0::/443 and [::]:443 and note down the Certificate hash value. Please look at references for further info

2.2) Remove the all IP address certificate binding from HTTPS Listener
netsh http delete sslcert ipport=0.0.0.0:443
netsh http delete sslcert ipport=[::]:443

2.3) Plumb the new certificate to the HTTPS Listener for specific IP address(assume, the new certificate has SHA1 certificate hash as xxx and IP address is 1.2.3.4 and 3001::1)
netsh http add sslcert ipport=1.2.3.4:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY
netsh http add sslcert ipport=[3001::1]:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

2.4) Configure the appropriate certificate hash inside RRAS (so that RRAS doesn’t try to reset the HTTPS listener on all the IP address and port number). Open regedit and add the following regkey:

Location: HKLM\System\CurrentControlSet\Services\Sstpsvc\Parameters

Regkey Name: Sha256CertificateHash

Regkey Type: REG_BINARY

Regkey Value: SHA256 Certificate hash as noted down in step 2.1)

2.5) Restart RRAS from RRAS MMC console. As HTTPS listener is set to listen on particular IP address:port, it will drop the HTTPS connection coming in from the rest of the IP address:port

References:

How to change the machine certificate of SSTP based RRAS server

Setting up HTTP listener

Verifying VPN server is accepting SSTP connections

SSTP Server FAQ

Debugging SSTP connection failure

Cheers,

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 to change the machine certificate of SSTP based RRAS server

rrasblog — Thu, 04 Oct 2007 16:40:00 GMT

SSTP requires a machine certificate on the RRAS server which needs to be set inside HTTPS listener (i.e. HTTP.SYS). This certificate will be sent to the client during SSL hand-shake stage (like in any other https:// requests). The RRAS server, when configured first time tries read a machine certificate from the machine certificate store and sets it inside HTTPS listener for 0.0.0.0::443 and [::]:443 (i.e. all IP addresses: 443), if it not already set. Otherwise, it keeps it untouched.

Please note: The HTTPS listener can have only one certificate for a given IP address/port number pair. This means if you have RRAS, IIS and the additional web listeners (like TS gateway) sitting on top of HTTPS listener, then you need to ensure all the different server roles are using the same certificate for a given IP address/port number pair.

Background of the problem:
Let us assume that you have already installed a machine certificate and configured the RRAS server once. But later you want to change the certificate (like a new certificate is provisioned or existing one expired or you want to explicitly provision a specific certificate to RRAS inside of RRAS selecting on its own etc) without reconfiguring RRAS from scratch. This post helps you to know insights on how to change the machine certificate.

Background of the components involved:
There are three components involved: -
a) The machine certificate that is installed inside "computer account" of certificate store.
b) The HTTPS listener component that terminates all the HTTPS connections and is plumbed with a machine certificate (note: please use the following command to figure out which certificate is bound to HTTP listener: netsh http show sslcert)
c) The RRAS server which sits on top HTTP.SYS that terminates the SSTP based VPN connections. It also uses the certificate hash of machine certificate for its crypto-binding validation phase (which is an extra security cover to ensure PPP client and SSL client is originated from the same machine to avoid man in the middle attack).

If you want to change machine certificate, you need to ensure all the three components are kept in sync (i.e. RRAS & HTTP listener are plumbed with same certificate and certificate is actually present in the machine store).

Steps to change the machine certificate:
1) Find out which machine certificate is configured for the SSTP based VPN connection. This can be accomplished using one of the following steps:
1.1) Run the following netsh command on server side to figure out the SSL certificate plumbed to HTTP.SYS.
netsh http show sslcert
Please look at the certificate with IP:Port pair as 0.0.0.0::/443 and [::]:443 and note down the Certificate hash value. Please refer to the Setting up the SSTP listener blog (as referenced below) for further details.

1.2) On the VPN client machine, open your web browser and type in the following URL (assume myvpn.contoso.com is your VPN server name)

https://myvpn.contoso.com/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/

View the certificate inside the browser (e.g. IE7 prints the certificate inside the lock shown next to address bar) and note down the certificate hash value.

2) Now delete that certificate from the server certificate store (local computer store)
Open 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 (Double click on the node). Expand the 'Personal' node ( Double-click on the node). Click on 'Certificates' sub-node under this.

On the certificates pane, you will see a list of certificates in the store. Double click 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. Compare the value of the field 'Thumbprint' with the value of the certificate hash we saw in step 1) from netsh http show sslcert command. If it is same, then it means this is the certificate that is bound to the HTTPS listener. Right-click and delete the certificate.

3) Remove the certificate binding from HTTPS Listener
netsh http delete sslcert ipport=0.0.0.0:443
netsh http delete sslcert ipport=[::]:443

4) Remove the certificate binding in RRAS. Open regedit and delete the following regkeys (if present)
HKLM\System\CurrentControlSet\Services\Sstpsvc\Parameters\Sha256CertificateHash

HKLM\System\CurrentControlSet\Services\Sstpsvc\Parameters\Sha1CertificateHash

5) Add the new certificate inside the certificate store (local computer store)

6) Plumb the new certificate to the HTTPS Listener (assuming new certificate has SHA1 certificate hash as xxx)
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

7) Restart RRAS from RRAS MMC console. RRAS will read the certificate that is plumbed to the HTTPS Listener and records the appropriate certificate hashes regkeys for its crypto-binding validation phase.

References:

Setting up HTTP listener

Verifying VPN server is accepting SSTP connections

SSTP Server FAQ

Debugging SSTP connection failure

Cheers,

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 to debug SSTP specific connection failures

rrasblog — Wed, 26 Sep 2007 14:26:00 GMT

Hi All,

To all our beta testers who are trying out SSTP, first of all "many many thanks from my RRAS team". This post talks about how to debug failures specific to SSTP based VPN tunnel

(Note: I am not discussing all the error codes displayed on RAS client - as most error codes will be common across all VPN tunnels i.e. PPTP, L2TP, SSTP - like when remote access policy fails or authentication fails or server doesn’t support required port etc).

The common failure scenarios when the the VPN client is not able to connect to SSTP server and gets different error codes are:

Symptom1: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800704C9
Trouble-shooting steps: This can happen if either remote access is disabled on the server OR no SSTP ports are free on the server OR server is not listening on the appropriate port number. Ensure remote access and SSTP services are running on the server by running following commands on command prompt: “sc query remoteaccess” and “sc query sstpsvc”. If they are disabled, start it using RRAS MMC snap-in or services snap-in. Ensure RRAS server has sufficient number of ports configured – open RRAS MMC Snap-in, go under Ports->Properties and see SSTP ports. Check whether it is listening on correct port number by running following command on command prompt: netstat –aon

Symptom2: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x80070040
Trouble-shooting steps: This can happen if the server authentication certificate is not installed on the RRAS server. Open MMC certificate snap-in for “Computer Store” on the server side, go under “Personal”->”Certificates” and see if the appropriate certificate of type “Server Authentication” is installed.

Symptom3: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800B0101
Trouble-shooting steps: This can happen if the server authentication certificate is expired. Open MMC certificate snap-in for “Computer Store” on the server side, go under “Personal”->”Certificates” and see if the appropriate certificate is valid and not expired. If expired, renew the certificate

Symptom4: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800B0109
Trouble-shooting steps: This can happen if the appropriate trusted root CA certificate server is not installed on the client side. This certificate normally gets installed if you join the machine to the domain and using the domain credentials to log-on to VPN server. But if you are using some other certificate chain OR this machine is not joined to correct domain (like a home machine), then it is possible.
Open MMC certificate snap-in for “Computer Store” on the client side, go inside “Trusted Root Certificate Authorities” and check whether relevant CA is installed. If not, install the same.

Symptom5: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800B010F
Trouble-shooting steps: This can happen if the destination hostname in VPN connection (i.e. VPN server name) does not match the SSL server certificate subject name sent from server to client. Open MMC certificate snap-in for “Computer Store” on the server side, go under “Personal”->”Certificates” and see if the appropriate certificate with correct subject name (i.e. matching the VPN server name) is correct. If you are using the destination name as IPv4 or IPv6 address on the VPN client, then you need to install the appropriate certificate (i.e. subject name = IP address) on the server side. If you are using destination name as DNS based hostname, then you need to install the appropriate certificate (i.e. subject name = full name with which client connects).

Symptom6: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x80092013
Trouble-shooting steps: This will happen if client is failing the certificate revocation check of the SSL certificate obtained from server side.

This can happen because of two reasons:

a) Ensure the CRL check servers on the server side are exposed on the Internet (i.e. are available on the Internet). This is because CRL check is done on the client side during SSL connection establishment phase and the CRL check query will be directly going on the Internet (and not on top of VPN connection because it is not up yet).
b) CRL URL that is set inside the machine certificate on RRAS server is pointing to the internal DNS name (e.g. myvpn.contoso.local) and not the external name (special thanks to one of our esteemed customers, Bill Voltmer, in pointing this out). To validate this, open the certificate snap-in on your RRAS server, go to details tab and look at "CRL distribution point" field. To fix this:

1. Open Server Manager and navigate to Roles, Active Directory Certificate Services

2. Right click on CA name (e.g. mycompany-vpn1-CA) and choose Properties.

3. Click Extensions tab.

4. Select the pre-existing http: URL and click Remove.

5. Click Add…

6. Type http://

7. Type external URL of VPN server

8. Type CertEnroll/

9. Insert variable <CaName>

10. Insert variable <CRLNameSuffix>

11. Insert variable <DeltaCRLAllowed>

12. Type .crl

13. Check boxes Include in CRLs… and Include in the CDP…

The above should be done before SSTP VPN is configured on RRAS. Or if it is already configured, change the machine certificate by following this blog.

Symptom7: Client tries to connect to SSTP VPN server and it fails to connect giving error message 809
These are the trouble-shooting steps because reasons can be multi-fold

a) This can happen if any firewall between client and server is blocking the SSTP connection.

b) check the proxy settings on the client (i.e. open the Internet explorer and go under inside Tools->Internet Options->Connections) and see if it is correct – you can also check to see if you are able to access other Internet sites.

c) This can also happen if SSTP service or remote access service is stopped on the RRAS server side. Ensure remote access and SSTP services are running on the server by running following commands on command prompt: sc query remoteaccess and sc query sstpsvc. If they are stopped, start it using RRAS MMC snap-in or services snap-in.

d) Ensure SSTP service is listening on TCP port 443 (or the appropriate port number on which you have configured) by running “netstat –aon | findstr 443”.

e) See the server certificate plumbed to http.sys using “netsh http show sslcert”. See the IP address and port number of the certificate – RRAS reads only ::0 or 0.0.0.0.

f) Ensure the same server certificate is present in the machine store by opening MMC certificate snap-in for “Computer Store” and going under “Personal” certificate. Ensure that certificate is valid and not expired.
Ensure the same certificate hash is present under Sha256CertificateHash or Sha1CertificateHash regkeys.

g) Ensure RRAS inbound/outbound filters are not blocking SSTP connections. Open RRAS MMC Snap-in, go under IPv4->General or IPv6->General. Select the appropriate interface and see the properties->Inbound/Outbound filters. See if the appropriate port number (default TCP port 443) is enabled.

h) Ensure Windows firewall is not blocking SSTP connections. Open Firewall and see if SSTP is added to exception.

i) Ensure some other firewall infront of RRAS server is not dropping the connection (i.e. TCP port 443 connection are blocked towards RRAS server). Revisit your network topology.

j) Look for the events inside eventvwr and look for events from remote access and SSTP service.

If you cannot still figure out, feel free to contact us at our blog email alias given above

With Regards,

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