Being a road warrior is always a bit of a crap shoot. You are pretty sure that the hotel you are going to will have an Internet connection. But will the Internet connection work? How many times have you had to troubleshoot your Internet connection in a hotel, only to find out that there is something wrong with the wireless connection or the router for your segment in the hotel.

But getting that Internet connection to work often is not the end of your troubles; your next worry is what kind of firewall does the hotel have in place? Does the hotel firewall support VPN connections? If so, what kind of VPN connections does it support? I have been to hotels that support only PPTP connections. Other hotels support only L2TP/IPSec connection, and some hotels that support both PPTP and L2TP/IPSec. Unfortunately, many hotels do not support either PPTP or L2TP/IPSec. As a network admin who might need to access many networks over a VPN connection when I am out of town, this is where the real pain starts.

The problem with hotel firewalls or routers is that they want to keep things easy. They are not blocking your VPN connections out of spite or because they want to ruin your trip. It is much easier from a management and security point of view to allow only HTTP and HTTPS (SSL) outbound, two easy protocols that are used by 99% of their users. This makes troubleshooting much easier for the network service providers who support the Internet connectivity for these hotels.

Of course, if you are someone who needs a VPN connection and you are staying at one of these hotels, life becomes an exercise in futility when your network, or one of your client’s networks needs servicing and the only way to provide that service is through a network level VPN connection. What to do? In the past, I have bent my policy on never allowing RDP connections to a network just in order to get the access I need to fix things – but this is always uncomfortable, because I am acutely aware of the risks of allowing RDP access from the Internet.

The good news is that we now have a solution, or at least we will have one when Windows Server 2008 is released next month (February 2008). That solution is the SSTP VPN protocol included with Windows Server 2008. SSTP is the Secure Socket Tunnel Protocol, which is essentially PPP over SSL. SSTP allows you to connect to your VPN server over TCP port 443, just like any other SSL connection, and it also works with non-authenticating Web proxies, so even if your hotel uses an ISA firewall for outbound access (you would be surprised by how many do), your SSTP connections will work fine through them.

In this article I am going to show you how to configure an SSTP VPN server and how to configure the ISA Firewall to allow inbound connections from SSTP VPN client to the SSTP VPN server. The ISA Firewall will be configured with two Publishing Rules: a Server Publishing Rule that allows inbound connections to the SSTP server and a Web Publishing Rule that allows inbound connections to the CRL distribution site.

First, let us take a look at our example network for this configuration:

Figure 1

There are two data paths we need to take into consideration here. First, there is the SSTP connection that must be made through the ISA Firewall that terminates at the SSTP SSL VPN server. The second connection needs to make two hops through our network – the first hop is an HTTP connection made through the ISA Firewall, and the second hop is through the SSL VPN gateway to the CDP. In order to support this, we will need to configure the SSL VPN gateway to be a NAT server that will perform reverse NAT in order to allow access to the CDP located behind the VPN server.

The SSTP VPN client must be running Vista SP1. The RTM version of the Vista client does not support SSTP.

The ISA Firewall is not a domain member in this example. The reason for this is that domain membership is not a requirement in this scenario. If you wanted to make the ISA Firewall a domain member, you would have to configure the ISA Firewall to use a router behind the ISA Firewall’s internal interface, since intradomain communications do not work with NAT devices in the path. The router would be put in parallel with the VPN server, so that its internal and external interfaces are on network IDs that mirror those on the SSTP VPN gateway computer.

The SSTP VPN gateway is a domain member. This is so we can take advantage of Windows authentication. I did this for simplicity, since I did not want to get into the details of setting up a Network Policy Server in this article. If you do not want your SSTP VPN gateway to be a domain member, you can install a Network Policy Server on the corporate network and configure the VPN Server to use that for authentication and accounting (NPS servers are the Windows 2008 replacements for the Windows Server 2003 IAS server).

The CRL Distribution Point computer on the internal network is a domain controller for the msfirewall.org domain. Server Roles installed on this machine include Active Directory Certificate Services, DHCP Server, DNS Server, Active Directory Domain Services, and the WINS server feature.

We will need to perform the following procedures to get the solution working:

Install IIS on the VPN server.

Request a machine certificate for the VPN server using the IIS Certificate Request Wizard.

Install the RRAS server role on the VPN server.

Enable the RRAS Server and configure it to be a VPN and NAT server.

Configure the NAT server to publish the CRL.

Configure the User Account to allow dial-up connections.

Configure IIS on the Certificate Server to allow HTTP connections for the CRL directory.

Configure the Client to use SSTP and Connect to the VPN Server using SSTP.

Install IIS on the VPN Server

This might sound like a strange way to get things started, as I normally suggest that you never put a Web server on a network security device. The good news is that we do not need to keep the Web server on the VPN server, we just need to use it for a little while. The reason for this is that the Web enrollment site included with the Windows Server 2008 Certificate Server is no longer useful for requesting computer certificates, at least not in a Windows Server 2008 and Windows Vista environment. In fact, it is no use at all. What is interesting about this is that you can still try to get a computer certificate using the Web enrollment site, and it will look like it was installed, but in fact the certificate is not installed.

To solve this problem, we will take advantage of the fact that we are using an enterprise CA. When using an Enterprise CA, you can make a request to an online certificate server. The online request for a computer certificate is allowed when you use the IIS Certificate Request Wizard and request what they now call a “Domain Certificate”. This only works when the machine requesting the certificate belongs to the same domain as the Enterprise CA.

Perform the following steps on the VPN server to install the IIS Web server role:

Read the information on the Web Server (IIS) page if you like. This is good general information about using IIS 7 as a Web server, but since we are not going to use the IIS Web server on the VPN server, this information does not really apply to our scenario. Click Next.

On the Select Role Services page, a number of options are already selected. However, if you use the default options, it does not seem that you will get the option of using the Certificate Request Wizard. This was the case when I tested it. There is no Role Service for the Certificate Request Wizard, so I tried putting a checkmark in each of the Security options and that seemed to work. Do the same on yours and click Next.

Figure 4

Review the information on the Confirm Installation Selections page and click Install.

Click Close on the Installation Results page.

Figure 5

Request a Machine Certificate for the VPN Server using the IIS Certificate Request Wizard

The next step is to request a machine certificate for the VPN server. The VPN server needs a machine certificate to create the SSL VPN connection with the SSL VPN client computer. The common name on the certificate must match the name that the VPN client will use to connect to the SSL VPN gateway computer. This means that you will need to create a public DNS entry for the name on the certificate so that resolves to the external IP address on the VPN server, or the IP address of a NAT device in front of the VPN server that will forward the connection to the SSL VPN server.

Perform the following steps to request and install the computer certificate on the SSL VPN server:

In the Server Manager, expand the Roles node in the left pane and then expand the Web Server (IIS) node. Click on Internet Information Services (IIS) Manager.

Figure 6

In the Internet Information Services (IIS) Manager console that appears in the panes to the right of the left pane, click on the name of the server. In this example, the name of the server is W2008RC0-VPNGW. Click on the Server Certificates icon in the right pane of the IIS console.

Figure 7

In the right pane of the console, click the Create Domain Certificate link.

Figure 8

Fill out the information on the Distinguished Name Properties page. The most important entry on this page is the Common Name entry. This name is the name that VPN clients will use to connect to the VPN server. You will need a public DNS entry for this name so that is resolves either to the external interface of the VPN server, or the public address of a NAT device in front of the VPN server. In this example we’ll use the common name sstp.msfirewall.org. Later, we’ll create HOSTS file entries on the VPN client computer so that it can resolve this name. Click Next.

Figure 9

On the Online Certification Authority page, click the Select button. In the Select Certification Authority dialog box, click the name of the Enterprise CA and click OK. Enter a friendly name for the certificate in the Friendly name text box. In this example we’ll use the name SSTP Cert so that we know it’s being used for the SSTP VPN gateway.

Figure 10

Click Finish on the Online Certification Authority page.

Figure 11

The wizard will run and then disappear. After this point you’ll see the certificate appear in the IIS console. Double click on the certificate and you can see the common name in the Issued to section and that we have a private key that corresponds to the certificate. Click OK to close the Certificate dialog box.

Figure 12

Now that we have a certificate, we can install the RRAS Server Role. Note that it’s critical that you install the certificate first, before you install the RRAS Server Role. If you don’t, you’ll end up being in a world of hurt, because you’ll have to use a fairly complex command line routine to bind the certificate to the SSL VPN listener.

Install the RRAS Server Role on the VPN Server

To install the RRAS Server Role, perform the following steps:

In the Server Manager, click the Roles node in the left pane of the console.

In the Roles Summary section, click the Add Roles link.

Click Next on the Before You Begin page.

On the Select Server Roles page, put a checkmark in the Network Policy and Access Services checkbox. Click Next.

Figure 13

Read the information on the Network Policy and Access Services page. Most of it is about the new Network Policy Server (which used to be called the Internet Authentication Server [IAS] which was a RADIUS server) and NAP, neither of which apply to our current scenario. Click Next.

On the Select Role Services page, put a checkmark in the Routing and Remote Access Services checkbox. This will put checkmarks in the Remote Access Service and Routing checkboxes. Click Next.

Figure 14

Click Install on the Confirm Installation Selections page.

Click Close on the Installation Results page.

Enable the RRAS Server and Configure it to be a VPN and NAT Server

Now that the RRAS server role is installed, we need to enable the RRAS service, just like how we did it in previous versions of Windows. We need to enable the VPN server feature and the NAT service. While it’s clear why we need to enable the VPN server component, you might wonder why we need to enable the NAT server. The reason for enabling the NAT server is so that external clients can gain access to the Certificate Server to connect to the CRL. If the SSTP VPN client can’t download the CRL, the SSTP VPN connection will fail.

In order to allow access to the CRL, we’ll configure the VPN server as a NAT server and publish the CRL using reverse NAT. The SSL VPN client will first connect to the ISA Firewall. The ISA Firewall will be configured with a Web Publishing Rule that allows connections to the URL required to access the CRL. This Web Publishing Rule is also configured to forward the request to the external interface of the NAT Server. The NAT server on the VPN server will be configured to forward the HTTP request to the certificate server that contains the CRL.

Perform the following steps to enable the RRAS service:

In the Server Manager, expand the Roles node in the left pane of the console. Expand the Network Policy and Access Services node and click on the Routing and Remote Access node. Right click on the Routing and Remote Access node and click Configure and Enable Routing and Remote Access.

Figure 15

Click Next on the Welcome to the Routing and Remote Access Server Setup Wizard page.

On the VPN Connection page, select the NIC in the Network interfaces section that represents the external interface of the VPN server. Then click Next.

On the IP Address Assignment page, select the Automatically option. We can select this option because we have a DHCP server installed on the domain controller behind the VPN server. If you didn’t have a DHCP server, then you would have to select the From a specified range of addresses option and then provide a list of addresses that VPN clients could use when connecting to the network through the VPN gateway. Click Next.

Figure 17

On the Managing Multiple Remote Access Servers page, select the No, use Routing and Remote Access to authenticate connection requests. This is the option we use when there is no NPS or RADIUS server available. Since the VPN server is a member of the domain, you can authenticate users using domain accounts. If the VPN server were not a member of the domain, then only local accounts on the VPN server could be used, unless you decide to use the NPS server. I’ll do an article on how to use an NPS server in the future. Click Next.

Figure 18

Read the summary information on the Completing the Routing and Remote Access Server Setup Wizard page and click Finish.

Click OK in the Routing and Remote Access dialog box informing you that relaying of DHCP messages requires a DHCP relay agent.

In the left pane of the console, expand the Routing and Remote Access node and then click on the Ports node. In the middle pane you’ll see that WAN Miniport connections for SSTP are now available.

Figure 19

Configure the NAT Server to Publish the CRL

As I mentioned earlier, the SSL VPN client needs to be able to download the CRL to confirm that the server certificate on the VPN server hasn’t been revoked. In order to do this, you need to configure a device in front of the certificate server to forward HTTP requests for the CRL location to the Certificate Server.

How do you know what URL the SSL VPN client needs to connect to in order to download the CRL? That information is contained within certificate itself. If you go to the VPN server again and double click on the certificate in the IIS console, as you did earlier, you’ll be able to find this information.

Click the Details tab of the certificate and scroll down to the CRL Distribution Points entry and click on that entry. In the lower pane you’ll see the various distribution points based on the protocol used to access those points. In the certificate seen in the figure below, you can see that we need to allow the SSL VPN client access to the CRL via the URL:

Because of this, you need to create a public DNS entry for this name so that external VPN clients can resolve this name to an IP address on the external interface of the ISA Firewall. In this example, we need to have win2008rc0-dc.msfirewall.org resolve to the IP address on the external interface of the ISA Firewall. When the connection reaches the external interface of the ISA Firewall, it will forward the connection to the NAT server on the VPN server, which will then perform reverse NAT and send the connection to the CA that’s hosting the CDP.

I should note here that using the default CRL site name might not be the more secure option, since it exposes a private computer name to the Internet. You can create a custom CDP (CRL Distribution Point) to prevent this if you consider exposing the private name of your CA in your public DNS a security issue. You can find some information on how to change these values at How to Change the Policy Settings for a Certification Authority (CA) in Windows 2000

Perform the following steps to configure RRAS NAT to forward HTTP requests to Certificate Server:

In the left pane of the Server Manager, expand the Routing and Remote Access node and then expand the IPv4 node. Click on the NAT node.

In the NAT node, right click on the external interface in the middle pane of the console. In this example, the name of the external interface is Local Area Connection. Click Properties.

Figure 21

In the Local Area Connection Properties dialog box, click on the Web Server (HTTP) checkbox. That brings up the Edit Service dialog box. In the Private Address text box, enter the IP address of the Certificate Server on the internal network. Click OK.

Figure 22

Click OK in the Local Area Connection Properties dialog box.

Figure 23

Now that the NAT server is installed and configured, we can move our attention to configuring the CA server, the ISA Firewall and the SSTP VPN client.

Summary

In this article we began with a discussion on the challenges of VPN remote access from hotel locations and how the SSTP protocol helps to solve these problems by allowing VPN connections to take place over an SSL connection through TCP port 443, which is allowed through all firewalls in these environments. Then we installed certificate services on the VPN server so that we could obtain a computer certificate. After installing the certificate on the SSL VPN server, we installed the RRAS VPN and NAT services on the VPN gateway. We finished up by configuring the NAT server on the VPN gateway to forward incoming HTTP connections forwarded by the ISA Firewall to terminate on the CA hosting the CDP. Next week we will finish up the configuration by configuring the CA server, the ISA Firewall and the SSTP VPN client.

If you would like to read the following parts in this article series please go to: