The Cable GuyThe Secure Socket Tunneling Protocol

Joseph Davies

This column is based on a prerelease version of Windows Server 2008. All information herein is subject to change.

Virtual private network (VPN) support in Windows XP and Windows Server 2003 allows you to connect to your private intranet across the Internet, just as if your computer was plugged into a local Ethernet port. However, the VPN protocols in Windows XP and Windows Server 2003 don’t work for some firewall configurations

and for some indirect configurations—such as when your computer is behind a Network Address Translator (NAT) or Web proxy server—in which the traffic for VPN connections is being blocked. To resolve these difficulties, Windows Server® 2008 and Windows Vista Service Pack 1 include support for the new Secure Socket Tunneling Protocol (SSTP).

VPN Access Problems

In Windows® XP and Windows Server 2003, the VPN protocols that enable remote access connections to an intranet across the Internet are the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPsec). They provide the encapsulation of the packets sent between a remote access client and the intranet to which it is connected.

PPTP-based VPN traffic consists of a TCP connection to TCP port 1723 on the VPN server to perform tunnel maintenance, and Generic Routing Encapsulation (GRE)-encapsulated packets for VPN data. But PPTP traffic can have problems with firewalls, NATs, and Web proxies. To prevent problems, firewalls must be configured to allow both the TCP connection and the GRE-encapsulated data. Although GRE is a standard method of encapsulating IP packets, many Internet service providers (ISPs) drop these packets, resulting in lost data. In addition, the connections found in hotels and coffee shops are typically configured for normal Web and e-mail traffic and may not allow PPTP traffic. Moreover, if your computer is behind a NAT, the NAT must be able to translate the GRE traffic. If it can’t, you’ll be able to establish the TCP connection but you won’t be able to send or receive any GRE-encapsulated data. Lastly, PPTP traffic cannot flow through a Web proxy.

The other VPN protocol at work in Windows XP and Windows Server 2003, L2TP/IPsec, uses Internet Key Exchange (IKE) to negotiate the IPsec Encapsulating Security Payload (ESP) protection of the VPN traffic, and it too can have problems with firewalls, NATs, and Web proxies.

In this setup, firewalls need to be configured to allow both the IKE traffic and ESP-encapsulated data. If your VPN client computer is behind a NAT, both the VPN client and the VPN server must support IPsec NAT-Traversal (NAT-T). Note, however, that the VPN server can’t be located behind a NAT, and that L2TP/IPsec traffic can’t flow through a Web proxy.

The New VPN Solution

As you can see, there are a number of issues around VPN protocol operation in Windows XP and Windows Server 2003. The good news is that SSTP in Windows Server 2008 and Windows Vista Service Pack 1 solves these VPN connectivity problems by using HTTP over secure sockets layer (SSL). SSL is also known as Transport Layer Security (TLS). HTTP over SSL on TCP port 443 is the protocol that has been used on the Web for some time for collecting credit card numbers and other private data. Whenever you connect to a Web address that begins with https:, you are using HTTP over SSL.

Using HTTP over SSL solves many VPN protocol connectivity problems—firewalls, NATs, and Web proxies typically allow this type of traffic because it’s so widespread.

SSTP uses an HTTP-over-SSL session between VPN clients and servers to exchange encapsulated IPv4 or IPv6 packets. Note that an HTTP-over-SSL-based remote access VPN connection is different from the connection made by an application that uses HTTP over SSL. For example, Outlook® Web Access (OWA) lets you access your Microsoft Exchange e-mail at your enterprise over the Internet. OWA uses an HTTP over SSL-encrypted session, but this is not the same as a remote access connection. Although you can view your e-mail with OWA, you can’t reach the location of an intranet URL that is embedded within an Exchange e-mail message.

(SSTP does not support authenticated Web proxy configurations, in which the proxy requires some form of authentication during the HTTP Connect request.)

An HTTP-over-SSL implementation in Windows can substantially lower the cost of maintaining your remote access solution. For example, HTTP over SSL results in fewer help desk support issues and eliminates issues related to VPN servers being placed behind NATs. And, since SSTP works just about everywhere, users are happier and more productive.

Because SSTP is built into Windows, you don’t have to be concerned with third-party VPN client software to install and manage on client computers, or with extra software to install on the VPN server. Additionally, SSTP can provide better load balancing of VPN connections through available SSL load balancers.

New SSTP Features

• SSTP has integrated support for Network Access Protection (NAP), which can be used to better protect network assets by enforcing compliance with system health requirements. For more information about NAP, see microsoft.com/nap.
• Also, SSTP supports native IPv6 traffic sent inside the SSTP tunnel and IPv6-based SSTP connections across the IPv6 Internet.
• Furthermore, SSTP establishes a single HTTP over SSL session from the SSTP client to the SSTP server. Other third-party SSL-based VPN solutions use two HTTP over SSL sessions. Using a single HTTP over SSL session provides lower network utilization and better load balancing.
• Finally, SSTP is fully integrated into the VPN client components of Windows Server 2008 and and Windows Vista Service Pack 1 and Routing and Remote Access in Windows Server 2008. SSTP is another VPN protocol and can use all of the same authentication protocols and configuration methods—such as the Network Connections folder and Connection Manager—that are used for PPTP or L2TP/IPsec-based connections.

Unlike the PPTP and L2TP/IPsec protocols in Windows XP and Windows Server 2003, SSTP does not support site-to-site VPN connections.

SSTP in Windows

A computer running Windows Server 2008 and Routing and Remote Access is an SSTP-based VPN server. You don’t have to install IIS because Routing and Remote Access listens to incoming connections on the specific Uniform Resource Identifier (URI) /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/. However, Routing and Remote Access and IIS can coexist on the same server.

A computer running Windows Server 2008 or Windows Vista Service Pack 1 is an SSTP-based VPN client, capable of initiating SSTP connections to an SSTP-based VPN server. The SSTP server must have a computer certificate with the Server Authentication or All-Purpose Enhanced Key Usage (EKU) property installed. This computer certificate is used by the SSTP client to authenticate the SSTP server when the SSL session is established. The SSTP client validates the computer certificate of the SSTP server. To trust the computer certificate, the root certificate authority (CA) of the issuing CA of the SSTP server’s computer certificate must be installed on the SSTP client.

Figure 1 compares attributes of the different VPN protocols in Windows Server 2008 and Windows Vista Service Pack 1. The sidebar "New SSTP Features" describes SSTP features.

Figure 1 Comparing the different VPN protocols

How SSTP Works

When a user on a computer running Windows Server 2008 or Windows Vista Service Pack 1 initiates an SSTP-based VPN connection, the following occurs:

1. The SSTP client establishes a TCP connection with the SSTP server between a dynamically-allocated TCP port on the client and TCP port 443 on the server.
2. The SSTP client sends an SSL Client-Hello message, indicating that the client wants to create an SSL session with the SSTP server.
3. The SSTP server sends its computer certificate to the SSTP client.
4. The SSTP client validates the computer certificate, determines the encryption method for the SSL session, generates an SSL session key and then encrypts it with the public key of the SSTP server’s certificate.
5. The SSTP client sends the encrypted form of the SSL session key to the SSTP server.
6. The SSTP server decrypts the encrypted SSL session key with the private key of its computer certificate. All future communication between the SSTP client and the SSTP server is encrypted with the negotiated encryption method and SSL session key.
7. The SSTP client sends an HTTP over SSL request message to the SSTP server.
8. The SSTP client negotiates an SSTP tunnel with the SSTP server.
9. The SSTP client negotiates a PPP connection with the SSTP server. This negotiation includes authenticating the user’s credentials with a PPP authentication method and configuring settings for IPv4 or IPv6 traffic.
10. The SSTP client begins sending IPv4 or IPv6 traffic over the PPP link.

Figure 2 shows the structure of IPv4 or IPv6 packets that are sent over an SSTP-based VPN connection.

Figure 2** Structure of SSTP packets **

An IPv4 or IPv6 packet is first encapsulated with a PPP header and an SSTP header. The combination of the IPv4 or IPv6 packet, the PPP header, and the SSTP header is encrypted by the SSL session. A TCP header and an IPv4 header (for SSTP connections across the IPv4 Internet) or an IPv6 header (for SSTP connections across the IPv6 Internet) are added to complete the packet.

For more information about SSTP, see the Routing and Remote Access Blog at blogs.technet.com/rrasblog.

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written eight books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.