Planning for IPSec Site-to-Site Access

With IPSec remote access, mobile workers and single client locations can connect to a specific VPN using a software client by referring to a fully qualified domain name or FQDN that is associated with a single or set of IPSec PEs serving that specific VPN. Remote access requires a software bundle (or client) to communicate with the edge of the VPN.

The Cisco network-based IPSec VPN solution Release 1.5 uses RADIUS to support IPSec remote access to network-based VPNs and to provide the information necessary to establish the IKE connection as well as the session with the remote access user.

The infrastructure supporting IPSec remote access is allocated to a distinct set of resources called the IPSec service module. Each IPSec service module supports a distinct set of VPNs and their associated users. For new customers, you must invoke assignment logic to associate customers with a specific IPSec service module.

Assignments are followed by reduction in inventory for a given IPSec service module, configuration of customer specific VRF, establishment of RADIUS infrastructure, and finally documentation of VPN topology/engineering information.

Required Information for Implementing Remote Access

The following information is necessary to successfully implement IPSec remote access for the Cisco network-based IPSec VPN solution Release 1.5:

Forecast of subscribers in month 0, 6, 12, and 24.
Percentage of subscribers active at peak.
The average IPSec tunnel speed (initially, the speeds will be unconstrained).
Number of routes in the customer's network (information should encompass all routes for a given customer network).

Consider this information algorithmically (against IPSec server module capacity) to assign the customer to the appropriate service module and to reduce the capacity of the selected service module by the appropriate amount of resources the customer is expected to consume.

VPN Topology

Remote access users must identify the desired VPN topology type. In the case of hub and spoke, the remote access user must identify the sites designated as a hub.

AAA Management

Managed AAA

In a managed AAA configuration, a service provider hosts a RADIUS system that administers user information specific to a remote access user. The remote access user must designate one or more administrators that will be responsible for user administration. The remote access user must provide contact information and initial user-id/password for each administrator. After administrators are configured, the remote access user can add, delete, modify, and view users without the intervention of service provider.

Proxy AAA

The service provider performs authorization while the remote access user controls user authentication. Proxy AAA is the only configuration that supports two-factor authentication (also called token card). In the case where a remote access user is managing his own AAA system, the remote access user must identify one or more IP addresses associated with the remote access user's AAA system. In addition to IP addresses:

A shared secret must be configured on both ends of the proxy (service provider and remote access user).
The shared secret must be communicated.
The shared secret should be a well-formed password.

Per-VRF AAA

Using the Per VRF AAA feature, Internet Service Providers (ISPs) can partition authentication, authorization, and accounting (AAA) services based on Virtual Route Forwarding (VRF). This feature permits the Virtual Home Gateway (VHG) to communicate directly with the customer's RADIUS server, which is associated with the customer's Virtual Private Network (VPN), without having to go through a RADIUS proxy. Thus, ISPs can scale their VPN offerings more efficiently because they do not need to proxy AAA to provide their customers with the flexibility they demand.

Preshared Key

A preshared key is used for the client PE IKE security association (SA). There is one preshared key for each group name. The group name is the IKE ID that binds it to the preshared key. The preshared key is loaded into RADIUS for device authentication and integrated with software clients. Software client distribution must be addressed along with key generation.

We recommend that client software along with patches/upgrades for customer be distributed from a web page maintained by the service provider. After preshared key assignment, the software for each remote access user has the preshared key bundled with the software when the software is downloaded. This process must be validated by security.

User Password Options

Authentication of users can be implemented using simple user passwords or RSA SecurID based two-factor authentication passwords. Remote access users that require two-factor authentication passwords must use Proxy AAA.

Address Pools

The remote access user must provide addresses to use as address pools for dynamic assignment to clients. The remote access user must also provide address space for use by the service provider to assign addresses to connecting clients. An algorithm or policy is necessary so that the number of peak users over time is considered along with the IPSec service module configuration to generate the appropriate address space requirement for a specific remote access user.

Internet Access Method

To support troubleshooting, the remote access user should provide information describing the Internet access methods that clients use to access the IPSec service module.

Domain Name

Consistent with the format user%service@domain, the remote access user must specify a unique domain name used to make certain that clients are unique. This domain name determines the domain of authority relative to user authentication (proxy or service provider hosted). If you are defining multiple users in multiple groups on the VPN 3000 series concentrator, you must enable group lock to prevent users in one group from logging in with another group's parameters. For information on group lock, see http://www.cisco.com/warp/public/471/altigagroup.html .

IPSec Infrastructure Provisioning

In addition to the required information, router configuration information is necessary to provision the infrastructure for a specific customer (this assumes basic infrastructure provisioning is complete):

VRF name
Route distinguisher (should be generated by an algorithm)
Route targets for import/export
Routing policy—Required to assure address pools are exposed.
IPSec policy—All customers have the same policy. Configuration arguments must be loaded into the new customer VRF.

Remote Access IPSec Configuration Example

The following configuration example shows relevant service-related configuration required for remote access users activation on an ITR. Customer 'Coke' is used for example purposes only. Customer-specific routing is not shown.

Step 2 Configure the VRF including route descriptor and the export/import route targets.

Step 3 Configure ISAKMP policy for Phase 1 if it is different from the existing policies or does not exist.

Step 5 Configure the transform set if it is different than the existing ones or does not exist.

Step 9 Assuming that the BGP PE configuration is already configured, add the customer-specific address- family configuration. Optional route maps can be applied to filter any routes.

Table of Contents

Planning for IPSec Remote Access

IPSec Remote Access Overview