Scenario:
On a Windows Server 2008 machine running ISA/Threat Management Gateway Medium Business Edition, you enable the SSTP for VPN connectivity. After a reboot, the server no longer handles server publishing on HTTPS (tcp 443) correctly.
TMG/ISA was set to publish on all IP addresses on the Internet network, as seen here:
Error message:
The Web Proxy filter failed to bind its socket to <ip address> port 443. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure. The failure is due to error: 0x8007271d
Solution:
Restarting the Firewall Service (as instructed) does restore the publishing rule, but breaks RRAS connectivity, and also requires additional steps each time the server is rebooted. Move the SSTP publishing port to another port instead.
- Locate the following registry path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters
- Locate the entry ListenerPort, data type REG_DWORD
- Edit the value from 0 to 86 (decimal), to bind the SSTP service to tcp port 86 (and therefore away from 443, allowing TMG to properly publish the HTTPS/SSL servers. You can use the ListenerPort registry entry to change the server-side TCP port on which the SSTP server listens. You can set this value to any valid 16-bit port number. If the value is set to 0, the SSTP server listens on the default port number, depending on the value of the UseHTTPS registry entry. See [3] for more information about these registry settings.)
- Reboot the server.
Discussion:
This is to be expected, since the SSTPSVC service will bind to port 443 to service the VPN requests. Move the SSTP port publishing to another port and use TMG to (optionally) publish the port.
First, verify that the SSTP service is indeed causing the trouble. I downloaded TCPView from SysInternals, but you can pick your own tool if you wish. This is what I saw when I fired it up, showing System (the kernel) having bound to HTTPS, thereby preventing TMG from properly binding to the port to publish my SSL server.
Doing some searching, I found that netsh was used in Server 2008 to configure the kernel level socket pooling for IIS 7.0 [1]. That made sense. At this point, I was suspecting TMG's own reporting service to be the cause, since it had installed IIS, and since I didn't remember activating SSTP on the TMG box.
So I figured I'd try to remove the entries via netsh, using show urlacl and show sslcert, then deleting the appropriate entries.
IP:port : 0.0.0.0:443
Certificate Hash : 47db64e8ea425333bbd7e5c847df00b3254f2d57
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
delete sslcert ipport=[::]:443
delete sslcert ipport=0.0.0.0:443
(I tried to delete https://+:443/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ , as well.) Upon reboot, however, I found that the urlacls were being recreated. [ http://justinho.com/files/media/image/SSL-03.png and http://justinho.com/files/media/image/SSL-04.png ]
Then I noticed this line: User: NT SERVICE\SstpSvc in the show urlacl command. Bingo.
I immediately went to remove the SSTP role from the server. However, I found that removing the RRAS/SSTP role and rebooting the server did not fix this; the SSTPSvc was still started, and still recreating registry entries, and binding to tcp 443.
I therefore went to configure SSTP to bind to a different port to workaround this problem [2] [3].
Based on the information in [3], I opened regedit and went to this path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters and changed the ListenerPort to decimal value 86, to bind SSTP to tcp port 86 instead of 443.
From [3]: You can use the ListenerPort registry entry to change the server-side TCP port on which the SSTP server listens. You can set this value to any valid 16-bit port number. If the value is set to 0, the SSTP server listens on the default port number, depending on the value of the UseHTTPS registry entry. For example, if the UseHTTPS registry entry is set to 1, the default listener port number is 443. If the UseHTTPS registry entry is set to 0, the default listener port number is 80. The ListenerPort registry entry is typically useful in configurations where the VPN server is behind a Network Address Translation (NAT) router or behind a reverse proxy. Notice that SSTP clients always connect to the TCP 443 port. This behavior cannot be configured from the clients.
Summary: If UseHTTPS is set to 1, SSTP will listen on 443 if ListenerPort is set to 0. Since we want TMG to listen on 443, change ListenerPort to 86 (decimal).
After binding the SSTP service to port 86, rebooted my server, and my SSL/HTTPS sites were happily published.
[1] http://technet.microsoft.com/en-us/library/cc725882.aspx
[2] http://support.microsoft.com/kb/947032 How to configure a Secure Socket Tunneling Protocol (SSTP)-based VPN server behind a NAT device in Windows Server 2008. This article describes how to configure a Secure Socket Tunneling Protocol (SSTP)-based VPN server behind a network address translation (NAT) device in Windows Server 2008.
[3] http://support.microsoft.com/kb/947054 Registry entries that Routing and Remote Access adds in Windows Server 2008.