eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As enterprises expand their corporate networks to new sites, remote workers and partners, they are increasingly deploying virtual private networks on IP technology. And as they do, they are faced with new challenges: In order to deliver quality of service, flexibility and scalability while providing a wide variety of remote access, for example, many organizations have had to deploy and manage multiple types of VPNs.
|
In an e-mail roundtable, eWeek Labs Senior Writer Anne Chen asked members of eWeeks Corporate Partner Advisory Board, as well as industry expert Dave Kosiur, for their takes on the VPN market and the deployment and management strategies theyve developed.
eWeek: What were the key challenges you encountered when deploying VPN products?
Benincasa: When we began the deployment, it took a lot of planning to synchronize existing frame [relay] sites with the VPN sites.
Training of personnel worldwide to support the deployment was important. Personnel needed to understand the firewall/VPN software, as well as the security criteria. When we made the change, we moved from a supplier-managed frame [relay] to an in-house-managed VPN.
Once the VPN was installed, we had to ensure that users did not see any reduction in responsiveness or reliability.
Otherwise, the implementation would have been considered a failure, no matter how well it actually went.
Wilson: Desktop maintenance was one issue. Performing desktop maintenance on VPN- connected clients can be a real challenge, and some management applications make it more difficult than others.
Knouse: We deployed a VPN in our retail stores, and the key challenge was the planning and coordination effort. The technical implementation was not difficult—it was making sure that the telecom engineer, the local phone company, the VPN vendor, store manager or shopping center representative, etc., were able to show up at the same time so that the expenses of installation in terms of time on-site and travel expenses were kept to a minimum.
eWeek: What are the top things IT managers should consider when planning a VPN project?
Benincasa: We wanted to minimize latency and multisupplier issues, such as “The problem is not my network,” when selecting suppliers to provide the T-1/DSL lines. It was important to try to use one supplier for the best performance. Standardization of the firewall/VPN software was important in order to be able to effectively support the VPN. This would make it easier to manage, trouble-shoot and train for.
Quality and reliability of the software and the T-1 line/backbone were some of the most critical criteria. We wanted to make sure that business needs were being met or exceeded based on our frame network performance. Cost was also an important factor. We could not afford to increase costs for a VPN while, at the same time, trying to improve performance over our frame network.
Kosiur: IT managers should look at the type of security they need for their traffic. They should also look at the reliability of the VPN. If youre going to make this your business- critical LAN/WAN networking technology, you need to make sure theres failover on the devices. As customers become more interested in leveraging VPNs for services like voice- and videoconferencing, they will become increasingly concerned with performance.
Another important point is to look at what kind of cost savings youll actually achieve. A lot of companies decide they can save money by using VPNs but dont factor in additional costs like rolling out clients with secure IDs. You need to be cognizant of the long-term management costs.
Finally, there needs to be a transparency of the VPN. Softwares gotten smarter, so the user doesnt have to be as involved in running a VPN. But its still a product-by-product advance. IT managers looking to deploy VPNs have to carefully figure out what the pain threshold [is] for themselves and their users.
Page Two
eWeek: Many customers believe single-vendor implementations of VPN technologies are necessary to avoid interoperability problems. Did you feel confined to a single vendor when developing your VPN project?
Knouse: We did not look at it as confinement. As a matter of fact, we sought out a single-vendor solution so that we had one point of contact in the form of the VPN vendors project manager for our implementation.
We had several different countries and 100 locations to deal with, and it was important for us to have a focused, dedicated resource provided by one vendor.
Since our in-house network staff is very small, from an ongoing network management perspective, we felt the single-vendor approach would work best for us.
Benincasa: We knew that once our VPN was in place, that we might have to connect via a VPN to some of our key customers and suppliers that may have different products. Anticipating this requirement, we made sure that the firewall/VPN product we purchased was OPSEC [Open Platform for Security]-compliant.
For our own VPN, we had always wanted to standardize the software as much as possible for support, training and cost issues. Using one supplier for the backbone was important, but, where needed, we could deviate.
We felt a little confined knowing that standards are not always followed, but most of the confinement was based on objectives that we had set for ourselves. Since then, we have connected successfully to partners using other firewall and VPN products.
eWeek: What steps should IT managers take to ensure quality of service?
Kosiur: If youre trying to track the traffic patterns of end users, its always good to do your own monitoring. Checking the bandwidth and traffic performance is your own way of verifying what the service provider is telling you. You cant always ask the gatekeeper to tell you the gate is open. Make sure your service provider is providing the type of performance theyve promised to you in their service-level agreements.
eWeek: What steps have you taken to maintain the scalability and flexibility of the VPN infrastructure?
Wilson: There is also a definite trend toward testing and certifying generic operating-system-provided VPN clients, such as those included in Windows XP Professional and Pocket PC 2003. The intent would be to test and certify them as alternatives to the vendor-specific VPN clients most of us have used since the beginning of our VPN experiences.
Benincasa: We use standard server hardware and can always increase processor capability or add accelerator cards. If we had to scale to more than one unit at a location, we could load balance via the VPN software. We can always increase the VPN licensing at any time to handle an increase in users as well.
Since we manage our own VPNs and our own equipment, we can quickly bring new sites online or deactivate sites if needed and redeploy the equipment. Changes can be made quickly to policies to adapt to changing conditions. As a result, we feel comfortable that we can scale or adapt our VPN as needed to meet current and future plans.
The only area of concern would be over personnel to support [the VPN] and larger-than-anticipated growth. In such a situation, we would have to make sure we have additional trained resources to handle the management of the VPN.
eWeek: What about running other services over the VPN such as voice?
Kosiur: Enterprises are starting to look at running VOIP [voice-over-IP] traffic over VPNs more seriously. There are two aspects of looking at it. One is to get through the toll bypass and connect to sites through tunnels. Other clients would like to use DSL lines through VPNs and still have a voice line that goes back to the office. Many enterprises are still concerned with providing a data VPN for their teleworkers. If anything, the first stages of VOIP on VPNs will be between sites.
Senior Writer Anne Chen can be reached at anne_chen@ziffdavis.com.