1

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.

test
  • 131
  • 2
  • 6
  • `0:0:0:0:443 LISTENING and [::]:443 LISTENING` - The server **IS** listening on port 443 on all interfaces for both IPv4 and IPv6. – joeqwerty Jul 21 '17 at 17:45
  • @joeqwerty Yeah, but look at the last command. It returns nothing. The picture is showing it was listening, and now it's not. – test Jul 21 '17 at 18:26
  • Ah, my bad. I missed that. Apologies. – joeqwerty Jul 21 '17 at 20:10

2 Answers2

2

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.

GregAndo
  • 21
  • 2
0

Can you set the Recovery options on the service to simply restart when it shuts down?

enter image description here

There is a likelihood that it shuts down due to inactivity. ( I just grab telepohony service here to show the settings) Set days to 0 and minutes to 1 for the restart to happen.

htm11h
  • 170
  • 11
  • I could but I'm not sure how this will help. The services are all still running, the issue is that they aren't listening to port 443. If I restart the services they still don't fix the issue, only with a reboot of the server does it resume listening. – test Jul 21 '17 at 20:12
  • Even though netstat does not find the port are you able to connect? – htm11h Jul 21 '17 at 20:33
  • No, the VPN service is using SSTP and is expecting to connect through a listening port 443. If port 443 is not being listened to, the client cannot connect. – test Jul 21 '17 at 20:40
  • I understand that, I was just confirming that you received a failure of some sort on the connection attempt. You don't mention an error or any other indication of a failed attempt in the OP, other than it doesn't seem to work, only that the port is not reporting as listening. Have you checked the Event Logs or added any auditing? I would also suggest that you check with Comodo support, there may be an issue they could shed some light on. – htm11h Jul 21 '17 at 20:58
  • The client will receive a timeout error, code 0x8007274C. I didn't include the error on the client side because it didn't really seem to matter, I know that the client can connect if the port is open. I perused the Event Viewer and put a couple in my post but I haven't seen anything that has been helpful for this. I haven't added any auditing. – test Jul 21 '17 at 21:01
  • What about a possible Memory issue. Either your client or your server may have an issue here. Usually, what happens is your system can not support the decryption and/or buffering required so the session is aborted. Try clearing your cache to get a fresh start. – htm11h Jul 24 '17 at 12:48