The best way to build a VPN
Dedicated encryption devices are the best choice overall for setting up virtual private nets over the Internet.
By Joel Snyder
Virtual private networks (VPN) are an increasingly popular option for communicating with employees or business partners over the Internet. The hard part is figuring out the best way to build one, given you've got at least four viable options.
What most vendors call a VPN amounts to encrypted TCP/IP links between LANs. You can fashion one using a software-only product, with software installed on a router or firewall, or with dedicated encryption hardware. We set out to discover which method works best for connecting two or more LANs.
After testing 11 products, we concluded that dedicated hardware encryptors are easiest to configure, manage and control. Unless you've got a lot of time, a small network, a tiny budget and limited reliability requirements, hardware tunnels are your best bet for LAN-to-LAN encryption. But don't worry: All the products behaved as expected, and none slipped clear traffic where it should have been encrypted, according to the protocol analyzer we used to check each one.
As for specific products, RedCreek Communications, Inc.'s Ravlin series stood out as a great all-purpose solution. With dedicated hardware, you get set-it-and- forget-it convenience as well as superior performance and the option to bring individual PCs scattered across the globe into the secure environment.
Radguard, Inc.'s cIPro systems let you construct a bulletproof installation where the highest level of security is required and link 100M bit/sec LANs with ease.
Budget-minded network managers will want to examine Microsoft Corp.'s Routing and Remote Access Service (RRAS), formerly code-named Steelhead. With zero cost for software and integration into the Windows NT 4.0 environment, RRAS brings low-cost encryption into small business environments.
Firewall-based tunnelsMost of the larger firewall vendors include a tunnel capability in their product. We picked two products, BorderWare Firewall Server from Secure Computing Corp. and Interceptor Firewall Appliance from Technologic, Inc., to represent the market.
The general idea behind firewall-based tunnels is that as long as you're funneling all your IP traffic through the firewall, you might as well encrypt there, too. This isn't as good an idea as it sounds.
We found little evidence that the firewall vendors have thought as much about IP tunneling as they have about building strong firewalls. The Java-based user interface and setup on Secure Computing's BorderWare was nothing short of frightening, and we had to battle poor documentation and convoluted procedures to use File Transfer Protocol (FTP) to transfer our keys around the network. We had hoped for better integration into the firewall and better distributed management.
Although Technologic's Interceptor was more reasonably priced and didn't force us to use FTP to move keys around, we still had to have a guru from the vendor dial in to our network to get the tunnels up. This, again, was the fault of poor documentation.
In both firewalls, we had the same misgivings about management style. The two end points of a tunnel inherently are part of a single management domain and require closely coordinated management and configuration. In both firewalls, tunnel configuration had to be manually repeated and coordinated at each end of the tunnel, an error-prone and cumbersome process.
But even if they had good documentation and a better user interface, firewall-based tunnels still wouldn't pay off because the performance of the firewalls was poor (see comparison graphic, page 58). BorderWare, running on a 200-MHz Pen-tium, clocked in as the slowest of any product we tested at 1.6M bit/sec. Interceptor, on a 166-MHz Pentium, was an uninspiring 2.2M bit/sec. In both cases, no other firewall activity, such as proxies or filters, was occurring.
Tunneling using your firewall is a workable solution only in limited circumstances involving small networks, small volumes of data and fairly static configurations. For everyone else, there are better solutions with lower total cost, better security and higher performance.
Router-based tunnelsIf firewalls are reasonably obvious places to put tunnels, then routers are blindingly so. Routers already have to look at and process every packet that leaves the LAN - why not give them the burden of encrypting as well?
We looked at Cisco Systems, Inc.'s IOS-based encryption option as an example of router-based tunneling and were impressed by its performance and flexibility. Cisco was the only vendor offering true VPN features other than IP encryption in their product RRAS. Those features include encapsulated AppleTalk, VINES IP, Connectionless Network Protocol, DECnet, IP and IPX. (Micro-soft's RRAS can encapsulate IPX as well as IP too.)
Cisco's encryption technology allows you to specify any stream of encapsulated or pure IP traffic for encrypted tunneling. The tunnel is built based on source and destination address, TCP/User Datagram Protocol (UDP) port numbers and IP Quality of Service indication.
For users of existing IOS-based routers, encryption can be added-in software for a license fee ranging from $500 to $7,000. For higher performance, Cisco's Encryption Service Adapter (ESA) board provides a coprocessor-based encryption engine that blew the socks off of everything else we tested.
Like all of Cisco's equipment, the management interface to VPN and encryption features is a command line.
We used the off-the-shelf documentation to configure and test tunnels and encryption in less than an hour.
Like all the high-end encryption devices, Cisco's ESA is both tamper-resistant and tamper-detecting. This means just removing the card from the router - even when powered off - turns on the "tamper'' light and requires management intervention. You either have to know a special password that was entered when the card was first initialized to reenable it or you have to be willing to clear the memory on the ESA board. If you're so bold as to remove the cover from the card, a dead-man switch initializes the memory for you. And if you get the cover off, you can't reverse-engineer the board - half of it is encased in epoxy.
This kind of security feature separates the devices that are serious security tunnels from those that are simply designed to keep your traffic over the Internet private.
Although router-based tunneling suffers from the same potential drawbacks as firewall-based tunneling, we're more enthusiastic about Cisco's implementation. Hardware encryption assist can alleviate performance problems, and the relatively low cost to add encryption and more powerful VPN features make it an attractive option.
Software tunnelsWe looked at three software tunnel systems. The first two, AltaVista Tunnel 97 from Digital Equipment Corp. and RRAS from Microsoft, run on standard operating systems such as Windows NT or Unix. The third, F-Secure Virtual Private Network (VPN) from Data Fellows, Inc., has its own embedded operating system.
Digital and Microsoft offerings are easy to evaluate and classify. They bring encrypted TCP/IP into the corporate LAN environment using just software. Digital's AltaVista Tunnel supports LAN-to-LAN and client-to-LAN tunnels on Windows NT, BSD/OS, FreeBSD, and Digital Unix systems. Microsoft's RRAS offers the same features but only runs on Windows NT 4.0. In both cases, the tunneling software requires the server to act as a TCP/IP router, receiving encrypted packets, decrypting them and retransmitting them to their final destination.
Both RRAS and AltaVista Tunnel are appealing to network managers with tight budgets. AltaVista Tunnel starts at $1,000, while Microsoft's RRAS is a free update to NT 4.0. But we found these software products only work well for small networks with lightly loaded servers. They're more appropriate for serving remote PC users (client-to-LAN) than remote LANs.
RRAS is more sophisticated than AltaVista Tunnel. It adds a midlevel router into Windows NT, complete with Routing Information Proto-col and Open Shortest Path First routing protocols and firewall-style traffic filtering rules.
Both of these products are excellent ways to get some experience with tunneling. They can run on existing servers and share resources with them. For low traffic levels and particularly for client-to-LAN connections, these are good starting points.
Data Fellows' F-Secure VPN has an unusual architecture. It consists of a Windows 95/NT-based graphical user interface (GUI), which is used to generate a network of encrypting tunnel systems. F-Secure VPN then builds boot diskettes for Intel Corp.-based systems that let them run as dedicated VPN systems.
This approach is a hybrid between software- and hardware-based tunnel systems. Unfortunately, it blends the disadvantages of both: The difficulty, expense and cost of being a hardware integrator are shoved onto the network manager. Meanwhile, the benefits of a software-based system, such as the ability to share resources and reduce costs, are missing. F-Secure VPN costs $2,500 and takes over the hardware as surely as any dedicated system.
F-Secure VPN may appeal mostly to network managers at educational institutions, where the availability of cheap labor and Data Fellows' 50% discount make the headaches of using this approach economical.
Hardware tunnelsWe looked at five hardware-based tunneling products: TimeStep Corp.'s Permit/Gate, Unified Access Communications' (UAC) PN7, Radguard's cIPro, RedCreek's Ravlin and Isolation Systems Ltd.'s InfoCrypt Enterprise.
In their simplest configurations, hardware tunnels operate as encrypting bridges and are typically placed just ahead of the network's routers. They fit into existing TCP/IP networks and intercept traffic as it heads off the net for encryption or filtering.
The beauty of this approach is that existing workstations and routers do not need to know anything about the tunnel or even be reconfigured to learn about it. The tunnel is, for all intents and purposes, invisible. In fact, the report from the protocol analyzer we placed between the tunnels was the only way we knew packets were being encrypted.
Small, unintrusive and generally managed from a single workstation, hardware-based tunnels were surprisingly easy to install and use. Compared with all other categories, these took the least amount of effort.
Management of hardware tunnels actually is two tasks: key management via a certificate authority (CA) and system management. All of the hardware tunnels except PN7 (whose management software won't run under Windows 95) can be managed with GUI software running under Windows 95 or NT. The system management software is used to handle basic tunnel security - which packets to encrypt - and how to handle errors. Hardware tunnel management can be centralized, which means one interface is used to manage all the tunnels, and the management software is responsible for updating the hardware to adhere to the centralized management policy.
CAs are a little different. For most of the tunnels, the CA runs as an application on Windows. Radguard's cIPro was a big exception: It had an additional piece of dedicated hardware that was responsible for key management. More impor- tant, each box has its own internal knowledge of the network keys, which means that even if the CA is dead, the network keeps running. This seems like an excellent idea. Having a vital network security application running on Windows doesn't give us the same warm fuzzy feeling that running the same application on dedicated hardware does.
Some hardware tunnels refuse to operate if the CA is unavailable. For example, the Permit Security Gateway won't come up from a system boot if its network management application can't be reached. Other tunnels had similar difficulties.
Hardware tunnels also differ in their flexibility. A good tunnel will allow you to choose which traffic to encrypt, which to send in the clear and which to simply block. The best in this area was Radguard's cIPro, which lets you pick source and destination addresses, ports and protocols as well as any set of bits in the IP packet as filtering criteria.
Although we tested tunnels in LAN-to-LAN configurations, some vendors also support client-to-LAN tunneling using the same hardware (see story, page 58). This is an obvious benefit if you're looking for a unified tunneling solution. Isolation Systems, RedCreek and Timestep all have Win-dows-based software available for client-to-LAN tunneling.
We also were pleased to see some vendors have multiple hardware tunnel offerings that let re-mote sites buy relatively less expensive hardware while the central site bulks up. Timestep, Red-Creek and Radguard all have less expensive dedicated hardware that interoperates with the high-end tunnels we tested. Radguard and Isolation Systems also offered 100M bit/sec LAN connections; Radguard even has a token-ring connection available.
Hardware tunnels, by and large, were not traffic bottlenecks, although none of them came close to Cisco's hardware-assisted encryption performance. In our tests, RedCreek's hardware, followed by Radguard's and Isolation Systems', topped the performance charts in their category. UAC's PN7 lagged behind, despite the 200-MHz Pentium in our test unit.
Bottom lineIn general, we liked hardware-based encryptors best. If you're serious about security, even in your own building, Radguard's cIPro is the way to go. Radguard is not just going through the motions; these folks really care about keeping things se-cure. For about half the price, though, RedCreek's systems outperform the cIPros and add client-to-LAN capabilities.
One special case worth mentioning: If you already have high-end Cisco routers, the ESA option is an excellent alternative. Speedy performance and the simplicity of dropping encryption into your existing infrastructure outbalance a difficult management interface.
How to Advertise | Copyright