In-Depth

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.

VPN Solutions

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 server.
• 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 them.

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 ownership (TCO).

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, and performance.

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 several ways:

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.

Outsourced VPNs. 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 and support.

Protocol Soup

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 the terms.

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 parties.
• 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 almost identical.

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 2).

Figure 2. An overview of how to set up a Windows NT 4.0 VPN.

Here are the basic steps:

1. 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.
2. Install the Remote Access Service (RAS). Go to Control Panel | Network. In the Services tab, click Add… and then select the “Remote Access Service.”
3. 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.
4. 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.

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.

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!