Configuring VPNs for Remote Access

From a procedural perspective, it is easier to configure the Cisco VPN 3000 Concentrator Series for remote access using preshared keys. While the alternative method is to use the services of a Certificate Authority (CA), that method entails additional steps. Using preshared keys, the client only needs

to know the address of the VPN concentrator and the shared secret key.

While VPN configuration is relatively easy with preshared keys, this manual process does not scale well for large implementations. The VPN administrator must provide the password and implementation instructions to prospective users. This could be accomplished by preconfiguring client software on a floppy disk or CD-ROM, but even that process can be labor intensive in large implementations.

Once all of your users have successfully configured their remote systems with the current shared key, the process of changing passwords periodically, as every good security plan requires, would require notifying all users of the new password and providing modification instructions. You can imagine how it would be easy to forget about this important security consideration.

While scaling VPN implementations can be better handled by using CA support and digital certificates, preshared keys are easy to implement and can be used in many applications.

This chapter discusses the process of implementing Internet Protocol Security (IPSec) using preshared keys on the Cisco VPN 3000 Series Concentrators. The clever graphical user interface (GUI) makes the implementation process easy.

By taking the following steps, you can make better use of your time:

• Keep your notes and answers for all your work with this book in one place for easy reference.

• Take the “Do I Know This Already?” quiz, and write down your answers. Studies show retention is significantly increased through writing facts and concepts down, even if you never look at the information again.

For site-to-site VPN connections, peer devices must authenticate one another before IPSec communications can occur. In addition to requiring device authentication, remote access VPN connections require user authentication to make certain that the user is permitted to use the applications that are protected by the IPSec connection.

User authentication can be handled in a variety of ways. You can configure Remote Authentication Dial-In User Service (RADIUS), NT Domain, and Security Dynamics International (SDI) authentication on most Cisco devices, and the VPN 3000 Concentrators have the additional ability to authenticate users through an internal database.

If you want to use internal authentication, create a username and password for each user and assign the users to the group that is to be used for IPSec device authentication. Once the devices have established the IPSec tunnel, the user is prompted to enter a username and password to continue. Failure to authenticate causes the tunnel to drop. A similar login prompt is displayed if you are using RADIUS, NT Domain, or SDI authentication.

You can establish device authentication by using either preshared keys or digital certificates.

“Configuring Cisco VPN 3000 for Remote Access Using Digital Certificates.”) With preshared keys, the system administrator chooses the key and then shares that key with users or other system administrators. Combining a preshared key with some other metric establishes three different uses for preshared keys, as follows:

• Unique

• Group

• Wildcard

The following sections describe each type of preshared key in more detail.

When a preshared key is tied to a specific IP address, the combination makes the preshared key unique. Only the peer with the correct IP address can establish an IPSec session using this key.

Ideal for site-to-site VPNs where the identity of the peer devices is always known, unique preshared keys are not recommended for remote access VPNs. Unique preshared keys scale particularly poorly because each new user requires a new key and the administrative burden that entails.

While this type of preshared key is the most secure of the three types, it is not practical for remote access applications, where users are typically connecting through a commercial Internet service provider (ISP). Most users are not willing to pay for the luxury of a permanently assigned IP address from their ISP and are assigned an IP address from an available pool of addresses when they connect to the service. If you had a large installed base of VPN users, keeping up with these dynamically assigned IP addresses to provide this level of security would be a maintenance nightmare.

If you begin using unique preshared keys, at some point you can decide to just use the same password for discrete groups of users. If you decide to do that, and shed the association with the IP address, you have begun to use the next type of preshared key, the group preshared key.

A group-preshared key is simply a shared key that is associated with a specific group. In a VPN 3000 Concentrator configuration, the group can be the Base Group or any other group that you define.

A group-preshared key is well suited for remote access VPNs and is the method used by Cisco VPN 3000 Concentrators. It is good practice to use groups to establish Internet Key Exchange (IKE) and IPSec settings and to provide other capabilities that are unique to a specific set of users. If you choose to use the Cisco VPN 3000 Concentrator’s internal database for user authentication, you can assign your users to specific groups, making the process of managing preshared keys much easier.

The final type of preshared key classification is the wildcard-preshared key. This type of key does not have an IP address or group assigned to it and can be used by any device holding the key to establish an IPSec connection with your VPN concentrator. When you set up your concentrator to use wildcard preshared keys; every device connecting to the concentrator must also use preshared keys. If any device is compromised, you must change the key for all the devices in your network. This type of key is also open to man-in-the-middle attacks and should not be used for site-to-site applications.

VPN Concentrator Configuration

Three major categories of activities that should be performed on network devices are configuration, administration, and monitoring. The browser-based VPN 3000 Concentrator

Series Manager was designed with those functions in mind. The remainder of this chapter focuses on the configuration capabilities of the VPN concentrator.

Remote access VPNs can be established with minimal equipment. Most of your users connect through the Internet, so their infrastructure costs are minimal. While you should place the concentrator behind or in parallel with a firewall, you could establish a robust VPN network with just a border router and your concentrator.

Administration requirements for the Cisco VPN 3000 Concentrator Series are fairly standard. You could configure the concentrators completely from the CLI using either a directly connected console monitor or by Telnetting to the concentrator. However, the best option for configuring this series of concentrators is through the GUI that you access through a web browser.

Microsoft Internet Explorer version 4.0 or higher is the recommended browser to use, but you can also use Netscape Navigator/Communicator version 4.0 or higher. You must enable the use of JavaScript and cookies in the browser application in order for the Cisco VPN 3000

Concentrator Manager to work properly. Nothing needs to be installed on your workstation other than the browser software.

  • Initial configuration of the Cisco VPN 3000 Concentrator Series for remote access
  • Browser configuration of the Cisco VPN 3000 Concentrator Series
  • Configuring users and groups
  • Advanced configuration of the Cisco VPN 3000 Series Concentrator

In part two this technical article focuses on three major categories of activities that should be performed on network devices.

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada

Featured Download

Featured Story

How the CTO can Maintain Cloud Momentum Across the Enterprise

Embracing cloud is easy for some individuals. But embedding widespread cloud adoption at the enterprise level is...

Related Tech News

Get ITBusiness Delivered

Our experienced team of journalists brings you engaging content targeted to IT professionals and line-of-business executives delivered directly to your inbox.

Featured Tech Jobs