Virtual Private Networks, Part 6: VPN ISPs

We’re still on the subject of Virtual Private Networks. After looking at the BorderManager package from Novell in the last column, it’s time to switch attention to Internet service providers that can offer you VPN solutions. (You might recall that you can only really do VPNs two ways: yourself with packages like BorderManager and Nortel Network’s Contivity, or by outsourcing the VPN system in much the same way you would your standard Internet connections.) Using an ISP to provide VPNs makes a lot of sense if you are not sure how big your VPN commitment will be, if you don’t want to lay out big bucks for VPN hardware and software, or if you don’t want to manage the system yourself.

The primary problem with an outsourced VPN solution is that you rely on someone else to provide a potentially critical service. On the plus side, you are probably already relying on an ISP for your Internet connectivity, so why not piggyback VPN on top of it? The key to choosing a good ISP with VPN capabilities is to read the Service Level Agreement (SLA) very carefully, as the SLA is where the terms and conditions of your contract are spelled out. The SLA will focus on a few things, but the most important to you are the costs and the service guarantees. Make sure the ISP can support the geographic regions you are interested in providing service to. Some can’t work nationwide, let alone internationally. You may also want to check out the ability to expand or contract the amount of VPN support you get without major penalty, as well. Find out if the ISP supplies things like the routers you need, too, or whether that’s your responsibility.

Many ISPs will offer VPN planning services, while some leave it up to you to tell them what you want. There’s also an issue with the protocols involved with an ISP’s VPN solution. As we discussed in a previous column, VPNs can be implemented through PPTP, IPSec, M2TP and other protocols. You have to be sure your ISP can handle the protocols you are planning to deploy on the machines involved in the VPN. Don’t assume all ISPs are equally knowledgeable about, and able to support, all the standard protocols, because they are not and can’t. Capabilities vary widely. In preparing this column I called a half dozen major ISPs only to find out some had only very limited support for VPNs, and most restricted VPN support to particular protocols. Even talking to sales and support staff can be a problem, as easily half the people I spoke to knew little or nothing about VPNs other than what they could read off their sign-up sheets.

While talking to an ISP remember to check on the security systems they use, as well. This covers everything from their network operations center (NOC) to the algorithms and authentication methods they support as part of their VPN solutions. Again, a number of the ISPs I talked to could provide only rudimentary authentication and encryption support, on the whole unsuitable for any serious VPN installation.

The SLA’s main focus (other than the bucks you need to spend each month) is the level of service you can expect. Network availability (also called uptime) is measured over your entire network by calculating how much time the network at any connected location is unavailable, divided by the total time and number of sites. The numbers can be misleading if you are not careful. An uptime guarantee of 99% sounds good, but what it can mean is one connection out of 100 can be down all the time. If that one connection is your VPN server, you’re out of luck for connecting. A more realistic number in an SLA is 99.5% uptime, but that still means that if you have 10 nodes, a day and a half of downtime is allowed every 30 days. That’s not a good number. There are usually a whole bunch of loopholes in an availability clause in an SLA. Check to see what the ISP is trying to get away from. Also, ask for references to check the ISP’s statements!

The other two parts of an SLA to concern yourself with are the effective throughput and delay statements. Effective throughput is a measure of how much real data (not potential or theoretical data) can be handled by the connections over a given period of time, usually seconds. Effective throughput statements usually have caveats too, such as the numbers apply only a certain times (what good is fast throughput at 2:30AM if you can’t use a fraction of it during the day when you need it?). Delays have to do with how mong a connection and data take to pass, and again is usually handled with lots of caveats. Check the clauses carefully.

Some ISPs will allow you to negotiate clauses in their SLA, some have a "take it or leave it" attitude. If you can’t get the level of performance and uptime that you need, as well as ability to expand and contract the number of VPN connections you have over time, all at a fair price, look elsewhere. There are many companies in Canada and the US looking for VPN customers, and in the next column we’ll look at some of the bigger ones.