Networking

Decision Support: Issues surrounding a Windows 2000 VPN implementation

Learn about the problems you may have to address when implementing a virtual private network in a Windows 2000 environment


If your business has multiple locations, there’s a good chance that sooner or later someone will ask you to link the various locations’ computer systems together. When taking on such a task, you have a couple of options. One option is to use a leased line, such as a T-1 line, to connect the facilities. Leased lines typically cost big money, however. If a leased line is out of your league, another option is to create a virtual private network. In this Daily Feature, I’ll discuss some of the issues you’ll face when implementing a virtual private network in a Windows 2000 environment.

What’s a virtual private network?
Virtual private networks (VPNs) are often misunderstood. It seems that these days, practically everyone is selling a VPN solution, and they’re all different. For example, you can buy VPN solutions from router manufacturers and firewall vendors. Likewise, there are pure hardware VPN solutions and VPNs that are part of your network operating system, as in Windows 2000.

Each of these solutions works differently. Some of these solutions conform to the standards of a true VPN, and others don’t. Because of the variety of virtual private networking solutions, I’ll begin by discussing virtual private networking from the standpoint of a generic VPN solution. Once I’ve covered the basics of how VPNs function, I’ll discuss implementing a VPN in a Windows 2000 environment.

To understand how a VPN works, let’s assume you’ve been asked to link two corporate networks together, but a dedicated leased line is too expensive. Instead, you’ve thought about using a VPN. In its purest form, a VPN is nothing more than a method for joining two private networks together by passing data packets between the two networks through one or more third-party networks.

The most common example of a VPN is a situation in which two networks exchange data through the Internet. For example, suppose a user in Las Vegas needed to access a file from a server in Miami. If the two networks were linked through a VPN, the user could access the needed file just as though the Miami server were sitting in the next room. The end user would be totally oblivious to the fact that the file was passing through the Internet to get to the Las Vegas office.

Issues to consider
At first, the idea of passing files across the Internet may not seem like that big a deal. After all, we all exchange files through e-mail everyday. However, VPNs work differently than e-mail servers. In an e-mail environment, it’s up to a user to send specific files to someone else. In a VPN, however, any user with the appropriate permissions may access any file on the network without the need for someone to send the files to them. To a user on a VPN, the remote servers look and act as if they are on your LAN.

If you stop and think about it, this means that your servers are totally exposed to Internet users. That’s a very scary thought when you consider the insecure nature of the Internet.

Because the Internet is full of people with questionable intentions, it’s necessary to protect your servers. This is where the word “private” in virtual private networks comes in. VPNs are designed so that only registered network users may access your network. In a Windows 2000 environment, this is accomplished by using a combination of different protocols and encryption methods. I’ll discuss the specifics of Windows 2000 VPN security a little later.

When it comes to virtual private networking, performance and reliability are just as important as security. After all, what good is security if you can’t even access your own data? When it comes to virtual private networking, the issues of performance and reliability can be summed up in a single sentence that I can’t stress enough: Your VPN is only as good as your Internet connections.

To understand why this is so true, consider how a Windows 2000-based VPN works. When packets are destined for a remote location, the packets are encrypted and encapsulated inside a protocol that’s specifically designed to move the packets safely across the Internet. Because of the encryption and encapsulation techniques being used, packets flowing across a VPN tend to be larger than packets flowing across a conventional network. A significant amount of bandwidth is required for moving these larger packets. Now consider your Internet connection. Browsing the Web involves a relatively small amount of data exchange. If your Internet connection is too slow to comfortably surf the Web, what will happen when you flood the connection with VPN packets? I’ll give you one guess.

To build an effective VPN, your Internet connection should be as fast and reliable as possible. Keep in mind that this rule applies to both offices. After all, your VPN is only as fast as the slowest Internet link involved. Therefore, if the Las Vegas server from my earlier example has a T-3 connection, but the Miami server only has an ISDN link, then your VPN will be limited to ISDN speeds.

Technically, a VPN will work with slow Internet connections, but you’ll almost have to use some form of broadband communications to build your VPN. If you’re limited to using analog modems, communications are faster and infinitely more secure if the two servers dial each other directly rather than having the packets pass through the Internet. The only downside to such an arrangement would be the charges for the long distance phone call. The slowest practical connection I’ve seen successfully used for a VPN involved using a 128-Kbps ISDN link with a static IP address.

Windows 2000 VPN security
There are two protocols you can use for Windows 2000 VPNs. The first is Point-to-Point Tunneling Protocol (PPTP). Although still widely supported, PPTP is being slowly replaced by IPSec-based VPNs. To help you to decide which protocol is right for your VPN installation, I’ll discuss the two protocols in detail and then compare the two.

Point-to-Point Tunneling Protocol
PPTP was the original VPN protocol Microsoft introduced. Many forms of Internet communications use the PPP (Point-to-Point) protocol. PPTP is merely an extension of PPP.

I mentioned earlier that VPNs rely heavily on encapsulation. The way the Windows 2000 PPTP implementation works is that standard network packets are encapsulated inside PPTP packets. The PPTP packets are then passed across the Internet. The advantage of using this method is that it works regardless of the protocol being used on your corporate networks. For example, suppose that your corporate networks use IPX/SPX. If a packet was destined for the remote network, the IPX/SPX packet would be encapsulated inside a PPTP packet.

When the remote VPN server receives the PPTP packet, it recognizes the packet as a PPTP packet, and the packet is allowed to pass through the firewall (assuming that you’ve opened the appropriate firewall port). Once the packet gets past the firewall and reaches the VPN server, the PPTP shell is stripped away. At this point, the remaining data is a true IPX/SPX packet. The IPX/SPX packet contains all of the usual information, such as the sender and recipient. The packet is then placed onto the network where it will reach the destination PC in the usual manner.

IPSec
IPSec is the first standards-based VPN protocol. IPSec is actually a collection of several services and protocols that are designed to collectively provide comprehensive security. In a virtual private networking environment, IPSec provides the mechanism through which the data is encrypted and decrypted.

While IPSec itself is responsible for establishing a secure connection between the two private networks, Microsoft’s implementation takes security a step further. It uses a mechanism called L2TP (Level 2 Tunneling Protocol) to better encrypt things like usernames, passwords, and data.

Not only does IPSec offer the encryption services necessary for VPNs, it also prevents hackers from launching a replay attack against either network by being “replay proof.” A replay attack is the process by which hackers capture packets and then replay them in order to gain access to a network. IPSec guards against replay attacks by associating a sequence number with each packet. If the recipient receives a packet with a sequence number that’s already been received, the packet is assumed to be fraudulent and is therefore discarded.

Comparing PPTP and IPSec
Now you know a little bit about how both VPN protocols work. Before you can truly make an informed decision about which protocol is right for your network, however, it’s necessary to understand the differences in the two protocols.

In a nutshell, IPSec is a standards-based protocol that runs on a variety of operating systems, such as Windows, Macintosh, and Linux. IPSec uses DES/3DES encryption and supports header compression. IPSec has minimal requirements for the network media since it only requires packet-based point-to-point connectivity.

PPTP, on the other hand, is a proprietary protocol designed by Microsoft to run on Windows and Linux platforms. It uses a proprietary encryption algorithm designed by Microsoft and doesn’t support header compression. PPTP also requires that the transit network support the IP protocol.

So which protocol is right for you? It depends on your network. If you’re adding an extra site to an existing Windows-based VPN, then it may be wise to stick with PPTP. If you’re building a brand-new VPN that’s purely Windows 2000 or that uses non-Microsoft/Linux VPN servers, however, IPSec is the protocol of choice.

Conclusion
In this article, I discussed some of the issues involved in creating a VPN in a Windows 2000 environment. As I did, I addressed typical concerns, such as cost, security, and reliability. In an upcoming article, I’ll discuss the actual process of setting up a VPN.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox