VPN tips from the trenches

By SUZANNE GASPAR
Network World, 05/10/99

When Dave Bixler, IT core technology service manager, deployed his firm's second-generation virtual private network (VPN) in January, he didn't anticipate having a problem that would be beyond his control.

Entex Information Services, a systems integrator headquartered in Rye Brook, N.Y., had just migrated about half of its 3,000 users from Compaq's Alta Vista Tunnel 98, and planned to keep the VPN up as an additional resource. However, the firm needed a second VPN to accommodate a growing number of users. Entex also wanted to set up a standards-based VPN and move away from soft key authentication.

At the end of March, Entex experienced congestion problems on its T-1 connection that supported the new VPN. For over a week, the firm's help desk was receiving about 100 calls a day about the matter. IT tested the lines and discovered that the problem seemed to occur over a three-hour period each day. After the ISP wasn't able to resolve the problem within seven business days, Bixler disabled the connection and routed all those users through the firm's 5M bit/sec primary Internet connection supplied by another ISP.

The VPN hummed along for a few days and then the help desk started getting calls again. IT tested the line and this time the problem appeared to be with the firm's dial-up connection for remote users. This third ISP was aware of the problem and added network capacity, but still this took almost three days. In the meantime, Bixler's users were yet again unable to access the corporate network.

Entex' spate of bad luck continued, and this time the problem was with the firm's primary ISP connection. However, this primary ISP was dual homed to two major ISP backbones, and the troublespot was located on one of these networks. Bixler wasn't a direct customer of that ISP, so he faced yet another issue: he now had to work in conjunction with his primary ISP to correct the problem. The first fix took care of 75% of the ISP's users. A second fix, implemented the next day, resolved the issue for the final 25% of the points of presence.

The bottom line was that Bixler's VPN had approximately four weeks of intermittent downtime for users thanks to four separate problems that were spread across three different Internet backbones. Entex users thought the company could fix the problem, but IT was completely reliant on the ISPs.

"Deploying a VPN can be a wild ride. There are a number of caveats and it is still an evolving technology," Bixler says. "The upside is that it can be done."

Fortunately for Entex, the horror story came about during the second VPN implementation. Having survived his first, Bixler based his deployment strategy on lessons learned.

First, he developed an initial list of 12 products to evaluate. He wanted a VPN that supported IPSec, Radius or NDS authentication, and 3DES encryption or the equivalent. Moreover, the product had to be easy to install and support and scale to more than 1,000 concurrent users.

Bixler narrowed the list down to five suitable products. He piloted all the products and decided on two Compatible Systems IntraPort Enterprise units because this product was the only one to meet all his criteria.

Old Republic Title Company, a San Francisco-based real estate transaction service provider, was another firm that carefully evaluated VPNs before choosing a product. Robert Matanane, vice president of IT operations, says his firm needed to implement a VPN to connect its offices in Arizona, California, Hawaii, Nevada and Washington, as well as to provide remote access.

"Direct connections via frame relay or point-to-point were very costly," Matanane says. "The idea that VPN could solve both our connectivity issues appealed to us."

Matanane visited a company that was using a VPN to connect two branch offices to a main office. This gave Old Republic's IT group a real-world proof of concept, he says. Moreover, reading numerous reviews in trade magazines and talking to other firms that had deployed VPNs was useful.

After considering a few hardware- and software-based VPNs, Old Republic decided to add a new 3Com PathBuilder 500 at headquarters and take advantage of its remote site's existing 3Com Super Stack NetBuilder switches.

Although Matanane is generally pleased with the VPN, he says the product documentation wasn't specific enough and a GUI would have simplified installation.

Forum, a Boston-based consulting firm, has been benefiting from a VPN for many years now. "We did VPN before it was called VPN," says Enno Becker, director of technology research and development.

During the evaluation phase, Forum focused on products it could pilot or see deployed in a production environment. Becker talked to ISPs, security firms and consultants before going to vendors.

Forum decided to use the VPN capability in Check Point's firewall because it was cost-effective. IT set up UUNET dial-up accounts for all the consulting firm's remote users. In order to use the firewall's VPN services, IT needed to install Check Point's SecuRemote VPN software module on 300 clients.

The VPN was reliable and scalable, but ongoing maintenance was a real chore. Until recently, Becker needed to change entries in the firewall and notify UUNET whenever he added or removed users.

Becker says that Check Point recently announced that its software is compatible via LDAP with Novell's NDS. This development lets him surpass the maintenance problem.

"We can disable a user on the spot without waiting for any processing delays," Becker says. "In a way this is the ultimate in VPNs, since our local network and our control is being securely extended worldwide through one of the worlds largest ISPs."

He advises fellow VPN adopters to keep it simple and look for a product that integrates with a firewall and directory. "Avoid thinking of it as a separate infrastructure," he says.

As Matanane points out, "Installing any new solution is always a learning experience. Understanding networks and protocols is a must." As you evaluate products, he suggests visiting a site that has implemented a VPN. "Don't take anything for granted unless you've seen it work yourself."

Bixler shares these VPN deployment tips:

Before you do anything, be sure you understand your requirements. There's nothing worse than a solution looking for a problem to fix.

Make sure you have adequate connectivity and that your users all have Internet access. Expecting employees to provide their own Internet connection can be problematic.

Document, document, document. The more you document your VPN, the easier it is to deploy and support it.

Don't neglect the back-end administration. If you're rolling out a solution to 1,000 users, keep in mind that someone needs to create and distribute 1,000 user IDs and passwords. If you go with a soft key/certificate solution, someone needs to manage those keys, and some products may require you to do this from the server console.

Build in redundancy. Consider getting a backup Internet connection or emergency dial-up service.

Get references. Don't let a VPN vendor talk you into being its first customer. If you need some consulting help, be sure to go with a reputable integrator.

Communicate with your end users and let them know what's going on.