Windows Server 2012 SSTP stops listening to port 443, how to resume listening without a server restart

rrassstpvpnwindows-server-2012-r2

I have a Windows 2012 R2 Standard Server setup with an SSTP VPN that is working for the most part. I have been able to connect to this VPN from an external computer and use everything properly.

Routing and Remote Access Uptime

The issue comes in when the server stops listening on port 443, as seen below:

Command Prompt netstat find 443

I thought that I'd be able to just restart the RRAS and have it start listening again on port 443:

Restart RRAS

But it doesn't seem to work. Everything restarts properly, but it does not resume listening on port 443. Here is a Running snapshot of the services relevant to the VPN/Remote access.

The somewhat funny aspect of this is that I am currently remote as I'm writing this and I've had to resort to using Remote Desktop to diagnose this issue, and if I end up not being able to figure it out I'll have to restart the server to have it start listening again on port 443. I obviously don't want to do that as it disrupts the office and is also a bad idea.

Running Remote Services

I found the following entries from the Event Log that seemed relevant to this issue, but I'm not sure. There are quite a few of both of these.

ID: 36888 Severity: Error Source: Schannel Log: System

A fatal alert was generated and sent to the remote endpoint. This may
result in termination of the connection. The TLS protocol defined
fatal error code is 10. The Windows SChannel error state is 1203.

and

ID: 8016 Severity: Warning Source: Microsoft-Windows-DNS Client Events Log: System

The system failed to register host (A or AAAA) resource records (RRs)
for network adapter with settings:

       Adapter Name : {B34E76CF...}
       Host Name : <NAME>
       Primary Domain Suffix : <DOMAIN>
       DNS server list :
          ::1, 192.168.0.1
       Sent update to server : <?>
       IP Address(es) :
         192.168.0.166

The reason the system could not register these RRs was because the DNS
server failed the update request. The most likely cause of this is
that the authoritative DNS server required to process this update
request has a lock in place on the zone, probably because a zone
transfer is in progress.

You can manually retry DNS registration of the network adapter and its
settings by typing ipconfig /registerdns at the command prompt. If
problems still persist, contact your DNS server or network systems
administrator.

I did purchase a Comodo certificate for my VPN domain which is bound when I go to the RRAS server properties:

Server Properties

I've also navigated to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters and can see that the SHA hashes seem to match my bound certificate:

Registry Editor SstpSvc Parameters

I'm trying to figure out:

  1. Why the server seems to arbitrarily stop listening to port 443 (so I can prevent it) and…
  2. How do I get the server to start listening again on port 443 without a server restart?

I hope I've included enough information, if I'm missing anything let me know. Keep in mind everything in my setup works if the server is listening on port 443. This is why I'm quite confused as to what is happening.


Edit #1 @ 2017-07-21 10:13 PM UTC

Some additional investigation has shown me that the service responsible for listening on port 443 (SstpSvc) is running when I am facing the above described issues. Restarting it does not resolve the problems. I'm not seeing any errors in the Event Viewer for this service when restarting.


Best Answer

Your's is the most comprehensive question so I will provide my input here.

From my testing in Windows Server 2012 R2, I can restore this functionality without rebooting by doing the following:

Restart w3svc

Restart sstpsvc

Unfortunately you have to force the restart of sstpsvc, which also requires Routing and Remote Access to restart, effectively disconnecting your users. Much faster to restart than a full reboot, but unfortunately still interruptive.

If you want to script it with powershell, you can:

Restart-Service -Name w3svc
Restart-Service -Name sstpsvc -Force

I have monitoring running on this, so maybe I can identify why this is happening. My current theory is that w3svc is managing the TLS for the SSTP sessions, and that stops working along the way.