Skip navigation

Configuring SSL VPNs for Secure Public-Terminal Connections

A new protocol and native Windows support for SSL VPNs enable secure public connections through network firewalls

Secure Sockets Layer (SSL) VPNs provide secure remote network connections through the public Internet using HTTP Secure (HTTPS) and Microsoft’s new VPN protocol, Secure Socket Tunneling Protocol (SSTP). SSL VPNs also create secure communication tunnels without the need to install additional client software. Learn the advantages of SSL VPNs over traditional PPTP and L2TP/IPsec VPNs, how SSTP works, and how to configure an SSL VPN.

Secure Sockets Layer (SSL) VPNs offer secure remote network connections from public Internet Access Points (APs). SSL VPNs create secure connections regardless of what client the user has or what proxy servers, firewalls, or Network Address Translation (NAT) devices stand between the user and the VPN server. Windows Vista SP1 and Windows Server 2008 are the first Microsoft OSs to natively support SSL VPNs. Microsoft incorporated its new VPN protocol, Secure Socket Tunneling Protocol (SSTP), into Vista SP1 and Server 2008 to enable secure network connections through HTTP Secure (HTTPS) without requiring you to install additional client software. Unlike traditional PPTP and L2TP/IPsec VPNs, which aren’t reliable over public networks, SSTP can establish virtual network connections through public networks because of HTTPS's widespread usage. If you’re running Vista SP1 and Server 2008 and want to take advantage of the new, more secure SSL VPNs, you’ll need to perform a series of configuration steps to enable your remote users to connect via SSL VPN. Here I’ll take you step-by-step through an SSL VPN installation and configuration, but first let’s briefly review the shortcomings of traditional PPTP and L2TP/IPsec VPNs and take a quick look at SSTP.

Traditional VPN Technology Weaknesses
The ports and protocols required by PPTP and L2TP/IPSec VPNs are often blocked or not supported on public Internet APs. PPTP's main technical disadvantage is that it requires TCP port 1723 to be open outbound and the firewall and ISP to permit the use of Cisco Systems’ Generic Routing Encapsulation (GRE) protocol. PPTP won’t work with NAT routers unless the appropriate port mappings are configured.

L2TP/IPsec VPNs require the client UDP port 500 to be open outbound (which most public APs don’t allow) and can be problematic over NAT connections, although Windows XP and Windows 2000 have been updated to support NAT traversal (NAT-T). Additionally, IPsec VPNs were designed to link two geographically separated but established sites, not provide remote users with ad hoc connections. L2TP/IPsec supports only IP traffic, and both PPTP and L2TP/IPsec VPNs require client software.

These limitations of PPTP and L2TP/IPsec often result in connection failures, especially from public Internet APs. Successful VPN connections traditionally have depended on how the client machine connects to the Internet. A user might successfully connect every time at home or in an established remote office if his or her network is appropriately configured. But on the road, successful connections can be hit or miss due to the lack of support for traditional VPN protocols from public Internet APs. Because workspaces are becoming increasingly mobile, Microsoft developed SSTP to offer secure VPN connections from public wireless networks.

A Closer Look at SSTP
One of SSL VPNs’ main advantages is that TCP port 443 is generally open outbound for HTTPS at Wi-Fi hotspots and other public Internet APs. Because HTTPS is almost always available, SSTP is more flexible than other Windows-supported tunneling protocols. Microsoft's SSTP uses an existing RRAS client, which is included in Vista SP1 and Server 2008, but that’s the only client software you need to establish an SSL VPN. Third-party SSL VPN vendors tout the ability to establish VPN connections using implementations that don’t require additional remote client software, but some applications can’t route traffic through the VPN to remote servers.

Microsoft’s SSTP implementation also fully supports IPv6, non-IP protocols, strong authentication, and Network Access Protection (NAP) integration. SSTP uses Advanced Encryption Standard (AES) or RC4 encryption, and like L2TP/IPsec, transmits user credentials only after establishing a secure tunnel. Unlike L2TP, however, SSTP doesn’t support mutual computer authentication. The SSL client authenticates the remote VPN server, but not vice versa. A secure tunnel can’t be established using SSTP unless Vista SP1 trusts the Certification Authority (CA) that issued the server’s computer certificate. Typically, the server’s certificate is provided by an internal public key infrastructure (PKI), so the trust chain can be limited to selected company-owned devices.

For user authentication, which occurs after a secure tunnel is created, SSTP supports Point-to-Point Protocol (PPP) authentication methods such as Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). EAP-TLS requires a client-side certificate to verify the user's identity and a server-side certificate to verify the server’s identity, thus providing mutual user authentication. Although EAP-TLS isn’t configured by default, you can create an appropriate network policy to enable it.

The principal disadvantage of SSTP stems from the fact that Vista SP1 and Server 2008 are the only OSs that natively include an SSTP VPN client—so only clients running Vista SP1 or Server 2008 can connect to a remote server running Microsoft's SSL VPN implementation. If you want to create and manage an SSL VPN on a machine running another OS, you'll need third-party software to do so. SSTP doesn’t support site-to-site VPN links or proxy servers that require authentication.

Configuring an SSL VPN
Now let's fire up the servers and set up a remote network connection. The example I use to demonstrate the SSTP VPN setup assumes the following infrastructure:

  • a Server 2008 Active Directory (AD) domain (called ad.com in the example)
  • a standalone CA with Microsoft IIS enrollment installed
  • a member server (called serv1 in the example) with two network interfaces
  • an RRAS client running Vista SP1
The demonstration also assumes that the client isn’t joined to a domain and that the example server's NIC has an Internet-facing IP address. You can simulate an Internet-facing IP address in a lab by using a network with a private address range that’s physically isolated from your Intranet.

A standard Network Policy Server (NPS, formerly Routing and Remote Access—hardware configuration includes two network interfaces. NPS then routes traffic between the two interfaces based on the server’s configuration. First you configure the two network interfaces, then you enter the IP addresses, and then you issue and install the NPS server’s computer certificate. After you complete those procedures, you can configure the VPN connection.

To configure the two network interfaces on the server, open the Start menu and the Control Panel, then click Network Sharing Center. Under Tasks, click the Manage network connections link. If your NICs are correctly installed, you should see both interfaces in the Network Connections window. Right-click the first connection and select Rename from the menu. Name the first NIC Private. Go back to the Network Connections window and follow the same procedure to rename the second connection Public.

Next you’ll enter the intranet and Internet IP addresses and configure the Internet-facing network connection. While still in the Network Connections window, right-click Private and select Properties. Then select Internet Protocol Version 4 and click Properties. Enter an intranet IP address, subnet mask, and DNS server ID. Next click OK twice and follow the same procedure for the Public NIC, but enter an Internet-facing IP address and subnet mask. To configure the Internet-facing connection, navigate back to the Network Connections window, right-click Public, then select Properties. Under This connection uses the following items, clear the File and Printer Sharing for Microsoft Networks check box. Click OK, then right-click the Public connection and select Disable. To complete the process, join serv1 to your AD domain. Now let's issue the NPS computer certificate.

Issue and Install an NPS Computer Certificate
SSTP must verify the NPS server’s identity through the server's computer certificate before establishing a tunnel. To make sure the certificate in our example is correctly installed, let’s first change the Microsoft Internet Explorer (IE) Intranet Zone security level to low. Certificate publishing properly works only when all active content is allowed to run without restrictions. To change the security level, open the Control Panel, select Internet Options, then select the Security tab. Next click the Local intranet icon and move the slider at the bottom of the window to the lowest position. Finish by clicking OK.

To create the NPS computer certificate, you must request the certificate, identify the server that needs a certificate, then approve the request. To request a certificate, open IE on the NPS server, then enter your network CA’s address. It should look something like http://servername/certsrv. Click Request a certificate, then select advanced certificate request. Click Create and submit a request to this CA, then click Yes on the ActiveX control warning. Under Identifying Information, enter the NPS server’s public DNS name. In this case, the NPS server’s public DNS name is serv1.ad.com.

It’s worth mentioning here that the certificate name must match the VPN server’s public DNS name, which is also the DNS name that should be entered on the client when creating this SSL VPN connection. If the computer certificate doesn’t match the Fully Qualified Domain Name (FQDN), the remote clients won’t be able to connect to the VPN.

To continue creating the certificate, select Server Authentication Certificate from the Type of Certificate Needed menu. Next click the Mark keys as exportable check box under Key Options, as Figure 1 shows. Then scroll down and click Submit. When the Web Access Confirmation screen appears, click Yes.

Because you’re dealing with a standalone CA, you must manually approve the request on the CA-installed server. To manually approve the request, you must open the Microsoft Management Console (MMC) Certification Authority snap-in. Click the Start menu, expand Administrative Tools, then select Certification Authority. Next select Pending Requests, right-click the request in the right pane, select All Tasks, then select Issue. After you’ve performed these actions, you should see the certificate in the Issued Certificates folder, as Figure 2 shows. After you’ve confirmed that the certificate was moved into the Issued Certificates folder, close the Certification Authority snap-in.

To install the certificate, go back to the NPS server, open IE again, and re-enter the CA’s address. Next click the View the status of a pending certificate request link, and you should see the Server Authentication Certificate listed, along with its issue date. Then click Server Authentication Certificate, and click Yes on the ActiveX control warning. Click Install this certificate, then click Yes in the Web Access Confirmation dialog box. IE should report that the certificate was successfully installed.

Moving the Certificate
Congratulations, you’re halfway through the VPN setup process! Now you need to move the certificate from the user’s personal store to the computer’s personal store. To move the certificate, first open MMC (to find and run MMC on your system, click the Start Menu, then click Search, type “mmc” in the Search box, and press Enter). Once MMC opens, press Ctrl+M to open Add or Remove Snap-ins, and in the Available snap-ins list, double-click Certificates. Leave My user account selected, and click Finish. Double-click Certificates again, but this time select Computer account, click Next, and while leaving Local computer selected, click Finish. Next, click OK in the Add or Remove Snap-ins dialog box.

Then reopen MMC, find Available snap ins, and expand Certificates. Select Current User, Personal, Certificates, and right-click the center certificate. Next, select All Tasks, then Export. Click Next to get past the welcome screen, and check Yes, export the private key. Click Next twice to accept the default file format. To enter the password, type and confirm a password, then click Next. Save the file to Desktop and call it cert. Click Next, then click Finish to exit. You should see a dialog box confirming the successful export. Now let’s import the certificate into the computer’s store.

To import the certificate, navigate back to Certificates and select Personal. Then select Certificates and delete the default all-purpose certificate that appears in the central pane. Right-click the Certificates folder in the left pane and select All Tasks, then select Import. Click Next at the welcome screen, then click Browse. At the bottom of the Open dialog box and to the right of File name, select Personal Information Exchange from the menu. Then select the cert file in the central pane and click Open. Go back to the Certificate Import Wizard, click Next, and at the next screen type the password. Then click Next twice to accept the default store and click Finish. Click OK in the confirmation screen. You should see the new certificate installed in the MMC Certificates snap-in, which Figure 3 shows. Don’t forget to return IE’s Intranet Zone security back to Medium-low. Now let’s begin the RRAS installation.

Install RRAS
A note of caution before beginning the installation process: The SSL certificate must be in place before RRAS is enabled; otherwise, you can’t use SSL. To start installing RRAS, re-enable the Public network interface. Then open the Start menu, select Server Manager, then select Roles in the left pane. Under Roles Summary, click Add Roles, then click Next on the Before you begin screen. Continue by clicking Network Policy and Access Services, then Next. Keep going by clicking Routing and Remote Access Services, ensuring that the two suboptions, Routing and Remote Access Service, are also checked. Click Next, then click Install. Close the dialog box after confirming a successful installation. Now let’s configure RRAS as a VPN server.

Open the Start menu, then Administrative Tools, then the Routing and Remote Access option. Right-click serv1 and select Configure and Enable Routing and Remote Access. Click Next twice at the welcome screen and, while leaving the default option of Remote Access selected, select the VPN check box, then Next. On the VPN Connection screen, select the Public interface, as Figure 4 shows. To simplify the configuration for the purposes of this article, let’s clear the Enable security on the selected interface by setting up static packet filters check box, then click Next. The next step is entering the intranet addresses.

Because my example doesn’t include a DHCP server, select the From a range of specified addresses option, and click Next. Then click New under Address Range Assignment, enter a small range of unused intranet addresses, and click OK. Click Next twice to get past the Managing Multiple Remote Access Servers dialog box and enable Windows Authentication as the default authentication method. Then click Finish. You’ll receive a warning about the DHCP Relay Agent, which you can ignore. Next I’ll configure a user’s remote network access permissions.

To configure remote access permissions, open the Start menu, select Administrative Tools, then Active Directory Users and Computers. Select a user to receive network access permissions. Double-click the user object, select the Dial-in tab, check Allow access under Network Access Permission, and click OK. When possible, it’s better to use network policies rather than configuring this setting for individual users. Make sure that the user has access to an NPS server file share so that you can test the VPN. Now let’s get to the fun part and configure the client for a VPN connection.

Configuring Vista’s SSL VPN Connection
Before creating the VPN connection on the client, you need to install the root CA’s certificate so that the VPN server identity can be verified. It’s much easier to install the root CA's certificate than installing the computer certificate on the NPS server. You can even use Group Policy to automate the procedure.

On the Vista SP1 client, open IE and type the CA’s address (//http//servername.certstrv). Then click Download a CA certificate, certificate chain, or CRL, and close the Information Bar warning. Next, click Download CA certificate chain at the bottom of the page and save it to the Desktop.

Then open the Start menu. In the Search box, type MMC and press Ctrl+Shift+Enter to elevate your privileges. Once the MMC window opens, press Ctrl+M to open the Available Snap-ins dialog box and double-click Certificates. Then click Computer account, Next, then Finish. Next click OK in the Add or Remove Snap-ins dialog box and expand Certificates. Then expand Local Computer, expand Third-Party Root Certificate Authorities, right-click Certificates, select All Tasks, then select Import from the menu. Click Next to get past the welcome screen, and open the Download CA certificate chain file saved on the desktop. Click Next twice, then Finish. Close the Certificates snap-in.

To set up the remote network connection, open the Start menu, select Connect to, and at the bottom of the screen click Set up a connection or network. Next select Connect to a workplace under the Choose a connection option section, click Next, then select Use my Internet Connection (VPN). If Vista SP1 complains that there is no Internet connection, select I’ll set up an Internet connection later. Then, in the Internet Address dialog box, enter the NPS server’s public DNS name. Next, in the Destination name dialog box, give the connection a friendly name, such as VPN Connection, as Figure 5 shows. Click Next and enter the username, password, and user’s domain for the user for whom you granted AD network access permissions earlier. To finish, click Create, then click Close. Congratulations, you've configured an SSL VPN!

Testing the VPN
To test your SSL VPN, try to make a secure and remote network connection and access a network resource. To start, make sure your Vista client has a working Internet connection. Then open the Start menu and select Connect to. Next, right-click the VPN connection you’ve created under Select a network to connect to and choose Properties from the menu. From the Type of VPN menu, click the Networking tab and select Secure Socket Tunneling Protocol (SSTP), as Figure 6 shows, then click OK. Navigate back to the Connect to a network dialog box, select the VPN connection, and click Connect. A new window will appear that should already contain the VPN user’s logon credentials. Click Connect, and you should see a successful connection confirmation. Try connecting to a file share on serv1 to confirm that the resources are accessible to the remote client.

Security and Convenience
Although many organizations have found VPN alternatives, such as Microsoft Outlook Web Access and web-based document management systems such as SharePoint, SSL VPNs provide a convenient and secure way to grant network access without relying on a web interface. Microsoft’s SSL VPN implementation is client based and avoids some of the problems associated with third-party SSL VPN “client-free” products. The management and NAP and NPS integration advantages are also administrator bonuses. If you have an L2TP/IPsec VPN infrastructure in place, you might not need SSL VPNs. But if you’re still working with PPTP, SSL is a more secure and convenient option.

TAGS: Security
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish