test's questions

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.

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

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

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.

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:

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:

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.

I have a SQL Server instance, Instance1, that has a linked SQL Server, Instance2. The linked server technically works, however I am positive that Instance1 is connecting to Instance2 via Named Pipes. I can see this very clearly by testing a sample query using TCP/IP and Named Pipes. Query run times are a difference between <1 second for TCP/IP and >45 seconds for Named Pipes.

Can I force the linked SQL Server on Instance1 to use TCP/IP when connecting to Instance2? I have not been able to find any information relating to this, do I have any other options if this can't be done?

I tried creating the linked server by specifying the port but it seems to use Named Pipes anyway, i.e., I created it as Instance2,1433. Is there maybe a way to tell the master database to use TCP/IP for linked servers?

Any help is greatly appreciated. I'm hoping the answer is not "Turn off Named Pipes in Instance2 SQL configuration" although I realize I might have to do that if I can't get this to work.

Edit: I have without a doubt verified that it is Named Pipes that is causing the problem, and I've seen this same problem with Named Pipes before (it's well documented behaviour of Named Pipes). I just haven't seen how to solve it when using Linked Servers.