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
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
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
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
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!
Right-click on the ISA Server console Protocol Rules node and select
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
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.
To test any VPN gateway solution,
you must have the ability to
establish at least three networks
in the lab. Figure 2 shows our
design. Routers A and B provide
routing across the fake Internet
networks C, D and E. Computers
in Network A simulate the corporate
headquarters sitting behind
ISA Server A, and computers
in Network B simulate the branch
office sitting behind ISA Server
B. ISA Servers are dual-homed
and, thus, have one interface
on external networks C or E
and one interface on internal
networks A or B. Web servers
A and B are configured with
a default.htm page that identifies
them when viewed. Web servers
are used simply to demonstrate
connectivity across networks
through a VPN tunnel. They aren’t
supposed to be accessible from
a system placed on our simulated
Internet. Routers A and B are
Win2K standalone servers. Each
has two network cards and is
configured with static routes
so traffic can be routed back
and forth between networks C
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.
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
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
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.
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
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
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
2. If the RRAS start-up notice appears, click
3. Browse to the location of the .vpc file and
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
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
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.