Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

  F E A T U R E

IPSec VPNs: Take Us To the Pilot

September 20, 1999
TimeStep Permit/Gate 7520
TimeStep's Permit/Gate 7520 sits at the top of the Permit product family, with support for 100-MB networks. If you're familiar with other Permit products, you should feel right at home using this VPN. TimeStep made some modifications to the software on the 7520 and ICSA certification is in progress. That shouldn't deter you; TimeStep is active within the IETF and in the IPSec community that's moving the IPSec standards forward and helping to ensure interoperability. Besides supporting Fast Ethernet, the 7520 supports bridge-emulation mode--it can sit transparently. Like the VSU-1100, it only uses one IP address, unlike the Ravlin 7100 and cIPro-VPN, both of which require two. TimeStep's VPN configuration is fairly straightforward, and in some cases is more granular that VPNet's, but it's also more complex. In terms of performance, the Permit came in last with only 45 MBps. That's still pretty fast throughput, but it's nowhere near the numbers rung up by either RedCreek's Ravlin 7100 or VPNet's VSU-1100.

Permit gates use configuration files to determine how VPNs are constructed. This is a multistep process. Each gate has a Red Security Policy Table that defines the subnets and hosts on the red (protected) network. The gates are extremely flexible, offering wide support for a number of syntax rules to specify protected addresses. For example, traditional subnetting (similar to VPNet), such as 192.168.201.0/255.255.255.0, wild cards, such as 192.168.201.*, and address ranges, such as 192.168.201.

[1-254] all denote the same configuration. We learned early on that we had to be careful building the Red Security Policy table because it acts like a routing table. At one point, we forgot to add an entry allowing management to pass through. As a result, we found ourselves cut off from the rest of the network.

Once all the Red Security Policy tables were built, we selected the devices in our VPN and used the Secure Map Wizard to create the VPN policy definitions to be sent to each gate. The Secure Map is a text file that defines the protected networks in a VPN, the gates they are associated with, and whether they are tunneled or passed in the clear. Because this is a text file, you can edit it by hand, making any modification that's necessary. In a large map, you may want to use the Name parameter to give a descriptive name to an entry, such as "Accounting Department." Unfortunately, any entries you enter into the map by hand, such as the descriptive name, will be erased if you create a new one. Once the map was built, we sent it to all the gates from Permit/Config.

A Security Level Map contains entries specifying what combinations of IPSec protocols and cryptographic algorithms are acceptable on the gate. A default Security Level Map contains the most common combinations of groups and are associated with a Security Level Name. This map is a text file that can be edited if custom configurations are required. When a peer gate tries to negotiate an IPSec tunnel, the gates only will negotiate mutually acceptable security proposals.

The order of entries in the Security Level Map is important. Two gates will negotiate the first set of mutually acceptable protocols, not the most secure set of protocols. If two gates can negotiate either DES or 3-DES, but DES is listed first, DES will be negotiated. Thus, in cases where you must negotiate DES internationally and 3-DES nationwide, you must edit the Security Level Map to set the proper order.

Both the Secure Map and the Security Level Map are well documented, and the combination of these two files offers an extremely scalable architecture for building common VPNs. For example, two gates in the United States can accept either DES or 3-DES encryption while a gate in France may only support DES. By applying the appropriate Security Level Maps on each gateway, the two gates in the United States will negotiate a VPN using 3-DES while a VPN with France will negotiate DES without having to define individual tunnels on each gate.

The 7520 currently supports only the Entrust PKI (versions 3 and 4), but TimeStep expects to have generic X.509 support by the end of September. The Entrust Support is rock solid, however. The Permit institutes an Entrust client, and we easily certified our 7520 with Entrust online. However, the gates will not work with Entrust 4.0a. We had to upgrade our Entrust PKI to 4.0c. The Permit/Director, TimeStep's policy management system, also leverages Entrust's Directory by pushing group attribute certificates into the directory. The Group attributes define which gates can create a VPN together and offers a better control system than the process of manually creating and editing Secure Map for every gate.

The Permit/Client is extremely configurable and easy to use, though it may appear daunting to novice users and administrators. Fortunately, the client uses the same Security Level Map and Secure Map that the gates use, so no separate configuration files are necessary. After installing the client, we were up and running with a VPN within minutes. TimeStep also provides additional methods for locking down the client besides either user access or no access. Through a user interface file, administrators can lock specific portions of the client from modification.

Permit/Gate 7520, $10,995, TimeStep Corp., (880) 383-8211, (613) 599-3610; fax (613) 599-3617. www.timestep.com or info@timestep.com



PAGE: 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 I 10 I NEXT PAGE
 

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers