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.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 firstname.lastname@example.org.
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.