Security Advisor

Digging a Tunnel

As a company grows, so does its need for fast, secure connectivity. Enter ISA Server, a caching firewall that also serves as a nifty VPN endpoint.

• By Roberta Bragg
• 07/01/2001

Despite the general depression swamping the dot-com world and haunting more traditional businesses, my client with the little hardware-based VPN was expanding faster than gas bubbles in the belly of a Giants fan on Super Bowl Sunday. In addition to opening new locations, my client’s home and original branch offices were complaining about slow Internet access and difficulties using the VPN tunnel. Employees on the road were often unable to connect, and management wanted to know what all the fuss was about. By the time they thought of asking my opinion, it was clear that we had to either upgrade the level of hardware or seek a slightly different solution.

ISA Server to the Rescue
You know, sometimes I feel there really is justice in the universe. For several months I’d been researching, testing and stressing a new Microsoft firewall, Internet Security and Acceleration Server. This product, in addition to providing superb Internet caching capabilities, is a full-fledged, ICSA-certified firewall (www.icsalabs.com). On top of that, ISA Server provides a gateway-to-gateway VPN tunnel solution. By installing an ISA Server at each of my customer’s locations, I was able to provide the capabilities they needed for a manageable VPN solution, expand their firewall capabilities, enable caching to reduce demands on bandwidth, and broaden their horizons for possibilities in protecting their soon-to-be-internally hosted Web site. Of course, I could have simply upgraded their hardware-based solution with more powerful boxes, but some features available by default with ISA Server wouldn’t have been present.

While full implementation details for all ISA Server features are beyond the scope of this column, I’ll detail the VPN gateway-to-gateway installation process. Before choosing and deploying ISA Server VPN tunnels on your network, you may want to study the product and do a test implementation in a lab. Last month I discussed the setup for such a lab; I’ll use that model here. (See “Lab Set Up” for a recap.)

A Prickly Pear in Cuddly Clothing
When I think of a firewall/VPN solution, two types of products come to mind: the hardware-based appliance, which may or may not be a pain to implement but is usually straight-forward in design, and the have-to-go-to-school-for-a-month-of-Sundays-to-figure-out-how-it-works software-based solution.

Enter ISA Server. While its interface isn’t immediately intuitive, it’s not difficult to understand. Wizards help you configure most items, and a good online help system goes a long way toward educating the savvy administrator. Bringing up a VPN tunnel is fairly painless; in fact, wizards do all the hard stuff for you.

ISA Server Preparation
Before configuring a gateway-to-gateway VPN tunnel, we prepared two ISA Servers. ISA Server requires Win2K Server, Service Pack 1 or above. An additional hotfix rollup is recommended for SP1 systems and is provided on the ISA Server CD-ROM. Two network cards are installed, one to provide access and connectivity with the Internet router, the other to provide internal network access.

An ISA Server computer can be configured to serve as a dedicated caching server, a dedicated firewall used only as the VPN gateway, or some combination of all its features. You’ll want to consider the requirements of your situation and the load you expect ISA Server to bear carefully.

Two versions of the product exist: Standard edition and the more advanced Enterprise edition. Enterprise edition can be integrated with Active Directory and provide additional centralized management capabilities, fault tolerance and network load balancing. For the test, we’ll work with the Standard edition installed in integrated mode, so it can be used both as a firewall and a caching server. We could have used different ISA servers to play these separate roles; however, in a small network, additional computers aren’t always available. Likewise, we could have used the Enterprise edition and integrated our ISA Servers with AD and displayed a complex tiered architecture for policy configuration. My customer didn’t require such a setup. You must decide which mode and version of ISA Server is the proper solution for your implementation.

ISA Server Installation
Installation is straightforward, with only a few questions to answer. You’ll choose installation mode, which will determine whether you’re required to configure the cache (caching mode), LAT (firewall mode) or both (integrated mode). Mode choices are the following:

• Caching mode—In this mode, ISA Server provides caching for HTTP objects requested by internal clients. Additional requests can be served from the cache, which translates to improved access time and reduced bandwidth requirements. You’ll need to provide space on an NTFS partition on the ISA Server computer and tell ISA Server where to place its cache during installation. Changes can be made afterward to add or reduce the amount of disk space dedicated to the cache.
• Firewall mode—Firewall-mode ISA Server provides additional protection for the internal network. Default application filters, configurable packet filters and access rules can be written to control access between the internal and external networks. Some intrusion-detection capabilities (licensed from Internet Security Systems, www.iss.net) are provided. You’ll be asked to configure the LAT (local address table) during installation. The LAT assists ISA Server by identifying which requested IP addresses lie on the internal or private network. It assumes that all others are on the Internet or public network. You can adjust the LAT after installation.
• Integrated mode—In this mode, both LAT and cache will be configured during installation.

After installation you must take steps to provide access. By default, ISA Server allows no access in either direction. This, of course, is an excellent security measure. If installing the firewall provides no access, then I’m able to configure just the access I choose—in both directions—and not have to worry about closing down default communication through the juncture.

Testing Firewall Operation
I believe in testing one step at a time. If problems occur, it’s easier to troubleshoot. First, I placed only ISA Server A online. In our scenario, access to the simulated Internet was configured for access to external Web sites. Web server B was temporarily placed on Network C (and its IP address changed). Figure 1 illustrates this configuration.

Figure 1. Placing ISA Server A online and temporarily placing Web server B on Network C establishes that the firewall is correctly configured to allow access to Internet Web sites, yet access isn’t allowed from the Internet.

To configure Web proxy clients, we could have pointed Internet Explorer to port 8080 on ISA Server (ISA Server listens on this port for HTTP requests) or installed the firewall client software. However, since not all clients run Microsoft operating systems (necessary for the firewall client) or even proxy-configurable Web browsers, we chose to simply include the ISA Server’s internal address as the gateway address for the client. No other configuration is necessary for basic Web access. This type of ISA Server client is called the SecureNAT client.

By placing only ISA Server A online in this manner, we established that, yes, the firewall was correctly configured to allow access to Internet Web sites, yet access wasn’t allowed from the Internet (incidentally, ISA Server translates the client’s address before it sends communication to the Internet so the internal addressing scheme isn’t exposed.)

An attempt to browse the Web server B from behind ISA Server A by using a workstation on the A network was unsuccessful, as it should have been. Likewise, access from Network C to the internal Web server A was unsuccessful. We could have sat there beating against ISA Server A’s external interface testing other protocols, but we accepted the ICSA lab report. (Note: You should periodically test your ISA Server external interface. Be sure to see the ISCA lab report for hints on how to make it even more bulletproof and to improve logging facilities. Keep up with Microsoft and other reports on any hotfixes or configuration adjustments necessary to keep ISA Server locked down in the face of the ever-more-sophisticated attacks that the future may bring.)

To allow Internet access from behind the firewall, both ISA Server protocol rules and site and content rules must be written. Protocol rules define which protocols may cross ISA Server. Site and content rules determine which sites and what content can be accessed, when this may occur and who may do so. A default site and content rule, the “Allow Rule” (it allows all clients to access all sites on the Internet at all times), is created during installation. (An Enterprise array policy may prohibit the creation of this rule, but in the Standard edition installation it’s always created.) Later, we could replace this rule with more specific rules to limit who can access what. Since no protocol rule existed, however, all access was denied. To allow access, we had to write a protocol rule. This was easy!

1. Right-click on the ISA Server console Protocol Rules node and select New.

2. Enter a name for the rule and click Next.

3. On the rule action page, select Allow.

4. On the protocols page select “Selected Protocols” and select HTTP.

5. Select the schedule and click Next.

6. Select the client type of all users. Client types could be restricted to Win2K user groups or pre-created “client address sets,” which consist of a range of IP addresses.

7. Click Finish.

After writing our rule, clients on Network A were able to reach the Web server on Network B. Next, we took ISA Server A offline, placed ISA Server B online and ran similar tests. That done, we placed both ISA Servers online so we could configure and test a VPN tunnel between them. With both ISA Servers online and their respective Web servers placed behind them, access to either Web server from the opposite network wasn’t possible.

VPN Wizards and a Surprise
So here we are, the real purpose of our lab. With both ISA Servers online, we needed to access the opposite network’s Web server across our simulated Internet. If Web server A and B were meant to be public Web servers and our only desire was to ensure access to these Web servers behind the firewall, then our approach would have been to simply publish these servers using ISA Server publishing rules. Remember, though, that these Web servers were merely serving as an easy way to test access to a network. In the first test, we confirmed access to Web servers on a public network and merely used these Web servers to demonstrate access to the internal network—not as public Web servers. We wanted to provide a safe way for employees at different locations to access the internal network of another company location. They may need to access company mail servers, file servers and intranet servers. In short, we wanted to link two disparate networks and make them as if they were one—the definition of a virtual private network.

Figure 2 shows this “virtual” path via the dotted line that extends between the two firewalls. The “real” path, of course, is denoted by the solid line from ISA Server A, through Router A, across the Internet, through Router B, to ISA Server B.

Figure 2. When setting up a lab to test a VPN gateway solution, you must have the ability to establish at least three networks.

Configuring an ISA Server VPN gateway is straightforward. Two wizards make the process easy. The Remote ISA VPN Wizard not only configures the VPN gateway at headquarters, but also records branch office configuration information in a file. This file is used at the branch by the Local ISA VPN Wizard. This is especially helpful if the branch office doesn’t have someone trained on ISA Server and Win2K VPNs. Instructions can be given over the phone to ensure that the configuration elements are correct.

Only one troublesome decision existed in our scenario: whether to use PPTP or L2TP over IPSec. Because the use of IPSec requires obtaining certificates for server authentication or the writing of a custom IPSec policy (Knowledge Base article Q252735, “How to Configure IPSec Tunneling in Windows 2000,” at http://support.microsoft.
com/directory/article.asp?id=
KB;EN-US;Q252735), we chose PPTP for our test.

Tunnel Configuration and Testing
Each wizard configures an endpoint. Since a gateway-to-gateway VPN requires two endpoints, you must run both wizards, one for ISA Server A and one for B. An individual could run the initial wizard on both sides of the proposed tunnel or configure the entire tunnel manually using Routing and Remote Access, Computer Management and ISA Server consoles. In either case, the configuration file wouldn’t be used. There are a lot of details to get right, and it’s easier (except for perhaps “real” nerds) to use the wizards. I went for the wizards.

Local ISA VPN Wizard
To start, I ran the Local ISA VPN wizard on ISA Server A. By default, it makes this ISA Server the connection receiver—only the remote ISA VPN server can initiate the call. This is a good solution where branch offices might periodically initiate a call to corporate and require a VPN connection. Filling out an additional page in the wizard allows the tunnel to support initiation by either end-point. Here’s the 12-step approach I used.

1. Right-click on the Network Configuration folder in the ISA Server console and select “Set Up Local ISA VPN Server.”

2. Click Next on the first wizard page.

3. When presented with the pop-up “Routing and Remote Access Service must be started,” click OK.

4. Enter a name for the local VPN connection—A Network.

5. Enter a name for the remote VPN connection—B Network—and click Next. The names are appended with an underscore. This becomes the name for the demand-dial connection object that is created in RRAS.

6. Select PPTP and click Next.

7. To enable both endpoints to initiate a connection, enter the Fully Qualified Domain Name (FQDN) or IP address of the remote computer then click Next.

8. Enter a range of address that will be accessible at the remote ISA Server internal network (Network B). This is the range of addresses on the remote network that you want users from this machine to access. A static route that includes this address range will be created automatically. Click Next.

9. Enter the range of addresses on Network A that you want accessible to the remote VPN endpoint. The wizard displays the entire LAT of ISA Server A. In practice, you’ll remove any address ranges you don’t want made available. When the remote VPN endpoint is configured, a static route is configured using the entries here. Click Next.

10. Select a location to store the .vcf file. This file contains configuration information necessary to configure the remote VPN endpoint using the Local ISA VPN Wizard on the ISA Server B.

11. Enter a password to be used to encrypt the configuration file. The administrator installing the remote VPN will need this password. Click Next.

12. View details of your configuration by clicking the Details button. Then click the back button and click Finish.

You can best understand how all this hocus-pocus will work by considering the changes made on ISA Server A. In Computer Management | Users and Groups | Users, a new user’s been added with the name of the interface created by the wizard. The new user has “Allow dial-up access.” The wizard assigns a strong password to this account and places the information in the configuration files. A demand-dial interface has been created in the Routing and Remote Access Service (RRAS) console with the interface name created by the wizard. A demand-dial interface holds the configuration information used for creating VPN connections. When access is attempted to a remote server within its specifications, the tunnel is used. Demand-dial can mean dial on demand, but it can also be used to configure persistent tunnels.

When we opened our ISA Server VPN wizard-created interface, it showed the address of the remote ISA Server. An inspection of the Advanced security settings (behind the Advanced button) mandated data encryption and specified MS-CHAP or MS-CHAPv2 for authentication. To tighten security here, I de-selected MS-CHAP and required MS-CHAPv2. Finally, in the ISA Server Management console, packet filters (pptp call and pptp receive) for PPTP had been created. Each packet filter was specific for this computer and the remote computer address. As you now can see, the primary functionality of the VPN was based on good, old Win2K RRAS. ISA Server primarily provided the configuration and implementation of packet filters, which allowed the traffic. Superb wizards helped get it all going.

To tweak the VPN, or to troubleshoot its functioning, you’ll have to understand and use RRAS. You’ll find a good article at http://www.microsoft.com/technet/ network/ddrout.asp. For information on Demand Dial routing in Win2K, see the Windows 2000 Resource Kit and Routing and Remote Access help files.

Remote VPN Connector
After transferring the .vcf file we created above to ISA Server B, I ran the Remote ISA VPN Wizard on ISA Server B. It took four steps.

1. Right-click on the Network configuration folder and select “Setup Remote ISA VPN Server” and click Next on the wizard start-up screen.

2. If the RRAS start-up notice appears, click OK.

3. Browse to the location of the .vpc file and click Next.

4. View the details to confirm that all additional information has been entered correctly, click back, then click Finish.

An inspection of ISA Server B reveals the counterparts to ISA Server A configuration created by the wizard.

Test the Connection
To test the connection, I right-clicked on the demand-dial object in RRAS and selected “connect.” Since the connection was successful, the “connecting” message box closed and a “connected” status was displayed. Next, I attempted to access Web server B from the internal Network A. This was successful, as was the access of Web server A from internal Network B.

To further test the tunnel, I placed a client system on the “Internet” network between routers A and B. It shouldn’t have been able to access either Web server—and it couldn’t. Since this system also had a Web server, I tested client connections to this “normal” Internet Web server from both network A and B to simulate client computers browsing the Internet.

Deployment
In the real world, multiple tunnels will be created, one for each branch office connecting to headquarters and an occasional one for branch-office-to-branch-office connectivity. It’s easy to move from a hardware-based approach to an ISA Server installation, as the former can continue to run until the latter is configured and tested—branch by branch. When the last branch is up and running on ISA Server, the headquarters’ hardware can be shut down.

As far as I can tell, there’s no hard-coded limit to the number of PPTP tunnels that ISA Server can support. As I mentioned, ISA Server PPTP tunnels are actually supported by Win2K RRAS. An independent testing agency, NSTL, testing Win2K in late 1999, was able to create and maintain 2,600 tunnels. It doesn’t say if tunnel 2,601 failed or if it just got tired of implementing tunnels. You can read more on the test, which includes comparative information between PPTP and L2TP/IPSec and also between Win2K L2TP/IPSec and other IPSec tunnels, at www.microsoft.com/technet/network/nstlvpn.asp.

Incidentally, if you prefer to establish L2TP over IPSec tunnels for your ISA Server VPN solution, you can do so using Win2K-provided or third-party server certificates, or you can write a custom IPSec policy. The actual VPN tunnel setup is just as simple, but using or not using a PKI for this purpose, in any network, isn’t a simple decision. There’s a range of issues to consider that are far beyond the scope of this article. If you choose Microsoft Certificate Services, you face additional infrastructure decisions and implementation. I recommend that you take the time to thoroughly investigate PKI and IPSec before implementing this approach.