Routing and Remote Access Blog : SSTP, Troubleshooting

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

Setting up the SSTP listener and verifying it

rrasblog — Tue, 06 Mar 2007 22: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.]