|
Table Of Contents
Planning for IPSec Remote Access
Required Information for Implementing Remote Access
IPSec Infrastructure Provisioning
Remote Access IPSec Configuration Example
Planning for IPSec Remote Access
Revised December 22, 2005
IPSec Remote Access Overview
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.
Note IPSec remote access requires one access-request for IKE (authorization) and another for XAUTH+MODE-CFG (authentication).
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
Remote access users need to identify the following AAA configuration options:
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.
Note SecurID is supported only in proxy mode and not in native mode.
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.
For information on the Cisco IOS software commands used below, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/index.htm.
Note Download group parameters from RADIUS during device authorization. The parameters are not configured on the router.
Step 1 Configure the AAA group list for the new customer pointing to RADIUS for authentication as well as authorization.
aaa authentication login coke-ra radius
aaa authorization network coke-ra radius
Step 2 Configure the VRF including route descriptor and the export/import route targets.
ip vrf coke
rd 1:101
route-target export 1:101
route-target import 1:101
Step 3 Configure ISAKMP policy for Phase 1 if it is different from the existing policies or does not exist.
crypto isakmp policy 1
authentication pre-share
group 2
Step 4 Configure the remote access profile.
crypto isakmp profile coke-ra
vrf coke
match identity group coker-ra
client authentication list coke-ra
isakmp authorization list coke-ra
client configuration address respond
Step 5 Configure the transform set if it is different than the existing ones or does not exist.
crypto ipsec transform-set tset esp-des esp-md5-hmac
Step 6 Configure the dynamic map for remote access clients
crypto dynamic-map coke-ra 1
set transform-set tset
reverse-route
set isakmp-profile-coke-ra
Step 7 Apply the dynamic map as well as the isakmp profile to the crypto map.
crypto map vpn 1 ipsec-isakmp dynamic coke-ra
Step 8 Configure the address pool corresponding to the customer.
ip local pool coke-ra 192.168.1.1 192.168.1.254
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.
address-family ipv4 vrf coke
redistribute connected
redistribute static
no auto-summary
no synchronization
aggregate-address 192.168.1.0 255.255.255.0 summary-only
exit-address-family
Posted: Thu Dec 22 12:29:18 PST 2005
All contents are Copyright © 1992--2005 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.