Introductory VPNs: Mapping LANs and Lines for Fewer Landmines
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Somebody from the head office wants you to set up a virtual private network (VPN), and you can't talk him out of it. Or maybe you've decided on your own that you need a VPN. There are some good reasons for setting up a VPN, such as these:
You need to link branch offices without paying for dedicated direct lines.
It's cost-effective to let the phone company carve a slice of the Internet and let your wandering staff "tunnel" to work, rather than install a modem bank and pay for individual lines plus the toll charges that would go with Remote Access Services (RAS).
Of course, a VPN can be slower than dial-up—but that's the least of an overburdened IT manager's worries.
What's so bad about virtual private networking? In theory, not much. In practice, the jumble of protocols, platforms, and standards; the wild range of product quality and performance; and the real need for administrative competence in networks, operating systems (cross-platform, not just Windows), and security make VPNs one of the most hairy undertakings a nice IT manager could encounter.
This article helps you plan past some common VPN landmines, swamps, and quicksand like a superhero. The next article in this series will work on general troubleshooting, helping you learn some of the VPN ropes that can help you lasso your users out of the tar pits and into the tunnel.