Nuts and Bolts VPNs with SSTP Lead image: © Maxim Kazmin, 123RF.com

State-of-the-art virtual private networks

Private Affair

Because Microsoft's legacy VPN protocol, PPTP, has a couple of vulnerabilities, SSTP, which routes data via an SSL connection, was introduced as the new VPN protocol with Vista, Windows Server 2008, and Windows 7. By Thomas Drilling

Virtual private networks (VPNs) have established themselves as a standard solution for convenient remote access to enterprise networks. However, they can cause some issues in combination with standard tunneling protocols like PPTP if, for example, NAT routers are involved or you need to work around the local firewall. Typically, it is not in the administrator's best interest to modify the firewall, NAT, or proxy configuration to suit requirements for remote access. The Secure Socket Tunneling Protocol (SSTP), which was introduced with Microsoft Windows Server 2008, provides a solution by setting up a VPN tunnel that encapsulates PPP or L2TP traffic on a Secure Sockets Layer (SSL) channel (Figure 1).

For administrators, this means that SSTP is a new VPN tunnel type in the Windows Server 2008 routing and RAS server role. It encapsulates PPP (point-to-point protocol) packets in HTTPS, thus supporting the VPN connection through a firewall, a NAT device, or a proxy. Like all SSL VPNs, SSTP uses TCP port 443 (HTTPS) for data transfer. Compared with other commercial or proprietary solutions (e.g., IPsec, L2TP, or PPTP), the advantage is that port 443 is open in almost any router or server configuration, and SSTP packets can thus pass through without any additional configuration overhead. The "Handshake" box explains what Windows does with all of these protocols.

Handshake

Microsoft's SSTP is basically another proprietary implementation of an SSL VPN. SSTP relies on standards such as SSL and TLS for encryption and authentication, but Microsoft has modified the tried-and-trusted SSL handshake by introducing proprietary extensions that bind the proprietary PPP protocol. If you look at the basic handshake, SSTP at first keeps to the standard SSL handshake procedure:

1. The client opens a connection to TCP port 443 on the server.

2. The client sends an "SSL Session Setup Message" to indicate that it wants to set up an SSL connection to the server.

3. The server sends an SSL certificate to the client.

4. The client validates the server certificate, identifies the correct encryption method for the SSL session, and creates a session key, which it encrypts using the public key from the server certificate.

5. The client sends the encrypted SSL session key to the server.

6. The server decrypts the client's SSL session key using its own private key and encrypts the communications with the session key. Up to this point, the procedure is no different from standard SSL communication. However, Microsoft then implements additional handshake steps that build on what has happened thus far.

7. The client sends an HTTP-over-SSL request message to the server and negotiates an SSTP tunnel with the server.

8. After this, the client negotiates a PPP connection with the SSTP server, which includes authenticating the user's login credentials with a PPP authentication method and configuring the settings for the data traffic.

9. The client starts to transfer data via the PPP connection.

Strong encryption in SSL 3.0 ensures maximum security and performance. SSTP VPNs are thus a class of SSL VPNs, like Cisco's WebVPN or the Vigor Router by Draytek, that basically work in the same way as IPsec, L2TP, or PPTP, but use SSL to handle the data transfer. Because SSTP encapsulates complete IP packets, the connections act just like a PPTP or IPsec tunnel on the client side. According to the Microsoft definition, SSTP is a protocol mainly intended for dialup connections in the application layer that guarantees the confidentiality, authenticity, and integrity of the data to be transferred. A public key infrastructure (PKI) is used for authentication purposes. Microsoft introduced SSTP with Windows Server 2008 and Vista SP1. Today, Windows Server 2008 R2 and Windows 7 also support SSTP [1]. But what does SSTP offer the administrator, and how do you set up a VPN server with SSTP?

Sample Scenario

In this example, I am using Windows Server 2008 R2 to provide an SSTP-based VPN server behind a NAT device. The server is configured as the domain controller and needs two network cards for the VPN setup. At least one card (preferably both) needs a static IP address. The client will be MS Windows 7.

The server and clients are both members of an Active Directory (AD) domain. Additionally, the server and clients should have all the current updates in place, such as the current Service Pack 2 for Windows Server 2008 R2. After installing a Windows server, you need to install the Active Directory Domain Services to make the server a domain controller. The easiest way to do this is to run dcpromo at the command line and then follow the wizard.

The server also needs to provide DNS, DHCP, and certificate services, which you can achieve by configuring the matching server roles in the role wizard. VPN functionality is also provided via a server role Network policy and access services.

PKI

Because SSTP uses HTTPS (port 443) to handle all the data traffic, there is no alternative to configuring a public key infrastructure. At a minimum, this means installing at least one certificate on the SSTP server and a root certificate authority certificate on all SSTP VPN clients. You might have to modify the packet filter rules, too, even though SSTP doesn't actually need any additional NAT configuration because port 443 is typically open. The "Port Customizer" box explains how you can use a port other than 443 for SSTP.

Port Customizer

SSTP normally uses TCP port 443, which is open in most router and NAT configurations. Security-conscious Windows administrators might prefer to modify the standard port used by SSTP. To do so, you need to edit the following registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters

in the Registry Editor. Look for the ListenerPort parameter. Changing the view to Decimal (right-click) lets you specify a different port. Then you need to restart the Routing and RAS service. If you change the ListenerPort, you need to reconfigure your NAT device to match and forward all incoming traffic addressed to port 443 to the newly configured port on the SSTP-based VPN server.

Next, you'll need to configure an Active Directory-integrated root certification authority on the domain controller. In combination with a group policy, this causes clients that are domain members to request certificates automatically when they open a connection. Certificates are then issued by the domain controller and placed in the client's local certificate store along with the certification authority certificate. If you are unable or prefer not to purchase a commercial certificate, you can use a private certificate issued by Active Directory's built-in CA. The "Setting up a Certification Authority" box explains how to do this.

You need to configure the firewall to allow network traffic to pass through to the certificate authority in order for the certificate request to work. To get this to happen, the firewall must also be authorized to request certificates (Figure 2). You can set this up under the Web Server Properties Security tab; Read and Enroll privileges are required at minimum.

Figure 2: If you are unable to request a certificate, you can check the privileges in the certificate template for web servers to see whether Enroll is allowed.

In production, it often makes more sense to purchase a commercial certificate and install a dedicated firewall server with Microsoft's new Forefront Threat Management Gateway (TMG) 2010 [2].

The gateway offers a wizard-based configuration in the TMG management console. Note that you cannot install the Forefront 2010 server component on a domain controller. Additionally, you will want to publish a certificate revocation list in a production scenario.

Revocation

A Certificate Revocation List (CRL) details any certificates revoked before their expiry date. Revocation lists are always available at CLR Distribution Points (CDPs). A CDP can be set in the Extensions tab of the CA Properties dialog box (Figure 3).

Additionally, the certificate revocation list must be accessible to all clients at all times via the Internet, which will mean configuring the packet filter on the local firewall. In Forefront TMG 2010, you can use the website publishing wizard for this.

VPN Server

Setting up the VPN server itself is easily done. Once you have added the network policy and access services role by clicking Add roles in the Customize this server section of the Server Manager, the Routing and Remote Access tool is available below Management. The Action | Configure and enable routing and RAS button takes you to the Routing and Remote Access Server Setup Wizard.

At the second Configuration step (Figure 4), you'll want to enable Virtual private network (VPN) access and NAT, then click Next and select the required network interface. At the following step, Address assignment defines how the VPN server assigns IP addresses to remote clients. If you have the DHCP service running, Automatic is the quickest and cleanest option. Then you can define an IP address pool for the DHCP server to use in the next step, Address range assignment.

Figure 4: You need to set up the RAS services to run a VPN server.

In the final step, you can choose whether or not to use a Radius server to authenticate clients on a large-scale network; this is disabled by default. The wizard will then instruct you to set up the DHCP relay agent for Windows to support the forwarding of DHCP messages to RAS clients. To do this, you need to enable the Relay DHCP packets option in the DHCP Relay Properties dialog box (Figure 5).

Figure 5: Configuring Windows to forward DHCP messages to the RAS clients.

Conclusions

Microsoft's SSTP encapsulation structure is like a Russian doll. Just as with PPTP, Microsoft uses the PPP protocol with SSTP, which leads to a fairly complex encapsulation structure (see Figure 6), in which an IP header contains a TCP header, which in turn contains an SSTP header, which then contains a PPP header, which finally contains the IP packets themselves.

Figure 6: The SSTP encapsulation structure is like a Russian doll. Microsoft has gone to considerable trouble to make something proprietary from what are basically open protocols. From a technical point of view, there seems to be no real reason to use PPP.

Although the method seems to be slightly more efficient than Encapsulating Security Payload (ESP), with an overhead of 8 bytes in the PPP header, compared with 20 bytes in IPsec over HTTPS, there is actually no real need to encapsulate in PPP packets. In IPsec, ESP builds directly on IP. Microsoft is quite obviously seeking to set itself apart by encapsulating in PPP.

Apart from the fairly complex Windows server configuration, which mainly involves setting up the certificate services, and possibly packet filters for transporting the certificate requests, SSTP offers a secure, well-performing tunnel technology for the future.