Network Computingwww.networkcomputing.com

Cisco sent me two VPN 3002s, which I installed on two different subnets, and a VPN 3060 Concentrator, which I placed on a third subnet and positioned as the central network. When I set up the first VPN 3002, I was impressed by how much easier it is to configure than a typical LAN-to-LAN VPN. After creating the client configurations in the first VPN 3002 management console, I copied the configurations to the other client I was deploying on a different remote network--a task that is impossible to perform in a LAN-to-LAN VPN. This saved me an enormous amount of time: Within 30 minutes I was able to access the concentrator from either client over my VPN.

Getting Down To Business

After the initial hardware installation, I cabled my workstation to the VPN 3002 and connected to its default IP address using a Web browser. I also had the option of using the console terminal, but the browser interface is easier to navigate. To configure the VPN 3002, you can enter the quick setup mode and accept the default values for configuration or manually configure the VPN 3002 to fit your needs.

In the quick setup, you'll need to define just the IP address pool that private-connection IP addresses will be pulled from, the IP address for the private side of the VPN 3002 and the subnet. The VPN 3002 is not configured for client DHCP by default, but can be enabled by clicking on a check box when you're defining the subnet mask of the remote network's IP addresses.

I did not have to do much along the lines of configuration for the VPN 3002: I set policies on user management manually, statically configured a management IP address, and defined which hashing algorithms to use for authentication and encryption on the VPN 3060 Concentrator. This brings up a very handy feature: Users will not have to configure the VPN 3002 outside of the basic information in the quick setup. It is configured remotely, meaning that when the VPN 3002 connects to the 3060 Concentrator, it downloads the newest policies and applies them just like a software client does.

Cisco VPN 3002 Hardware Client Manager (screen view) Click here to enlarge

When configuring the VPN 3002, I had to decide whether to set it up in client mode or network-extension mode. The client mode shows one IP address -- that of the hardware client -- to the world for the entire network, which means I could use nonroutable IP addresses behind the VPN 3002. This is problematic if you plan to manage individual hosts behind the VPN 3002 from the central network as well as the VPN client because you can't connect to the remote hosts. The network-extension mode lets each host IP address be advertised to the world.

An impressive security feature of the VPN 3002 is that it allows split tunneling of network traffic in both client and network-extension modes. When configuring the VPN, I specified that all the traffic destined for the central network must be forwarded over the VPN. All other traffic passes through the VPN 3002 to the Internet in the clear, increasing response time for Internet applications. With split tunneling, all traffic is disabled, regardless of destination, and must travel over the VPN. This increases the load on the central concentrator.

The VPN 3002 made it look as if my remote hosts were accessing the network locally when they actually were communicating over the private connection. All I needed to do was configure the VPN client to pull local addresses from a pool of designated IP addresses and the VPN client correlated them with a remote host. As a result, the VPN 3002 makes decisions about whether to send traffic over a public or private connection based on the destination address of the packets. All packets destined for the defined network are sent over the private connection using IKE (Internet Key Exchange) for connection management and IPsec (IP security) for transmission.

IPsec Support

I was impressed by the VPN 3002's ability to support IPsec through NAT (network address translation) mode, though this feature must be set on the VPN 3060 Concentrator for it to be put into use on the VPN 3002.

Common NAT implementations translate the IP address of packets based on Layer 4 information, such as TCP/UDP port numbers. Because IPsec encapsulates Layer 4 data end to end, IPsec communication is not possible. To deal with this, the VPN 3002 and its corresponding concentrator communicate with each other by adding another layer of encapsulation. Before an IPsec packet is sent out by the VPN 3002, it is encapsulated into a UDP packet and assigned a destination port, by default Port 10000 or whatever port is configured on the concentrator. The resulting UDP packet then can pass through NAT unhindered. When the IP packet arrives at its destination, the VPN concentrator strips off the IP and UDP headers, leaving an IPsec packet to process.

The graphical status-checking tool in the management console for monitoring the VPN client is quite useful. Enabled with point-and-click navigation, this tool (see screen, above) lets you check the performance of the VPN 3002 without hassle.

From here, I could use all the detailed logging and debugging tools available in the concentrator line.

Because the VPN 3002 doesn't support DDNS (dynamic DNS), you will have to look up the user name associated with the VPN 3002 on your concentrator to manage or troubleshoot it remotely.

Price-Performance

The Cisco VPN 3002 stands up well in price comparisons to other hardware VPN solutions, especially when you consider that the design of the device lets companies manage each remote site from a central office: In other words, all the benefits of a LAN-to-LAN VPN without the headache. The VPN 3002 shows the competition that a hardware client solution may be just what network-based enterprises are looking for to support remote offices. Support for other Cisco routers -- such as the 7100, 7200 and 5000 series -- should be available by year's end.