Finally, buying the technology that fits your needs is the safe choice. Purchasing a product that scales up as your network gets more critical is the better choice. You'll ensure the safety of your data and, ultimately, your user and customer satisfaction. Knowing exactly what you have before digging too deeply into the VPN world may save you precious time and money.

Knowing the Market

Years of R&D have taught me not to reinvent the wheel when shopping for technology. In a short period I also discovered that VPN technologies are still very new, so I had to turn to some old standby resources for clear explanations. What I found was a variety of solutions from more than a dozen vendors.

Next I looked to companies that have been good sources of technical knowledge over the years without beating me over the head with marketing propaganda. The hours I spent searching and reading online led me time and again to the Cisco Systems and 3Com Corp. Web sites. I found that both companies do an excellent job of explaining VPN technology, while leaving their sales pitches to the end of their articles. Reading articles from these sites gave me a thorough understanding of the protocols and physical connectivity without my having to endure the endless sales ravings of why a particular product is best. And the definitions and diagrams are clear and concise. (For a list of helpful Web sites, see VPN Resources on the Web.")

Knowing Your Users

I learned through my Web search that a VPN will play two major roles within my company. Role No. 1 is connecting our internal, but physically remote users to our LAN in a secure fashion (commonly referred to as remote-access VPN). These remote users form two distinct groups. The traveling group, including our salespeople, connect with laptops from hotel rooms, home, client offices and nearly anywhere they use their computers. The home-based users make up the second group. These users include some of our documentation writers, employees who had moved away from the main office but remained in their positions and anyone who telecommutes rather than treks to the office every day.

These two groups differ primarily in the devices they use to connect to the main office LAN and the speed at which they connect. Most of the traveling users are dialing into a modem bank in the main office, incurring long-distance expenses. Our RAS (remote-access service) logs them into the network, and performance is less than optimal, requiring us to bypass the systems-management services written into our logon scripts.

To compound the situation, we get a maximum of 28.8 Kbps, because our modem-bank capabilities are limited. Needless to say, a VPN has the potential to upgrade this connectivity and save the company some cash. The home users will likely connect with cable modems to local ISPs, then use a VPN for secure access to the central office.

Role No. 2 for a VPN within my company is to connect client LANs to our support groups in the main office. Much of our support is handled through secure dial-ups. The basic model is a familiar one: Clients phone our support people, who in turn dial into their system and work with the clients. In this case, a VPN would let us leverage our connection to the Internet and form a private extranet between our customers and us. Faster data connections to the clients and voice over IP on the same lines (perhaps eliminating the long-distance calls) make for a compelling service model. A VPN would serve to keep intruders out of internal and client systems.

The connectivity issues raised were numerous and the answers not easy to determine. The amount and source of bandwidth into the company became a major topic of discussion as my research progressed. Would we need to purchase bandwidth beyond that provided by our frame relay T1? Would our vendor (a local ISP) be able to offer services to all our clients throughout the United States? Would a VPN be appropriate in the "wilderness" of the Internet, which can't guarantee dedicated bandwidth? Would our customers demand the performance and security of a private network connection? The questions began to pile up. The answers came much later. For now, we needed to keep up the research, by looking at our situation.

Know Thy Network

Once we had identified the people we needed to serve with a VPN, we began to look closely at our existing environment. From my "Web-splorations," I found that the protocols running on the internal network of the company will play a major role in a VPN decision. This is because IPsec (IP security) and other VPN protocols are not compatible with every other protocol. The bottom line here is that if your network is running only on TCP/IP, you have the common denominator of all VPN technologies. Every hardware and software VPN solution, no matter the protocol, is designed to package and tunnel TCP/IP packets. NetBEUI or IPX/SPX-based networks will have a limited number of options if your VPN solution requires those packets to be tunneled to another site. Because our network runs only TCP/IP, protocol support wasn't a concern for us.

With my vendor list in hand, I looked for the VPN offerings from companies whose products we had purchased previously. My logic was to determine if we could leverage our existing technology into a VPN solution with a high level of compatibility. After chatting with our network administrator, I found four likely solutions to compare. Our company recently added a PIX firewall from Cisco, which offers a solution as part of its PIX software bundle. Our Bay Networks router, now a Nortel Networks product, comes from a line of products that includes VPN solutions. We use both Microsoft and various flavors of Unix servers in our environment, so I determined a software-only solution might also suit our needs. Because we eventually would migrate to Microsoft Windows 2000 on our domain servers, the VPN support could be suitable for our needs and easily configurable with our existing network.