The Cable Guy
The 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.
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
| Attributes |
PPTP |
L2TP/IPsec |
SSTP |
| Encapsulation |
GRE |
L2TP over UDP |
SSTP over TCP |
| Encryption |
Microsoft Point-to-Point Encryption (MPPE) with RC4 |
IPsec ESP with Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) |
SSL with RC4 or AES |
| Tunnel maintenance protocol |
PPTP |
L2TP |
SSTP |
| When user authentication occurs |
Before encryption begins |
After the IPsec session is established |
After the SSL session is established |
| Certificates required to establish the VPN tunnel |
None |
Computer certificates on both the VPN client and VPN server |
Computer certificate on the VPN server and root CA certificate on the VPN client |
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:
- 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.
- The SSTP client sends an SSL Client-Hello message, indicating that the client wants to create an SSL session with the SSTP server.
- The SSTP server sends its computer certificate to the SSTP client.
- 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.
- The SSTP client sends the encrypted form of the SSL session key to the SSTP server.
- 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.
- The SSTP client sends an HTTP over SSL request message to the SSTP server.
- The SSTP client negotiates an SSTP tunnel with the SSTP server.
- 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.
- 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.
.gif)
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.