Do you have traveling users on your network who wish they could connect to your corporate network from home, a hotel room, or even an airport? Unfortunately, many companies don't have a remote access server (RAS) in place to make this possible. Even if your company does have a RAS, what are the chances that the line will be busy when you call? In either case, doing business on the road can be difficult. However, by setting up a virtual private network (VPN), you can access your corporate network from anywhere that you have access to an Internet connection.
What is a VPN?
A traditional network consists of two computers that must communicate with each other. The two computers are connected by a physical medium, such as an Ethernet connection. A VPN works on the same principle. It consists of two computers that must communicate and a medium. However, unlike with traditional networks, this medium isn't dedicated to the network in question. Often the medium is the Internet. Because both computers are connected to the Internet, it's possible to establish a route through the Internet between the two computers. In the case of a VPN, this route is called a tunnel.
Introducing the Point-to-Point Tunneling Protocol
As you're probably aware, a network connection requires the computers on the network to share a common protocol. A protocol is the language computers use to communicate over the connection medium.
For a standard Internet connection, computers
use the TCP/IP protocol over a PPP (Point-to-Point Protocol) connection. In the case of a VPN, this concept is taken a step further. The Windows 98 implementation of virtual private networking relies on a protocol called PPTP (Point-to-Point Tunneling Protocol). As you might have guessed from the name, PPTP is simply an extension of the PPP protocol. PPTP provides a tunnel through the logical connection medium that allows the two computers to communicate.
Because of the way PPTP works, you can use it regardless of the communications protocol your corporate network normally uses. For example, suppose your corporate network normally uses Internetwork Package Exchange/Sequenced Package Exchange (IPX/SPX). You can set up IPX/SPX on your remote computer and communicate with your corporate network using IPX/SPX packets traveling across PPTP.
Virtual private networking over the Internet
Now that you're familiar with some of the basic concepts and terminology associated with VPNs, let's look in a little more detail at how virtual private networking works.
When establishing a VPN connection over the Internet, the remote user must make two connections. The first connection is to the user's Internet service provider (ISP) by way of a dial-up session. As I mentioned earlier, this dial-up session uses TCP/IP and PPP to communicate with the ISP. At the time the connection is made, the remote user is automatically assigned an IP address by a Dynamic Host Configuration Protocol (DHCP) server at the ISP's office.
The second connection actually creates the VPN. It uses some of the Windows 98 code that's normally associated with dial-up networking to establish this connection over the existing PPP connection. Packets are sent across the second connection in the form of IP datagrams containing encapsulated PPP packets.
Under normal circumstances, when a remote user tries to access a corporate network via the Internet, the company's firewall prevents PPP packets from entering the network. This means the private network is inaccessible to Internet users. However, when the company loads the VPN services, it can enable certain firewall ports that provide a route across the firewall (or router) and allow Internet users who meet specific security criteria to access the private network from across the Internet.
When a VPN server receives a packet from across the Internet, it disassembles the packet. From this packet, it can derive the name of the computer the packet was intended for. The packet also contains the underlying protocols, such as NetBEUI and IPX/SPX. Once this information has been extracted into a usable form, the packet can be passed from the VPN server to the destination computer residing on the private network. As you can see, the VPN server functions similarly to a gateway.
Because you can embed standard networking protocols into a packet that's sent across a VPN, all standard networking features continue to work. For example, name resolutions by way of a Windows Internet Naming Service (WINS) server or a Domain Name Service (DNS) server will function just as if the remote host were directly plugged into the local network.
Because name resolution continues to function, you may be wondering about the general DNS requirements. After all, addressing a computer by name across the Internet normally requires the name to be registered and globally accessible. However, in the case of virtual private networking, only the VPN server needs a valid, globally accessible DNS name (with a static IP address). This is because when you send packets from the remote computer, the VPN server is as far as those packets must travel. As far as anything on the Internet knows, the VPN server is the packet's final destination. It's not until the VPN server disassembles the packets that they're passed on to their true final destination. Because the packet already resides at the local level at the time of disassembly, the Internet requires absolutely no knowledge of the name of the computer that's the true final destination of the packet. As a matter of fact, it's a bad idea from a security standpoint to make the name of that computer accessible via the Internet. You should place all local nodes on your network, as well as the VPN server, behind a firewall for protection.
Virtual private networking and routing
As I mentioned earlier, connecting to a VPN involves using two dial-up networking sessions. The first session establishes your Internet connection. Once you're connected to the Internet, you can establish the VPN connection via the second dial-up networking connection. However, there are a couple of side effects you should know about.
First, when you launch the VPN session, the Internet is no longer accessible for standard access (Web browsing, e-mail, and so forth) unless the network you're connecting to can also get to the Internet. If the remote network doesn't provide access to the Internet, you can't surf the Web or check your e-mail at the same time you're connected to a VPN.
Second, you should know that establishing a VPN session kills your connection to any local networks you might be attached to. For example, suppose you're part of a 10-user workgroup. Now suppose you establish a VPN session to a corporate enterprise network. Once you do, the corporate enterprise network will be accessible but your workgroup won't be. Consequently, you won't be able to use Windows 98 to route packets between the two networks.
The reason for these routing limitations lies in the way the PPTP protocol affects Windows 98's local routing tables. If you absolutely have to connect to the Internet, to a local network, or to both at the same time you're connected to a VPN, you may be able to do so in some cases by using Windows 98's Route command. The Route command can be used to make Windows 98 aware of other IP networks that you're connected to without the aid of a router.
Given the insecure nature of the Internet, security is a big concern with VPNs. After all, you don't want someone to steal your packets as they flow freely across the Internet. And you don't want your corporate network to be compromised. Fortunately, the Windows 98 implementation of virtual private networking is designed to be secure. In this section, I'll discuss some of the aspects of VPN security that you need to be aware of.
The first step in having a secure environment is to have strong passwords. When you dial in to your ISP, it typically asks for a password. However, this password only grants you an Internet connection-it has absolutely nothing to do with your VPN access. Instead, when you establish the VPN session, you'll be prompted for a second password. This is your usual Windows NT (or Windows 2000) domain password. The password is authenticated using the same method a RAS server uses. You can use Challenge Handshake Authentication Protocol (CHAP), Microsoft CHAP (MS-CHAP), or Password Authentication Protocol (PAP) to authenticate Windows NT passwords.
Once a user has been authenticated into a Windows NT domain, all the usual security mechanisms continue to apply. For example, all NTFS permissions and share permissions apply to a user who's connected through a VPN just as if the user were connected to a network locally.
An added level security comes from encryption. Once a user has specified his or her password, the remote client and the VPN server generate a 40-bit encryption key that can be used to encrypt and decrypt packets. If you're using Windows NT Server with Service Pack 1, 2, or 3, this encryption key changes with every 256 packets. If you're using Service Pack 4 or above, the encryption key changes with every packet. To further enhance security, users in the United States and Canada may use 128-bit encryption as opposed to the standard 40-bit encryption.
I mentioned earlier that you should always place your VPN server behind a firewall. A firewall is designed to block all unused IP ports. This prevents attacks on your network by malicious Internet users. Another function of a firewall is to hide the computer names and IP addresses used on your private network from Internet users.
If you already have a firewall in place, you'll have to enable the ports that are used by virtual private networking before the VPN server will be accessible from across the Internet. Remember that virtual private networking relies on the PPTP. PPTP uses TCP port 1723 and ID number 47. Therefore, you must enable port 1723 and ID 47 (in some cases listed as Protocol 47) before you can use virtual private networking. If these addresses aren't enabled, all VPN traffic will be stopped at the firewall and will never even reach your VPN server, not to mention the rest of your network.
This was first published in September 2001