Because they eliminate the high costs associated with dedicated leased lines, VPNs are becoming increasingly popular as a means of providing secure communication between enterprises and branch offices, business partners and home offices.
In a single-vendor environment, VPN connections are very easy to accomplish. But problems arise when VPN tunnels are created with devices from multiple VPN vendors. In most cases, the enterprise IT staff cannot dictate which specific VPN products will be used by external organisations. The result is that network administrators often spend countless hours and too many resources trying to solve VPN interoperability problems.
VPNs use encryption to establish secure connections via the Internet between individual computers or within whole networks. Remote-access VPNs connect individual systems to a VPN gateway and are most often used by employees working from home or travelling who need access to the corporate network. Site-to-site VPNs are most often used by branch offices or corporate partners to securely connect their networks to the corporate network for access to files and resources.
VPN standards do exist, but they cannot overcome all the interoperability issues. The IPSec VPN standard was adopted several years ago and has been implemented in most commercial VPN products. But to set their products apart, many VPN vendors have added proprietary functionality that does not work in multi-vendor environments and can make configuration more difficult.
Because the IPSec standard does not include support for user authentication, for example, vendors typically add proprietary extensions to improve user authentication for remote-access connections. Vendors also often add extensions to provide support for NAT (network address translation).
To achieve interoperability in multi-vendor environments, users should avoid the use of VPN functions that fall outside the IPSec standard. Interoperability will also require a solid understanding of IPSec. Sticking to a basic VPN connection will allow a company to create a secure connection among VPN products from different vendors, but preclude the use of all of the offered bells and whistles.
Layer two tunnelling
Microsoft threw an additional spanner in the works when it released Windows 2000 with built-in VPN support, including a VPN client. Microsoft's VPN implementation supports only L2TP (layer two tunnelling protocol)/IPSec. Although L2TP is an open standard, it is not widely deployed. As a result, many VPN vendors scrambled to provide support for Microsoft's implementation.
L2TP helps improve user authentication for VPN remote access, something not supported in the current IPSec standard. With IPSec, the device is authenticated, not the user. L2TP provides user-level authentication in addition to the IKE (Internet key exchange) authentication scheme. Although L2TP provides support for protocols other than IP and user authentication, it makes configuration considerably harder and adds at least 10 per cent more processing overhead.
User authentication is important because it ensures that the person using the system to create the VPN tunnel is an authorised user. Unless user authentication is required, the VPN gateway only requires authorisation of the system requesting the tunnel. Consequently, only user authentication can prevent hackers with stolen laptops or hackers who have compromised an employee's home system from connecting to the corporate network through the VPN.
Because there is not yet a standard for the protection of L2TP traffic with IPSec, each third-party VPN vendor has developed its own way of interoperating with Windows 2000. This has led to a rash of interoperability problems. When they alter their clients to work with Windows 2000, vendors often make the clients incompatible with other VPN products.
VPN interoperability is difficult to achieve, but it's getting easier. Vendors are beginning to realise that interoperability benefits everyone and are taking some of the necessary steps to make it a reality. Additionally, the Internet Engineering Task Force (IETF) is working on developing formal standards for L2TP/IPsec user authentication (www.ietf.org/ids.by.wg/ipsec.html) and remote access (www.ietf.org/ids.by. wg/ipsra.html). No immediate solutions exist, but several are just over the horizon.
Interoperability in action
With so many issues affecting VPN interoperability, we wanted to put three leading VPN products to the test:
Cisco Systems' 3000 VPN Concentrator (formerly from Altiga), NetScreen Technologies' 100-running ScreenOS 2.0, and the Windows 2000 Server serving as a VPN gateway. Using the three products in three different locations, we tried to create three site-to-site VPN tunnels for encrypted communication via the Internet.
For the test, we configured each site to use 3DES (triple data encryption standard) for data encryption, SHA-1 for authentication, preshared keys, and ESP headers in an effort to achieve authenticity, integrity and confidentiality. We chose this set-up because it represented average VPN configuration. We chose a set-up that promised to be simple and straightforward to configure, but that also allowed any device to initiate a tunnel connection while providing flexible support for both remote sites and mobile workers.
Connectivity between the NetScreen and Cisco products was easy to establish and took only a few minutes to configure. Each device had a Web-based administration GUI that allowed us to configure IPSec VPN tunnels with ease. First, we configured the NetScreen-100 by defining the remote gateway (the Cisco Concentrator) and the preshared key. We then configured the IKE negotiation and finished the NetScreen configuration by creating a firewall policy rule allowing the VPN connection to be made.
We then performed the same steps on the Cisco Concentrator. Its administration interface was a little different, but the basic procedures were the same. The Web-based GUI for each device was easy to understand, intuitive and flexible. And both NetScreen and Cisco included predefined IKE negotiation schemes, so IKE configuration was as easy as selecting a configuration choice from a drop-down menu.
NetScreen and Cisco excel at interoperability because their VPN configuration options are very flexible, earning them both an Excellent rating. Users have complete control when defining all parameters of the IKE negotiation process. Predefined configurations make the process simple, but you also have the ability to define any configuration you want by adding just a few steps to the process of creating a VPN tunnel.
But problems arose when we tried to establish tunnels with the Windows 2000 server. Both Cisco and NetScreen provide instructions for configuring their devices and Windows 2000 for connectivity, but we could not get either option to work. Plus, Cisco's documentation only shows how to use the built-in Windows 2000 client. It does not provide any information on site-to-site configuration.
By default, Windows 2000 requires certificates for authentication instead of preshared keys. Although certificates do provide a higher level of security, they have interoperability issues of their own that we did not want to encounter during our testing. You can enable preshared key authentication on Windows 2000 by making some registry changes, but it's not a task for the faint of heart.
Configuring Windows 2000 IPSec tunneling is neither straightforward nor intuitive. It took extra time to learn how to create the necessary IPSec policies, filter lists, and filter actions.
We first used the Microsoft Management Console (MMC) IPSec policy snap-in to create an IPSec policy for tunnel creation. This is easy enough if you choose all the default settings. But if you have to change anything, such as the encryption or hash algorithm, you are sent into an endless mase of dialog boxes.
Next, we added filter lists to the IPSec policy to identify which traffic it should be applied to. (This was the most confusing step, but Microsoft provides an excellent guide, "How to configure IPSec tunneling in Windows 2000," at support.microsoft.com/support/kb/articles/q252/7/35.asp.
Finally, we assigned our new IPSec policy to our Windows 2000 gateway but failed to establish connectivity between the NetScreen and the Cisco products. We tried to pinpoint our connection problems using support tools (netdiag, ipsecmon) and auditing policies provided by Microsoft, but to no avail. We even set up a second Windows 2000 gateway to make sure we configured all of the policies and filters correctly. We had no problems establishing an IPsec VPN connection with the second Windows 2000 server, but we could not establish connectivity between Windows 2000 and the NetScreen and Cisco devices.
Windows 2000 is a great VPN product if you will only have to connect with other Windows 2000 servers. Any interaction with another vendor will cause major headaches.
We spent a good 40 hours on this project without vendor help and devoted most of the time to Windows 2000 configuration. We were never able to pinpoint the reason for our failure to establish a VPN tunnel between Windows 2000 and the NetScreen-100 or Cisco 3000 VPN Concentrator. Our best guess is that the culprit was an improperly configured Windows 2000 Server. Making sure all the IPSec/IKE parameters were correct was not easy. Based on our tests, Microsoft earned a Poor rating in VPN interoperability.
Although it may be possible to establish VPNs between Windows 2000 and the NetScreen and Cisco products (please let us know if you have been successful), its difficulty does not make this set-up ideal for any organisation. A VPN tunnel should be easy to create; administrators should spend their time and energy developing the processes and procedures surrounding the creation, accessibility, and availability of the tunnel rather than troubleshooting interoperability problems.