I tested the Contivity 4600 and Contivity software version 4.0 (beta) in our Syracuse University Real-World Labs® and came away impressed with both.
The Contivity lines run on Intel hardware and VxWorks real-time operating systems and have suffered performance issues largely due to PCI bus limitations. The 4600 sports dual 800-MHz processors; 1 GB of memory; dual PCI buses; autosensing, hot-swappable power supplies; and a cryptographic accelerator. It also supports a wide array of interfaces: 10/100 Ethernet, T1 and T3, HSSI (High-Speed Serial Interface), V.21 and V.35. And the 4600 is certified as FIPS (Federal Information Processing Standard) 140-1 Level 2 (a cryptographic module certificate published by the National Institute of Standards and Technology [NIST]) as long as the optional kit is purchased and installed and the cryptographic accelerator is not installed.
High Availability Keeps You Connected
High availability and fail-over are key requirements for any mission-critical component. Contivity software version 4.0 comes through, offering failover and high availability for both LAN-to-LAN and remote-user VPN connections. High-availability configurations are stateless, which means the VPN connections have to reconnect to a secondary Contivity when a device fails. The secondary Contivity can already be in operation with its own VPNs. The secondary Contivity will aggregate its own VPN with the VPNs that failed over.
Client failover is global to any Contivity switch. All remote clients receive the same failover configurations when they connect. Up to three different Contivities can be allocated in order of preference for failover. All I had to do to make it happen was enter the IP addresses of the alternative Contivities.
I also had to make sure that I had the same user names and passwords on each Contivity; otherwise, the logon would fail. Because I was using the internal user database, I had to touch each Contivity, but if I had used an external server such as RADIUS, I wouldn't have been required to take that step. I connected to the primary Contivity and confirmed that I had a connection. Then I disabled the public interface on the primary Contivity. Using heartbeats, the client detected that the VPN connection had failed and initiated a new connection to the secondary Contivity.
If you don't let users store their passwords on the VPN client locally, they will have to enter their passwords when the VPN client makes a connection to a backup Contivity. If a user attempts a connection to a failed Contivity, the VPN client will try each backup Contivity in order. Also note that the client will use only the failover configuration from the primary Contivity.
I configured the primary Contivity switch with one backup and the secondary Contivity switch with a different backup. I made a connection to the primary Contivity, then disabled the interface. The client reconnected to the secondary Contivity.
When I disabled that Contivity, the client simply disconnected. Additionally, if the client fails over to a secondary Contivity, it will not reconnect automatically to the primary Contivity if the primary comes back online.
LAN-to-LAN (branch office) failover uses advanced routing protocols to provide high availability (see "Redundant Routing Saves the Day," above). OSPF (Open Shortest Path First) is used within the VPN tunnels to provide redundant paths to networks. On the private interfaces, VRRP (Virtual Router Redundancy Protocol) is used in failover between two Contivities. First, I created an OSPF area to define the peer groups that will participate in a routed network through the VPN. OSPF peers advertise the networks for which they provide connectivity. Next I defined two paths to the "10" network on the branch-office Contivity 600--one to the 4600 with a lesser cost and one to a Contivity 2600 with a higher cost.
Once the configuration was set, the routing information was distributed to each Contivity, which then built separate routing tables. All traffic flowing from the Contivity 600 to the 10 network would pass to the 4600. If the Contivity 4600 failed, the 600 would pass traffic to the 2600 instead.
Now that I had built redundant paths within the VPN, I wanted to provide failover for the 10 network on the private side. Using VRRP between the Contivity 4600 and 2600, I configured the 4600 as the primary Contivity switch and the 2600 as a secondary. VRRP runs a heartbeat from the primary to the secondary switch. In the event of a failure on the private interface, the Contivity 2600 would take over routing responsibilities from the 4600.
Dealing With Pesky NAT
NAT (network address translation) traversal has been a problem for IPsec (IP security) VPNs ever since VPNs were first deployed. The Contivity software version 4.0 has automatic NAT traversal discovery (based on a current IETF Network Working Group draft) and configuration that should assist in SOHO (small office/ home office) installation support. The Contivity and the client autodiscover NAT when the client sends a hash of the client's IP address and UDP (User Datagram Protocol) source port number to the Contivity during IKE (Internet Key Exchange) negotiation. The Contivity hashes the IP address and UDP source port number it is using to communicate with the client.
If there is a mismatch between the client's hash and the Contivity's hash, you can be sure NAT is being used at some point. If NAT is detected, the client and Contivity will encapsulate IPsec traffic within UDP using a predetermined destination port. I tested this using a Cisco Systems 4700 router and setting up NAPT (network address port translation) between the client and the Contivity. I also had to enable NAT detection in the Contivity. When I initiated the session, NAT was discovered, and the traffic was encapsulated properly.
Contivity software version 4.0 offers further enhancements that I did not test, such as support for ECC (Elliptic Curve Cryptography), designed to support hand-held devices; a Cisco IOS-like Nortel Network Command Line Interface (NNCLI), which offers access to some critical configuration options not available in the terminal menu system; and support for external LDAP-enabled directories. The 4600 looks as though it fits into organizations needing to support large numbers of remote users, and version 4.0 of the software offers networks of any size a host of useful features.
Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs® and covers all security-related topics. Prior to joining Network Computing, Mike worked as an independent consultant in central New York. Send your comments on this article to him at mfratto@nwc.com.
