Systems Engineering: Make the Internet Virtually Private
By implementing a VPN, you can use the world’s largest public network as a WAN that securely connects your remote users and branch offices.
- By Anil Desai
- December 01, 1999
Want to use the Internet to connect all of your users
together and throw away your modem banks? I’m not talking
about Web sites or email. This is about sending your WAN
traffic securely over the Internet. On the surface, using
a public network for transferring your secure data might
not sound like such a good idea. After all, security,
reliability, and performance aren’t often features used
to describe the Internet. But new protocols and technologies
have brought solutions that should ease your worries.
A little over a year ago, in my October 1998 article,
“Your Own Private Internet,” I wrote about the steps required
to set up a Windows NT-based Virtual Private Network (VPN).
In this article I focus on issues associated with evaluating
and implementing a VPN solution. I’ll start at the high
level—defining the business challenges you’re trying to
solve and how a VPN can help. The next step is to determine
which type of VPN implementation makes sense for your
organization. Finally, I’ll look at how you can quickly
and easily set up your own NT-based VPN.
The Business Case
You wouldn’t start a long journey without first deciding
where you’re headed and why you’re going there, right?
So, let’s start by looking at the problem. We’ll define
VPNs a little later. A good starting point is a high-level
look at remote access issues.
In a typical remote access scenario, a company supports
connectivity using modems and analog telephone lines.
This solution has been around for more than 20 years,
and the fundamental technology has changed very little.
On the client side remote workstations or laptop users
connect a phone line to their modems and dial into a remote
access server. On the server side administrators choose
some type of modem pool hardware and configure multiple
ports. Although the solution is readily available for
most companies, it has several problems:
- Costly solutions. Purchasing
serial port concentrators or proprietary modem bank
hardware can be quite expensive. Worse yet, analog communications
(such as phone lines) provide low-bandwidth solutions
relative to their cost.
- Complicated administration.
Implementing and managing proprietary solutions can
become quite a chore. Your IT department will need someone
familiar with the dial-in solution you’ve chosen.
- Limited scalability.
If you want to add support for more concurrent connections,
you’ll have to add more modems on the server side. Based
on your choice of hardware, this might mean adding another
eight ports, even if that’s not what you really need.
- Inefficient use of bandwidth.
Modem connections are one-to-one. That is, for every
user logged onto the system, one modem is in use. This
is true whether or not the user is actually transferring
data. Consider the case of a server supporting four
concurrent 33.6Kbps connections. Assume that three users
have downloaded their email and are composing replies
while still connected, and the fourth is surfing the
Web. In this case, you can see that about 134Kbps of
bandwidth is occupied despite the fact that only one
user is actually exchanging data (while the others are
reading their email). Worse yet, when the fifth user
comes around, guess how she’s greeted… That’s right,
a busy signal!
- Lack of support for new technologies.
Cable modems, xDSL (Digital Subscriber Loop), ATM (Asynchronous
Transfer Mode), ISDN (Integrated Services Digital Network),
and Frame Relay technologies are becoming increasingly
available and affordable. An analog modem-based solution
doesn’t support these new connection methods.
- End-user support is resource-intensive.
The traditional remote access solution is usually
set up and managed by an organization itself. This means
that on the client side, the help desk is responsible
for configuring and supporting dial-up user accounts,
while systems administrators manage server-side hardware.
Sound pretty grim? Well, here comes the good part… Loosely
defined, a VPN uses an insecure, public network for the
purpose of securely transferring data. Think of VPNs as
just another connection between remote offices and off-site
users. Just like traditional remote access and other WAN
connections, VPNs connect servers and workstations that
are located in geographically isolated areas. Unlike those
solutions, however, VPNs use public network infrastructures.
For most private organizations, this will mean using the
Internet. Figure 1 provides a high-level overview of how
a VPN works. Notice that clients can use a variety of
methods—including LAN access, modems, and xDSL—to connect
to the Internet. The clients then authenticate with the
remote VPN server. From then on, all data is encrypted
as it’s passed securely over the Internet to the comfort
and safety of a remote LAN. For now, keep this high-level
overview in mind. Later in this article I’ll discuss exactly
what hardware, software, and network protocols you’ll
need to set up a VPN.
|Figure 1. In a VPN, clients connect
to the Internet and then form a secure connection
to their remote server.
So how does a VPN help solve your problems? First, a
VPN can be very inexpensive to implement—both initially
and in the long run. For example, Windows NT/Windows 2000
Server already include the necessary software (as do Win9x/WinNT/Win2K
clients). Other benefits include:
- Simplified support and administration.
Since all of your clients will connect to the Internet,
you can offload support to ISPs. For example, if a remote
salesperson is having a problem getting connected to
the Internet, he can call his cable modem provider to
help with configuration and troubleshooting. On the
server side, you’ll only need to manage one Internet
connection instead of multiple analog modems. Many solutions
also offer integration with the NT account system.
- Lower data transport costs.
Shared Internet connections are much cheaper than dealing
with long-distance costs and managing one-to-one analog
modem connections. Imagine, if you will, an executive
who makes frequent international trips. Instead of connecting
to the company with an unreliable and costly telephone
connection, she can connect to the Internet using a
local ISP and then create a secure tunnel to your VPN
- Scalability. On the server
side, bandwidth is only consumed when users are actually
transferring data. On the client side, users can choose
any type of Internet connection that’s available to
Justify Your Decision
If you currently support or administer remote access
solutions, the benefits I’ve just listed probably sound
attractive to you. Now that you’ve determined that a VPN
could help your business environment, let’s look at some
ways to justify its implementation. If you’re an IT professional,
chances are you’ll need to get write-off from upper management
before investing in and implementing a VPN solution. Some
strong allies might be end users, heads of other departments,
and your own cost justifications. If implemented properly,
a VPN solution can offer your company a very quick return
on investment (ROI) and a greatly lowered total cost of
Evaluating VPN Options
The purpose of a VPN is to ensure that your communications
are kept secure, even over a shared public network. So
far, we’ve talked about the potential business benefits
of implementing and using a VPN. In this section, we’ll
examine the technical details involved with this relatively
new technology. First, you’ll need to decide which VPN
model to use. Then, it’s time to consider protocols and
confront the nagging questions of reliability, security,
There are three major ways to implement a VPN. All meet
the basic requirements: secure authentication and encryption
of data during transfer. However, they also differ in
Hardware VPNs. A
hardware-based VPN is usually implemented through the
use of VPN routers that are configured at either end of
an Internet connection. It connects remote networks without
forcing you to reconfigure clients. However, hardware
solutions can lock you into using proprietary hardware
and protocols, and they may be expensive.
Software VPNs. Several
solutions allow client machines to encrypt data and automatically
make a direct connection with a VPN server. Although this
requires reconfiguring client machines, it offers maximum
control and is a good solution for traveling users who
aren’t connected to a LAN. Later in this article, I’ll
demonstrate how Windows-based operating systems can be
used in a VPN.
If you don’t want to set up, manage, and support your
own VPN-based solution, you can outsource this functionality
to an ISP that provides VPN services. The ISP will be
responsible for configuring client systems to log onto
their secure access points and encrypting all data during
transmissions. At the other end of the connection, your
server will connect to your ISP’s point of presence and
receive standard, decrypted network data. Use this solution
when you have a large number of remote access users and
want to outsource much of the burden related to implementation
After you decide which type of VPN implementation method
is appropriate for your business requirements and environments,
it’s time to get down to the technical details. Let’s
start with a run-down of the current standards:
- Point-to-Point Tunneling Protocol
(PPTP). Originally introduced by Microsoft with
NT 4.0, PPTP is a protocol-independent, software-based
protocol. Windows 95/98, NT 4.0, and Win2K all support
the use of this protocol. Although PPTP will continue
to be supported in future operating systems, L2TP (an
improvement to PPTP, which I discuss in a moment) will
also be available and will eventually replace PPTP.
- Layer 2 Forwarding (L2F).
Developed primarily by Cisco and used in hardware implementations
of a VPN, L2F is an IP-based protocol. Its most common
implementation involves an L2F-compatible router at
each end of the VPN connection.
- Layer 2 Tunneling Protocol (L2TP).
Developed by Microsoft and Cisco, L2TP will be the new
standard in Win2K. L2TP aims to be protocol-independent
while providing some of the advantages of L2F.
- IPSecure (IPSec). Currently
being finalized as an Internet standard, IPSec is a
TCP/IP-based suite of protocols that can manage authentication
and encryption for secure connections. The protocol
will be included in the next version of the IP protocol
(IPv6) and will help hardware vendors design compatible
devices. (For more information, see www.ietf.org.)
What does all this mean to you? When evaluating a solution,
look for products and services that allow (or will allow)
the use of L2TP and/or IPSec.
The Reliability and Security Concerns
If you’re thinking that VPNs can be a risky proposition,
you’re right. After all, you’re sending potentially sensitive
information over the Internet. Despite its redundant design,
the infrastructure of the Internet is prone to problems.
Good solutions are available, though. If remote access
is extremely important to your company, consider entering
into a Service Level Agreement (SLA) with your ISP. Be
sure to read the fine print, however, because many SLAs
don’t offer you much of a guarantee.
As far as security is concerned, there are two main goals.
First, ensure that users are authenticated securely. If
the standard password-based methods (such as NT’s CHAP
implementation) aren’t enough, consider using other solutions
such as SecureID, Remote Authentication Dial-In User Services
(RADIUS), or biometrics (such as fingerprint or voice
recognition). Second, make sure that your data is unusable
if intercepted during transmission. To accomplish this,
most VPN implementations will offer at least 40-bit encryption
security. While this is reasonable for most general network
connections, you should bump this up (to 128-bit, for
example) if you want extra peace of mind.
Performance and Scalability Issues
When dealing with the Internet, it’s important to consider
performance issues. Much of the network you’ll be using
is beyond your control, so you should perform a load test
before deploying your solution. Most ISPs will give you
bandwidth guarantees through SLAs, but be sure you understand
As VPN data is encrypted (and optionally compressed)
during transfer, you’ll also need to consider the processing
overhead for these functions. On the client side, the
effects should be negligible—even the fastest Internet
connections available won’t outperform today’s CPUs. On
the server side, however, be sure to perform adequate
load testing to determine what you can handle. If you
need more power, you can purchase dedicated encryption
cards that offload this functionality from your CPU. Scalability—the
ability to take advantage of increased bandwidth—shouldn’t
be a problem. On the client side your users can obtain
Internet access any way they want. On the server side,
you can almost always get more bandwidth from your ISP.
You can also deploy multiple VPN servers and balance the
load using specially configured DNS servers or routers.
Implementation Best Practices
Setting up a VPN server, especially with NT, can be quite
easy. But you’ll also face several other challenges. Here
are some tips for making the best of your VPN rollout.
- Get buy-in from other departments.
Take the time to speak with users and department heads
to explain how this solution can reduce costs and give
them a better remote access experience. It shouldn’t
be difficult to get support. Buy-in can be a great asset
when trying to pitch VPN plans to management.
- Get acquainted with your ISP.
Your IT team will be working closely with your preferred
ISP(s) for managing server-side connections and (optionally)
for supporting remote users. Get to know your ISP’s
support policies and clearly define the roles of both
- Develop a test environment.
You’ve probably heard this before, but it’s very important
that you test your solutions before unleashing them
on unsuspecting users.
Setting Up an NT-Based VPN
So far, we’ve looked at both the business and technical
issues associated with evaluating a VPN. If you’re working
in a Windows-based environment, you’ll be happy to know
that you already have the tools to set up a VPN. The major
benefits of using NT Server to create your VPN include
low cost (free for licensed users), quick setup (the basics
can be done in about 30 minutes), and ease of administration
(integration with the NT Security Accounts Manager). Fortunately,
the exact steps for setting up an NT Server to use PPTP
are quite simple, as is management. In this section I
provide an overview of the steps required to implement
an NT-based VPN. Rest assured, you can get more details
elsewhere (see “Additional Information” in this article).
First, Get Current
For Windows 95/98 clients, you’ll need to get the Dial-Up
Networking (DUN) 1.3 Update. You can download this from
Microsoft (again, see “Additional Information”). For NT
4.0 Server and Workstation users, the latest Service Pack
is highly recommended. You can also download and install
the Routing and Remote Access (RRAS) Update for NT 4.0
Server. This new add-on supports dynamic routing and provides
a new administration console. Note that if you have RAS
installed and you install NT Service Pack 4 (or later),
the service will automatically be upgraded to the Routing
and Remote Access (RRAS) service. For now, I’ll assume
you don’t have RRAS installed, although the basics are
Second, Cover Your RAS!
NT’s VPN technology is a part of the Remote Access Service
(RAS). If you know the basics of using the NT Remote Access
Service, you’ll be well on your way to setting up an NT
VPN. Windows 9x/NT 4.0 uses PPTP and logical VPN adapters
to set up a secure connection over the Internet (see Figure
|Figure 2. An overview of how
to set up a Windows NT 4.0 VPN.
Here are the basic steps:
- Install the Point-to-Point Tunneling
Protocol (PPTP). Go to Control Panel | Network.
In the Protocols tab, click Add… and then select the
“Point-to-Point Tunneling Protocol.” You’ll be prompted
for the number of VPNs you want to configure. This will
be the maximum number of concurrent VPN connections
this server will support.
- Install the Remote Access Service
(RAS). Go to Control Panel | Network. In the
Services tab, click Add… and then select the “Remote
- Configure ports for RAS. In
the next dialog box, you’ll be prompted to assign the
various “devices” available for use by RAS. Devices
can be physical (such as modems or ISDN adapters that
you’ve already installed), or they can be logical (such
as the VPN adapters you set up in step 1). Each port
can be configured to allow dial-in, dial-out, or both.
- Configure RAS network properties.
Each port assigned to RAS can support one or more protocols
(TCP/IP, IPX/SPX, and/or NetBEUI). You can also route
traffic by using the “Entire network” button in the
options for each protocol (see Figure 3).
|Figure 3. Configuring RAS protocol
options on NT Server.
The steps are a little different for Win2K, but the ideas
are the same: You add the VPN protocol and then configure
the RRAS service to use the virtual adapters. Get more
information at www.microsoft.com/communications.
|If you’re having problems
connecting, here are some “gotchas” to
look out for:
- Internet configuration.
For this setup to work, your VPN server
must be accessible via the Internet.
This means that you either have a
DNS name configured for the box (such
as vpn.mycompany.com) or you instruct
users to use an IP address. Either
way, your ISP can help you take care
This is by far the most common connectivity
problem! PPTP requires that data be
allowed to pass on TCP Port #1723
and IP Protocol #47 (Generic Routing
Encapsulation). This generally isn’t
a problem with ISPs, but if your company
firewall restricts this traffic, you
won’t be able to authenticate and/or
connect to your VPN server. [For
more information on firewalls, see
Roberta Bragg’s “Security Advisor”
Up a Flame-Proof Firewall,” in
Third, Configure Your Clients
Now that your server is ready for business, it’s time
to configure your clients. The first step is to make sure
your users have access to the Internet. For laptop users,
this will probably mean configuring a Dial-Up Networking
(DUN) connection to an ISP. For remote branch offices
or users on a LAN, they may already have Internet access,
so you’re all set. Once they’re on the Internet, users
will need to use a second DUN connection to establish
a VPN session with your remote server. This connection
will have two differences: Instead of using a modem, you’ll
choose a VPN adapter, and instead of a phone number, you’ll
enter in the IP address (or DNS name) of the remote machine.
Now, when clients need to connect, they’ll first establish
an Internet connection. Then, they’ll use the second VPN
DUN connection to authenticate with your remote server.
|VPN technology is still
relatively new in the IT industry. Fortunately,
plenty of resources are available to help
you implement a VPN.
- Microsoft Communication Services
Web Site at www.Microsoft.com/communications
for in-depth technical information
about PPTP and RRAS, Win2K communications
features and case studies regarding
- “Troubleshooting PPTP Connectivity
Issues in Windows NT 4.0,” Microsoft
KnowledgeBase article Q162847, which
provides a thorough checklist of troubleshooting
steps for an NT-based VPN.
- “Evaluating MS PPTP Remote Access
Cost Factors,” a Microsoft TechNet
article listing costs that must be
considered before implementing a VPN.
- “Understanding PPTP (Windows NT
4.0),” a Microsoft TechNet article
with everything you ever wanted to
know (and more) about PPTP!
- Various vendor Web sites, including
Cisco at www.cisco.com,
3Com at www.3com.com,
Shiva at www.shiva.com,
and UUNet at www.uu.net
for information about third-party
hardware and outsourced VPN solutions.
- “IP Security Protocol (ipsec),”
an article at www.ietf.org/html.charters/ipsec-charter.html,
which provides information about the
status and details of the IPSec protocol.
Bringing it all Together
So there you have it—an overview of VPN technology with
business justifications for its use. Personally, I’ve
found that pitching the VPN idea has been an easy sell,
especially in small- to medium-sized organizations. The
challenge for you, the resident IT pro, will be to convince
management that it’s a good idea and to find the best
way to implement it. Considering the shortcomings of traditional
remote access and the business benefits of a VPN, it shouldn’t
be tough. Good luck, and may I never see your unencrypted
packets on the Internet!