Tip

Save your bacon with a VPN

When you have a lot of remote users -- and who doesn't these days -- you need some way to connect them to the home office. But at the same time, you need to make sure that they are connected securely. That means, no one can see what the user is doing and, similarly, outsiders can't piggyback onto your remote users' connections into the home office and wreak havoc.

A virtual private network (VPN) is one solution. These software constructs surround your network connections to your remote folks with layers of encoding, controlled by various protocols, that make it tough (nothing is impossible) to break into the channel. This way the legitimate users can connect to your home office and get the data they need, while outsiders are kept... outside.

VPNs increase overhead, so operation will be slowed down quite a bit. For example, I interrupted writing this tip to test the connection speeds here at my remote office with three computers. All the computers are connected through a cable router to a local cable ISP. One is a Sony Vaio PCGF520, with 200M bytes of RAM and a 500-MHz processor. It's connected to our corporate VPN. One is a Dell Dimension with a 750 MHz Pentium III processor and 256M bytes of RAM, not connected to the VPN, and the third is a slow old dog, a Gateway P5-90, upgraded to 200 MHz, with 40M bytes of RAM. The last one can barely get out of its own way, and I use it more as a print server and modem server than anything else.

I went to

    Requires Free Membership to View

    Login

PC Pitstop and conducted that site's Internet download test, downloading 500K bytes into each computer. The old dog came in with a speed of 866K bit/sec.; not great, but not awful (the connection has a theoretical max speed of 10M bit/sec. The Dell speedster delivered some impressive performance, clocking in at 1619K bit/sec.; only about 16% of the theoretical max, but still double the speed of the old dog. Neither of these is connected to our corporate VPN. But the Vaio, which isn't any slouch, and is connected to our VPN, dawdled along at only 625K bit/sec.; 241K bit/sec. slower than my resource-starved old dog. That test isn't definitive, of course, but it gives an idea of the performance hit your users may take with a VPN.

Moreover, some VPNs are a bit cranky. Frequently we'll see a message from some erstwhile remote user of our VPN that he's unable to stay on it. Personal experience indicates, however, that the good days FAR outnumber the bad, and it's clear that the security advantages hugely outweigh the performance disadvantages of using a corporate VPN for remote connections.

Microsoft has a new link on its home page that takes you to a page headed Professor Windows that discusses deploying VPNs. This page will probably give you more than enough information to get you started in deploying your own VPN. If you want to give setup a try, follow the procedure below, which is on a link from the Professor Windows page. (One note of caution -- this page will probably change content periodically, so if you go to it in a month or so it may not discuss VPNs any more.)

"To configure a VPN server, your computer must have at least two interfaces. To setup a Windows 2000 server for VPNs, use the following procedure:

1. Open Routing and Remote Access console in the Administrative Tools folder.
2. Right-click the server and then click Configure and Enable Routing and Remote Access.
3. The Routing and Remote Access Server Setup wizard starts; click Next.
4. Select Virtual private network [VPN] server, and click Next.
5. Select or add a remote client protocol and click Next.
6. Specify the Internet connection for the server and click Next.
7. Choose a method to assign IP addresses to the clients, either automatically or from a specified range of addresses, and click Next.
8. The next screen gives you an option to either configure this server to use a RADIUS server or skip this step for now.
9. Click Finish to complete the Routing and Remote Access Server Setup wizard."

Using a VPN isn't a simple matter, but you can start to test and make sure you have the bugs out of your installation. Then follow with deployment as the installation proves its worth.


This was first published in May 2001

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top