Table Of Contents
Managing Site-to-Site VPNs
Understanding VPN Topologies
Hub-and-Spoke VPN Topologies
Point-to-Point VPN Topologies
Full Mesh VPN Topologies
Implicitly Supported Topologies
Understanding IPSec Technologies and Policies
Working with VPN Topologies
Creating a VPN Topology
Defining a Name and IPSec Technology
About Selecting Devices in a VPN Topology
Selecting Devices for Your VPN Topology
About Defining and Editing the Endpoints and Protected Networks
Defining the Endpoints and Protected Networks
About Editing a VPN Topology
Editing a VPN Topology
Deleting a VPN Topology
Understanding Dial Backup
Configuring Dial Backup
Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade
Procedure for Configuring a VPNSM or VPN SPA Blade
Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
Understanding VRF-Aware IPSec
VRF-Aware IPSec One-Box Solution
VRF-Aware IPSec Two-Box Solution
Configuring VRF-Aware IPSec Settings
Understanding High Availability
Configuring High Availability in Your VPN Topology
Managing VPN Devices in Device View
Working with Site-to-Site VPN Policies
Managing Shared Site-to-Site VPN Policies in Policy View
Understanding IKE
Deciding Which Encryption Algorithm to Use
Deciding Which Hash Algorithm to Use
Deciding Which Diffie-Hellman Group to Use
Deciding Which Authentication Method to Use
Configuring an IKE Proposal
Understanding IPSec Tunnel Policies
About Transform Sets
About Crypto Maps
Configuring IPSec Proposals
Understanding VPN Global Settings
Understanding ISAKMP/IPSec Settings
Understanding NAT
Understanding Fragmentation
Configuring VPN Global Settings
Understanding Preshared Key Policies
Configuring Preshared Key Policies
Understanding Public Key Infrastructure Policies
Prerequisites for Successful PKI Enrollment
Configuring Public Key Infrastructure Policies
Understanding GRE
Understanding GRE Configuration for Dynamically Addressed Spokes
Configuring GRE or GRE Dynamic IP Policies
Understanding DMVPN
Configuring DMVPN Policies
Understanding Easy VPN
Configuring Easy VPN Policies
Configuring an IPSec Proposal for Easy VPN
Configuring a User Group Policy for Easy VPN
Configuring a Tunnel Group Policy for Easy VPN
Configuring Client Connection Characteristics for Easy VPN
Managing Site-to-Site VPNs
A Virtual Private Network (VPN) consists of multiple remote peers transmitting private data securely to one another over an unsecured network, such as the Internet. Site-to-site VPNs use tunnels to encapsulate data packets within normal IP packets for forwarding over IP-based networks, using encryption to ensure privacy and authentication to ensure integrity of data.
In Cisco Security Manager, site-to-site VPNs are implemented based on IPSec policies that are assigned to VPN topologies. An IPSec policy is a set of parameters that define the characteristics of the site-to-site VPN, such as the security protocols and algorithms that will be used to secure traffic in an IPSec tunnel. Security Manager translates IPSec policies into CLI commands that can be deployed to the devices in the VPN topology. Several policy types may be required to define a full configuration image that can be assigned to a VPN topology, depending on the IPSec technology type. For a description of the procedure to assign IPSec policies to VPN topologies, see Modifying Policy Assignments in Policy View, page 6-41.
The Site-to-Site VPN Manager defines and configures site-to-site VPN topologies and policies on Cisco IOS security routers, PIX Firewalls, Catalyst VPN Service Modules, and Adaptive Security Appliance (ASA) firewall devices.
You can access the Site-to-Site VPN Manager by selecting Tools > Site-To-Site VPN Manager or clicking the Site-To-Site VPN Manager button on the toolbar.
Note 
You can also view site-to-site VPN topologies and configure policies in Policy view and Device view. For more information, see:
•Managing Shared Site-to-Site VPN Policies in Policy View
•Managing VPN Devices in Device View.
The following topics describe:
•Understanding VPN Topologies
•Understanding IPSec Technologies and Policies
•Working with VPN Topologies
•Managing VPN Devices in Device View
•Working with Site-to-Site VPN Policies
Understanding VPN Topologies
A VPN topology specifies the peers and the networks that are part of the VPN and how they connect to one another. After you create a VPN topology, the policies that can be applied to your VPN topology become available for configuration.
Security Manager supports three basic types of topologies—hub and spoke, point to point, and full mesh, with which you can create a site-to-site VPN. Not all policies can be applied to all VPN topologies. The policies that can be applied depend on the IPSec technology that is assigned to the VPN topology. In addition, the IPSec technology that is assigned to a VPN depends on the topology type. For example, the DMVPN and Easy VPN technologies can only be applied in a hub-and-spoke topology.
For more information, see Understanding IPSec Technologies and Policies.
Note Security Manager provides default configurations for all site-to-site VPN policies, enabling you to deploy to your devices immediately after creating a VPN topology.
The following topics describe:
•Hub-and-Spoke VPN Topologies
•Point-to-Point VPN Topologies
•Full Mesh VPN Topologies
•Implicitly Supported Topologies
Hub-and-Spoke VPN Topologies
In a hub-and-spoke VPN topology, multiple remote devices (spokes) communicate securely with a central device (hub). A separate, secured tunnel extends between the hub and each individual spoke.
Figure 9-1 shows a typical hub-and-spoke VPN topology.
Figure 9-1 Hub-and-Spoke VPN Topology
This topology usually represents an intranet VPN that connects an enterprise's main and branch office locations using persistent connections to a third-party network or the Internet. VPNs in a hub-and-spoke topology make it easy and affordable to provide all employees with full access to the enterprise network, regardless of the size, number, or location of its remote operations.
A hub is a Cisco IOS VPN-enabled device, generally located at an enterprise's main office. Spokes are also devices, generally located at an enterprise's branch offices.
In a hub-and-spoke topology, most traffic is initiated by hosts at the spoke site, but some traffic might be initiated from the central site to the spokes.
If the hub in a hub-and-spoke configuration becomes unavailable for any reason, IPSec failover transfers tunnel connections seamlessly to a failover (backup) hub, which will be used by all spokes. You can configure multiple failover hubs for a single primary hub.
In a hub-and-spoke VPN topology, all IPSec technology types can be assigned. For more information, see Understanding IPSec Technologies and Policies.
Related Topics
•Understanding VPN Topologies
•Implicitly Supported Topologies
•Working with Site-to-Site VPN Policies
Point-to-Point VPN Topologies
In a point-to-point VPN topology, two devices communicate directly with each other, without the option of IPSec failover as in a hub-and-spoke configuration. To establish a point-to-point VPN topology, you simply specify two endpoints as peer devices. Since either of the two devices can initiate the connection, the assigned IPSec technology type can be only regular IPSec or GRE. For more information, see Understanding IPSec Technologies and Policies.
Figure 9-2 shows a typical point-to-point VPN topology.
Figure 9-2 Point-to-Point VPN Topology
Related Topics
•Understanding VPN Topologies
•Implicitly Supported Topologies
•Working with Site-to-Site VPN Policies
Full Mesh VPN Topologies
In a full mesh VPN topology, every device in the network communicates with every other device via a unique IPSec tunnel. Traffic is permitted between all sites—in other words, all devices have direct peer relationships with one another.
Note You can assign only regular IPSec and GRE technologies to a full mesh VPN topology. See Understanding IPSec Technologies and Policies.
Figure 9-3 shows a typical full mesh VPN topology.
Figure 9-3 Full Mesh VPN Topology
A full mesh network is reliable and offers redundancy. When the assigned technology is GRE and one device (or node) can no longer operate, all the rest can still communicate with one another, directly or through one or more intermediate nodes. With regular IPSec, if one device can no longer operate, a crypto access control list (ACL) that specifies the protected networks, is created per two peers.
A full mesh topology works well in a complicated network where all peers need to communicate with each other. It prevents a bottleneck at the VPN gateway device, and saves the overhead of encryption and decryption on this device.
When the number of nodes in a full mesh topology increases, scalability may become an issue—the limiting factor being the number of tunnels that the devices can support at a reasonable CPU utilization.
Related Topics
•Understanding VPN Topologies
•Implicitly Supported Topologies
•Working with Site-to-Site VPN Policies
Implicitly Supported Topologies
In addition to the three main VPN topologies, other more complex topologies may be created as combinations of these topologies. They include:
•Partial mesh—A network in which some devices are organized in a full mesh topology, and other devices form either a hub-and-spoke or a point-to-point connection to some of the fully meshed devices. A partial mesh does not provide the level of redundancy of a full mesh topology, but is less expensive to implement. Partial mesh topologies are generally used in the peripheral networks that connect to a fully meshed backbone.
•Tiered hub-and-spoke—A network of hub-and-spoke topologies in which a device can behave as a hub in one or more topologies and a spoke in other topologies. Traffic is permitted from spoke groups to their most immediate hub.
•Joined hub-and-spoke—A combination of two topologies (hub-and-spoke, point-to-point, or full mesh) that connect to form a point-to-point tunnel. For example, a joined hub-and-spoke topology could comprise two hub-and-spoke topologies, with the hubs acting as peer devices in a point-to-point topology.
Related Topics
•Understanding VPN Topologies
•Hub-and-Spoke VPN Topologies
•Point-to-Point VPN Topologies
•Full Mesh VPN Topologies
Understanding IPSec Technologies and Policies
Policies are grouped according to their IPSec technology type. Security Manager provides five types of IPSec technologies that you can configure on the devices in your site-to-site VPN topology—regular IPSec, GRE, GRE Dynamic IP, DMVPN, and Easy VPN. When you assign a technology to a VPN, all the policies that can be applied to your VPN topology using the assigned technology, become available.
Note You assign an IPSec technology to a VPN topology during its creation. After an IPSec technology is assigned to a VPN topology, you cannot change the technology, other than by deleting the VPN topology and creating a new one. See Defining a Name and IPSec Technology.
About Mandatory and Optional Policies
Some site-to-site VPN policies are mandatory, which means they are configured on your devices with predefined defaults, upon definition of the IPSec technology. You can edit these policies, if required. The policies that are not predefined are optional and available for your configuration, as required.
Note Mandatory policies with their default configurations provided by Security Manager, enable you to deploy to your devices immediately after creating the VPN topology. All you need to do is complete the steps of the Create VPN wizard. See Creating a VPN Topology.
Some mandatory policies are mandatory only under certain conditions. For example, a preshared key policy is mandatory only if the default (mandatory) IKE proposal uses preshared key authentication. If the selected IKE authentication method is RSA Signature, a Public Key Infrastructure policy is mandatory (see Deciding Which Authentication Method to Use). In addition, a tunnel group policy for an ASA device is mandatory only if the ASA is a hub device in a hub-and-spoke VPN topology.
Table 9-1 lists the mandatory and optional policies, for each predefined technology that you can assign to the devices in your site-to-site VPN topology.
Note In point-to-point and full mesh VPN topologies, you can assign only regular IPSec and GRE technologies.
Table 9-1 Site-to-Site VPN IPSec Technologies
Technology
|
Mandatory Policies
|
Optional Policies
|
Supported Platforms
|
Regular IPSec
See Understanding IPSec Tunnel Policies.
|
•IKE Proposal
•IPSec Proposal
•Preshared Key1
|
•Public Key Infrastructure2
•VPN Global Settings
|
Regular IPSec policies can be configured on Cisco IOS security routers, PIX Firewalls, Catalyst VPN service modules, and ASA devices.
|
Generic Routing Encapsulation (GRE).
See Understanding GRE.
|
•IKE Proposal
•IPSec Proposal
•Preshared Key1
•GRE Modes
|
•Public Key Infrastructure2
•VPN Global Settings
|
GRE policies can be configured on Cisco IOS security routers and Catalyst 6500/7600 devices.
|
GRE Dynamic IP
See Understanding GRE Configuration for Dynamically Addressed Spokes.
|
•IKE Proposal
•IPSec Proposal
•Preshared Key1
•GRE Modes
|
•Public Key Infrastructure2
•VPN Global Settings
|
GRE Dynamic IP can be configured on Cisco IOS security routers and Catalyst 6500/7600 devices.
|
Dynamic Multipoint VPN (DMVPN).
See Understanding DMVPN.
|
•IKE Proposal
•IPSec Proposal
•Preshared Key1
•GRE Modes
|
•Public Key Infrastructure2
•VPN Global Settings
|
DMVPN configuration is supported on Cisco IOS 12.3T devices and later.
|
Easy VPN
See Understanding Easy VPN.
|
•IKE Proposal
•IPSec Proposal
•User Group
•Client Connection Characteristics
|
•Tunnel Group (mandatory if device is an ASA hub in VPN topology)
•Public Key Infrastructure2
•VPN Global Settings
|
Easy VPN configuration is supported on Cisco IOS security routers, PIX Firewalls, Catalyst VPN service modules, and ASA devices.
|
Related Topics
•Understanding VPN Topologies
•Working with Site-to-Site VPN Policies
•Understanding Policies, page 6-1
Working with VPN Topologies
Security Manager provides the Site-to-Site VPN Manager that you can use to view, create, edit, and delete VPN topologies. You can also view the policies that are assigned to each VPN topology, create new policies, and edit them.
Note You can also view a list of VPN topologies in Device view. For more information, see Managing VPN Devices in Device View.
The following topics describe:
•Creating a VPN Topology
•Editing a VPN Topology
•Deleting a VPN Topology
•Managing VPN Devices in Device View
•Working with Site-to-Site VPN Policies
Related Topics
•Understanding VPN Topologies
•Working with Site-to-Site VPN Policies
•Site-to-Site VPN Manager Window, page B-2
Creating a VPN Topology
Creating a VPN topology involves specifying the devices and the networks that comprise the site-to-site VPN. You define the devices and their roles (such as hub, spoke, peer), the VPN interfaces that are the source and destination endpoints of the VPN tunnel, and the protected networks that will be secured by the tunnel. You can create hub-and-spoke, point-to-point, or full mesh type topologies. When you create a VPN topology, you assign to it the IPSec technology with which a predefined set of policies is associated. See Understanding IPSec Technologies and Policies.
Note You can create a visual representation of your VPN topology with all its elements in the Map view. For more information, see Creating VPN Topologies (Map View), page 4-30.
While creating a VPN topology, you can also configure:
•High Availability on a group of hubs in a hub-and-spoke topology (see Configuring High Availability in Your VPN Topology).
•VRF-Aware IPSec on a hub in a hub-and-spoke topology (see Configuring VRF-Aware IPSec Settings).
•A VPN Services Module (VPNSM blade) on a Catalyst 6500/7600 in a hub-and-spoke, point-to-point, or full mesh VPN topology (see Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface).
•A VPN SPA blade on a Catalyst 6500/7600 in a hub-and-spoke, point-to-point, or full mesh VPN topology (see Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade).
•A Firewall Services Module together with a VPN Services Module or VPN SPA on a Catalyst 6500/7600 device in a hub-and-spoke, point-to-point, or full mesh VPN topology (see Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA).
You can use the Create VPN wizard to create hub-and-spoke, point-to-point, and full mesh VPN topologies across multiple device types.
Note After creating the VPN topology, you can deploy to your devices immediately using the default policy configurations provided by Security Manager. All you need to do is complete the steps of the Create VPN wizard.
The following topics describe how to create a VPN topology:
•Defining a Name and IPSec Technology
•Selecting Devices for Your VPN Topology
•Defining the Endpoints and Protected Networks
•Configuring High Availability in Your VPN Topology
Note To edit a VPN topology, you use the same pages that appear in the Create VPN wizard. For more information, see Editing a VPN Topology.
Defining a Name and IPSec Technology
On the Name and Technology page of the Create VPN wizard, you define a name and description for the VPN topology, and select the IPSec technology that will be assigned to it.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 To add a VPN topology, click the Create VPN Topology button above the VPNs selector and select Hub and Spoke, Point to Point, or Full Mesh from the shortcut menu.
To edit a VPN topology, right-click it in the VPNs selector, and select Edit.
The Create VPN wizard opens, displaying the contents of the Name and Technology page. See Table B-4 on page B-10 for a description of the elements on this page.
Step 3 Enter a unique name and description for the VPN topology in the relevant fields.
Step 4 From the IPSec Technology list, select the IPSec technology that you want to assign to the VPN topology.
Note If you are editing a VPN topology, the assigned IPSec technology is displayed, but unavailable for editing. To edit the technology, you must delete the VPN topology and create a new one.
Step 5 Click Next (or the Device Selection tab if you are editing a VPN topology) to select the devices for your VPN topology.
For more information about selecting devices, see About Selecting Devices in a VPN Topology. For the procedure to select devices, see Selecting Devices for Your VPN Topology.
Related Topics
•Understanding IPSec Technologies and Policies
•Working with VPN Topologies
•Name and Technology Page, page B-9
About Selecting Devices in a VPN Topology
Note For the procedure to select devices for your VPN topology, see Selecting Devices for Your VPN Topology.
On the Device Selection page of the Create VPN wizard, you select the devices to include in the VPN topology. The contents of this page differ depending on whether you are creating or editing a hub-and-spoke, point-to-point, or full mesh VPN topology.
Only the devices that can be used for the selected VPN topology type and which you are authorized to view, are available for selection. In addition, the available devices depend on the selected IPSec technology—for example, if the IPSec technology is GRE, GRE Dynamic IP, or DMVPN, PIX Firewalls and ASA devices will not be displayed. For more information, see the supported platforms described in Table 9-1.
Note You can also edit the devices included in your VPN topology from Device view. For more information, see Managing VPN Devices in Device View.
Adding Unmanaged Devices to Your VPN Topology
You can include unmanaged devices in your VPN topology. These devices may serve as endpoints in a VPN topology, but Security Manager neither uploads or downloads any configurations nor deploys to them.
An unmanaged device can be a non-Cisco device, or a Cisco device that you do not want Security Manager to manage. An unmanaged device can also be a Cisco device that is not managed by Security Manager, but can still serve as a VPN endpoint, such as a VPN concentrator.
Note You can specify that a device is unmanaged when you add it to your device inventory, by deselecting the Manage in Security Manager check box in the Device Information wizard. For more information, see Adding a New Device, page 5-49.
Related Topics
•View Permissions, page 2-4
•Selecting Devices for Your VPN Topology
•Removing Devices from a VPN Topology
•Device Selection Page, page B-10
•Working with VPN Topologies
Selecting Devices for Your VPN Topology
This procedure describes how to select the devices that will be included in your VPN topology. For more information about selecting devices in a VPN topology, see About Selecting Devices in a VPN Topology.
Procedure
Step 1 Open the Device Selection page by clicking Next (or the Device Selection tab if you are editing a VPN topology) on the Name and Technology page of the Create VPN wizard. For a description of the elements on the Device Selection page, see Table B-5 on page B-12.
Step 2 Select the devices you want to include in your VPN topology, as follows:
•If you are creating or editing a hub-and-spoke topology:
–From the Devices list, select the device(s) that you want to define as hubs (or servers in an Easy VPN configuration) in your VPN topology, then click >>. The selected devices appear in the Hubs List.
Make sure that the device you want to be the primary hub appears first in the list. You can use the Up and Down buttons to change the order of the devices in the Hubs list.
–Select the device(s) that you want to define as spokes (or clients in an Easy VPN configuration) in your VPN topology, then click >>. The selected devices appear in the Spokes List.
•If you are creating or editing a point-to-point topology:
–From the Devices list, select a device to be Peer One in your VPN topology, then click >>.
–Select another device to be Peer Two in the topology, and click >>.
Note Only two devices are available for selection in a point-to-point VPN topology.
•If you are creating or editing a full mesh topology, select the device(s) that you want to include in your full mesh topology, then click >>. The devices appear in the Selected Devices list.
Step 3 Click Next (or the Endpoints tab if you are editing a VPN) to define the VPN interfaces and the protected networks for the devices in your VPN topology.
For the procedure to define the endpoints and protected networks, see Defining the Endpoints and Protected Networks.
Related Topics
•About Selecting Devices in a VPN Topology
•Adding Unmanaged Devices to Your VPN Topology
•Device Selection Page, page B-10
•Working with VPN Topologies
About Defining and Editing the Endpoints and Protected Networks
Note For the procedure to define and edit the endpoints and protected networks, see Defining the Endpoints and Protected Networks.
On the Endpoints page of the Create VPN wizard, you define the external or internal VPN interfaces and the protected networks for the devices in your VPN topology. The VPN interfaces are the interfaces that encrypt the data. The protected networks are the networks that are encrypted.
The Endpoints table lists the VPN interfaces and protected networks defined for all the selected devices in the VPN topology, including the interface roles, or the interfaces that match each interface role.
VPN interfaces are predefined interface role objects. Interface role objects enable you to apply policies to specific interfaces on multiple devices without having to manually define the names of each interface. For more information about interface roles, see Working with Interface Role Objects, page 8-120.
When selecting or editing the protected networks in your VPN, you can use interface roles whose naming patterns match the internal VPN interface type of the device, or network objects to refer to multiple networks. For more information about network objects, see Working with Network/Host Objects, page 8-142.
If the assigned technology is IPSec, you can also use access control lists (ACLs) to specify the protected networks. For more information, see Working with Access Control List Objects, page 8-32.
Note In a hub-and-spoke VPN topology in which IPSec is the assigned technology, when an ACL object is used to define the protected network on a spoke, Security Manager mirrors the spoke's ACL object on the hub to the matching crypto map entry.
Editing the VPN interfaces and protected networks for the devices in your VPN topology can include the following:
•Editing the VPN interfaces defined for devices.
•Configuring a VPN Services Module (VPNSM) interface or VPN SPA for a Catalyst 6500/7600 device.
•Configuring a dial backup interface to be used as a fallback link for the primary VPN interface.
•Editing the protected networks defined for devices.
•Configuring a Firewall Services Module together with a VPN Services Module on a Catalyst 6500/7600 device.
•Configuring a VRF-Aware-IPSec policy on a hub in a hub-and-spoke topology.
Related Topics
•Defining the Endpoints and Protected Networks
•Understanding VPN Topologies
•Endpoints Page, page B-13
•Configuring Dial Backup
•Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
•Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade
•Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
•Configuring VRF-Aware IPSec Settings
Defining the Endpoints and Protected Networks
Using the Edit Endpoints dialog box, you can define or edit the external or internal interfaces and protected networks in your VPN topology. The Edit Endpoints dialog box may display four tabs. Click the appropriate tab to edit the VPN interface or protected networks of the selected device, configure FWSM on a Catalyst 6500/7600 device, or configure a VRF Aware IPSec policy on a hub device.
For more information, see About Defining and Editing the Endpoints and Protected Networks.
Before You Begin
•This procedure describes how to edit the VPN interface and protected networks defined for a device, and configure a dial backup interface to be used as a fallback link for a primary VPN interface.
•If you are configuring a VPN interface for a Catalyst 6500/7600 device, see Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface.
•To configure a Firewall Services Module together with a VPN Services Module on a Catalyst 6500/7600 device, see Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA.
•If the selected device is a hub (IPSec Aggregator) on which you want to configure VRF-Aware IPSec, see Configuring VRF-Aware IPSec Settings.
Procedure
Step 1 Open the Endpoints page by clicking Next (or the Device Selection tab if you are editing a VPN topology) on the Device Selection page of the wizard. For a description of the elements on the Endpoints page, see Table B-6 on page B-14.
Step 2 To edit the VPN interface or protected networks for a device, select the row in the table that contains the device and click Edit, or right-click the row in the table and select Edit Row. The Edit Endpoints dialog box opens.
For a description of the tabs on the Edit Endpoints dialog box, see Edit Endpoints Dialog Box, page B-16.
Note You can select more than one device at a time for editing. The changes you make on the VPN Interface or Protected Networks tabs can be applied to all the selected devices. When selecting multiple devices, you cannot include Catalyst 6500/7600 devices in your selection.
Step 3 To edit the primary VPN interface for the selected device, click the VPN Interface tab, then do the following:
a. Specify the VPN interface defined for the selected device.
If required, click Select to open a dialog box that lists all available interfaces, and sets of interfaces defined by interface roles, in which you can make your selection, or create interface role objects. For more information, see Editing Interface Role Objects, page 8-124.
b. If the selected device is an ASA or PIX 7.0 hub in a hub-and-spoke VPN topology, and if the selected technology is regular IPSec, select the type of connection from the Connection Type list, as follows:
•Answer Only—To configure the hub to only respond to an SA negotiation, but not initiate it.
•Originate Only—To configure the hub to only initiate an SA negotiation, but not respond to one.
•Bidirectional—To configure the hub to both initiate and respond to an SA negotiation.
c. To define the IP address of the VPN interface of the peer device, click one of the following radio buttons in the Peer IP Address area:
•VPN Interface IP Address—To use the configured IP address on the selected VPN interface.
•IP Address for IPSec Termination—To enter manually the IP address of the peer device. Enter the IP address in the field provided.
•IP Address of Another Existing Interface to be Used as Local Address—To use the configured IP address as a local address on any interface, not necessarily a VPN interface. Enter the interface in the field provided.
You can choose the required interface by clicking Select. A dialog box opens that lists all available predefined interface roles, and in which you can create an interface role object. For more information, see Editing Interface Role Objects, page 8-124.
d. If the device is a hub and the selected technology is GRE or DMVPN, you must define the tunnel source address to be used by the GRE or DMVPN tunnel on the spoke side. Click one of the following radio buttons in the Tunnel Source area:
•VPN Interface—To use the selected VPN interface as the tunnel source address.
•Another Existing Interface—To use any interface as the tunnel source address, not necessarily a VPN interface, select this radio button, then enter the interface in the field provided.
You can choose the required interface by clicking Select. A dialog box opens that lists all available predefined interface roles, and in which you can create an interface role object. See Editing Interface Role Objects, page 8-124.
e. To enable the configuration of a backup interface to be used as a fallback link for the primary route VPN interface if its connection link becomes unavailable, select the Enable check box in the Backup area, then provide the relevant information in the fields provided. For the procedure to configure dial backup, see Configuring Dial Backup.
Step 4 To edit the protected networks for the selected device:
a. Click the Protected Networks tab on the Edit Endpoints dialog box.
b. From the Available Protected Networks list, select the interface role(s), protected networks, and/or access control lists (ACLs) that you want to define for the selected device, then click >>.
If the required interface roles, protected networks, or ACLs do not appear in the Available Protected Networks list, click Create and select the required option to create an interface role, protected network, or ACL. The Access Control List option is available only when IPSec is the assigned technology.
Note In a hub-and-spoke VPN topology in which IPSec is the assigned technology, when an ACL object is used to define the protected network on a spoke, Security Manager mirrors the spoke's ACL object on the hub to the matching crypto map entry.
The protected networks, interface roles, and access control lists you selected for the device are displayed in the Selected Protected Networks list.
Step 5 You can now do one of the following:
•To go back and change the devices selected in your VPN topology, click Back (or the Device Selection tab). See Selecting Devices for Your VPN Topology.
•To configure high availability on a group of hubs, click Next (or the High Availability tab if you are editing a VPN). See Configuring High Availability in Your VPN Topology.
•Click Finish to complete the VPN topology creation or modification process and exit the wizard, or OK to save your changes and close the Edit VPN dialog box.
The new or edited VPN topology appears in the VPNs selector in the Site-to-Site VPN window, with the VPN Summary page displayed. See VPN Summary Page, page B-3.
Related Topics
•Working with VPN Topologies
•About Defining and Editing the Endpoints and Protected Networks
•Endpoints Page, page B-13
•Edit Endpoints Dialog Box, page B-16
•Configuring Dial Backup
•Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
•Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
•Configuring VRF-Aware IPSec Settings
About Editing a VPN Topology
Note For the procedure to edit a VPN topology, see Editing a VPN Topology.
You can edit a VPN topology by changing its device structure (adding or removing devices), changing the VPN interfaces and protected networks defined for a device, or modifying the policies that are assigned to the VPN. For example, if your organization frequently opens new sites, you may need to add spokes to an existing hub-and-spoke VPN, while applying all policies of the VPN to the new spokes. Or, you may want to increase resiliency by adding a secondary hub to a VPN that has only one hub. You can also designate a hub to act as an IPSec Aggregator in a VRF-Aware IPSec configuration, or to be included in a High Availability (HA) group. While editing a VPN topology, you may also need to modify the policies assigned to it, such as, changing an IKE algorithm that was originally defined to a more secured one, or changing the DES encryption algorithm for a VPN, to make it more secure.
When you edit a VPN topology, you can also configure a VPN Services Module (VPNSM) or VPN SPA blade, with or without a Firewall Services Module (FWSM blade) on a Catalyst 6500/7600 device, in a hub-and-spoke, point-to-point, or full mesh VPN topology.
Note You can also a VPN topology at the device level from Device view, which displays a list of VPN topologies to which a selected device belongs. From this view, you can view and edit the structure of your VPN topologies, and edit the policies defined for them. See Managing VPN Devices in Device View.
About Locking in Site-to-Site VPN Topologies
Security Manager has a locking mechanism that prevents more than one user from making changes to the same policy or policy assignment at the same time. When a policy is locked, a message is displayed across the top of the work area to other users who access that policy. For more information, see Understanding Locking, page 6-48.
If you change the device assignment for a VPN topology, or make changes to a specific VPN policy, a lock is placed on the whole VPN topology, and any other topologies in which the policy is shared. This means that other users cannot make changes to the device assignment, nor can they make changes to any of the policies defined for the VPN topologies.
In order to view and modify site-to-site VPN policies, you must have the required permissions for each of the devices in the VPN topology. You also need permissions to add a device to a VPN topology. If you have different levels of permissions to the devices in the VPN topology, the lowest permission level is applied to the whole topology. For example, if you have read/write permissions to the spokes in a hub-and-spoke topology, but read-only permissions to the device serving as the hub, you are granted read-only permission to the policies and devices in the hub-and-spoke topology. For more information about permissions, see Security Manager Permissions, page 2-3.
Note•The information displayed in the VPN Summary page is read-only. It cannot be locked nor shared between VPN topologies. See VPN Summary Page, page B-3.
•The information displayed in the VPN Peers page can be locked but not shared between VPN topologies. Locking this information prevents all associated peers in the VPN topology from being edited by other users. Unassigning devices from a VPN topology will maintain the device locking in this VPN topology, which means that these devices cannot be deleted from the inventory. See Peers Page, page B-7.
Removing Devices from a VPN Topology
On the Device Selection page, you can also remove devices from your VPN topology. When doing this, you should be aware of the following:
•You cannot remove a device if it is the only hub in a hub-and-spoke VPN topology, unless you replace it with a different hub.
•You cannot remove a device that is one of the two devices in a point-to-point VPN topology, unless you replace it with a different device.
•In a VPN topology with multiple hub devices, deleting a hub causes the appropriate tunnels to be removed.
•If some, but not all, spokes in a VPN topology are deleted, the hub side crypto statements change to reflect the removal.
Related Topics
•Editing a VPN Topology
•Device Selection Page, page B-10
Editing a VPN Topology
You can edit a VPN topology using the Edit VPN dialog box. This dialog box displays three tabs—Name and Technology, Device Selection, and Endpoints. If you are editing a hub-and-spoke VPN topology, a fourth tab, the High Availability tab, is also displayed. The tabs display the same elements as appear in the pages of the Create VPN wizard. You can click a tab to go directly to the page that contains the parameters you want to edit, without having to go through each page in a wizard.
This procedure describes how to edit a VPN topology from the Site-to-Site VPN Manager. You can also edit a VPN topology from Device view. For more information, see
Before You Begin
•Make sure the VPN topology you want to edit appears in the VPNs selector in the Site-to-Site VPN window.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the VPN topology you want to edit, and click Edit. The Edit VPN dialog box opens, displaying the Name and Technology tab. For a description of the elements on this tab, see Table B-4 on page B-10.
Step 3 If required, edit the name and description of the VPN topology.
Note You cannot edit the assigned IPSec technology. To edit the technology, you must delete the VPN topology and create a new one.
Step 4 Click the Device Selection tab if you want to change the device structure of your VPN topology. For a description of how to change the device selection on this tab, see Selecting Devices for Your VPN Topology.
Note To remove devices from your VPN topology, select them on the Device Selection tab, and click <<.
Step 5 If you want to view or edit the external or internal interfaces or protected networks in your VPN topology, configure a VRF Aware IPSec policy on a hub device, or define FWSM settings for a Catalyst 6500/7600 device, click the Endpoints tab. Then, in the Endpoints table, select the device(s) you want to edit and click Edit to open the Edit Endpoints dialog box. For a description of how to use the Edit Endpoints dialog box, see Edit Endpoints Dialog Box, page B-16.
Note You can also use the Edit Endpoints dialog box to define the VPN Services Module (VPNSM) or VPN SPA settings, and/or FWSM settings for a Catalyst 6500/7600 device.
Step 6 If you are editing a hub-and-spoke VPN topology, and you want to configure high availability on a group of hubs, or remove a high availability group that was defined for the topology, click the High Availability tab. For a description of the elements on this tab, see Table B-13 on page B-36.
Step 7 Click OK to save your changes locally on the client.
Related Topics
•Managing VPN Devices in Device View
•Removing Devices from a VPN Topology
•Working with VPN Topologies
•Defining a Name and IPSec Technology
•About Selecting Devices in a VPN Topology
•Defining the Endpoints and Protected Networks
•Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
•Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade
•Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
•Configuring VRF-Aware IPSec Settings
•Configuring High Availability in Your VPN Topology
•Working with Site-to-Site VPN Policies
Deleting a VPN Topology
Deleting a VPN topology removes the IPSec tunnels between peers and all configurations associated with the VPN topology, from the devices and networks assigned to the site-to-site VPN.
This procedure describes how to delete a VPN topology.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens, displaying all defined VPN topologies.
Step 2 In the VPNs selector, select the VPN topology you want to delete and click Delete.
A confirmation dialog box opens asking you to confirm the deletion.
Step 3 Click Yes to confirm the deletion.
Related Topics
•Site-to-Site VPN Manager Window, page B-2
•Working with VPN Topologies
Understanding Dial Backup
Note For the procedure to configure dial backup, see Configuring Dial Backup.
Dial backup can be used to provide a fallback link for a primary, direct connection when the primary link becomes unavailable. Implementation of the dial backup feature is based on the assumption that two static routes exist:
•A primary route through a primary gateway, which has highest priority.
•A secondary route through a secondary gateway, which has lower priority and only appears in the routing table when the primary gateway is down.
Security Manager configures a logical dialer interface on the spoke. The dialer interface is associated with a physical backup interface. When the primary route is down, the dialer interface is activated and traffic is redirected through this backup interface, along the secondary route. To ensure that the spoke-hub traffic is encrypted, Security Manager applies a crypto map to the dialer interface. This crypto map is identical to the crypto map on the VPN interface (the primary route interface).
The IOS technology, Response Time Reporter (RTR), is used to detect loss of network performance on the primary route. If the assigned IPSec technology is DMVPN, Dialer Watch-List (DWL) is used.
ISDN Basic Rate Interface (BRI) and analog modem interfaces can be configured to work as backup interfaces to other, primary interfaces. In such a case, an ISDN or analog modem connection is made if the primary interface goes down. Should the primary interface and connection go down, the ISDN or analog modem interface immediately dials out to establish a connection so that network services are not lost.
Before you configure a dial backup policy for your site-to-site VPN, you must configure the dialer interface settings on the appropriate Cisco IOS router. This requires defining the relationship between the physical BRI and Async interfaces, and the virtual dialer interfaces used when configuring dial backup.
Note Dial backup can be configured only on Cisco IOS security routers which are spokes in a hub-and-spoke, point-to-point, or full mesh VPN topology.
Related Topics
•Configuring Dial Backup
•Configuring Dialer Interfaces on Cisco IOS Routers, page 12-29
•VPN Interface Tab, page B-17
•Dial Backup Settings Dialog Box, page B-33
Configuring Dial Backup
Note For conceptual information about configuring dial backup, see Understanding Dial Backup.
Follow the procedure below to configure dial backup on your device.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure the selected device is a Cisco IOS security router which is a spoke in the VPN topology.
•Make sure you have configured the dialer interface settings on the required device. For more information, see Configuring Dialer Interfaces on Cisco IOS Routers, page 12-29.
•Make sure that the primary route is functioning.
Procedure
Step 1 Open the Edit Endpoints dialog box of the Create VPN wizard, as follows:
a. Right-click the required VPN topology in the VPNs selector, and select Edit.
b. Click the Endpoints tab on the Create VPN wizard.
c. Select the row in the Endpoints table that contains the device (router) on which you want to configure dial backup, and click Edit. The Edit Endpoints dialog box opens, displaying the VPN Interface tab. For a description of the elements in the VPN Interface tab, see Table B-7 on page B-18.
Step 2 If required, edit the primary VPN interface for the selected device. See Defining the Endpoints and Protected Networks.
Step 3 In the Backup area, select the Enable check box to enable the configuration of a backup interface.
Step 4 In the Dialer Interface field, specify the physical interface through which the secondary route traffic will be directed when the logical dialer interface is activated.
Step 5 Enter the IP address of the destination device to which connectivity must be maintained from the primary VPN interface connection.
Note If you do not specify an IP address, the primary hub VPN interface is used for a hub-and-spoke VPN topology. In a point-to-point or full mesh VPN topology, the peer VPN interface is used.
Step 6 If the selected IPSec technology is IPSec, GRE, or GRE Dynamic IP, enter the next hop IP address—the IP address to which the primary interface will connect when it is active. If you do not enter the next hop IP address, Security Manager configures a static route using the interface name.
Step 7 If the selected IPSec technology is IPSec, GRE, or GRE Dynamic IP, you may click Advanced to configure additional (optional) settings. The Dial Backup Settings dialog box opens. For a description of the elements in this dialog box, see Table B-12 on page B-34.
Step 8 Enter the next hop IP address of the ISDN BRI or analog modem to which the backup interface will connect when it is active.
Step 9 Specify the tracking object settings by entering the required values in the Timeout, Frequency, and Threshold fields.
Step 10 Click OK to save your definitions locally on the client.
Related Topics
•Understanding Dial Backup
•Defining the Endpoints and Protected Networks
•Edit Endpoints Dialog Box, page B-16
•VPN Interface Tab, page B-17
•Dial Backup Settings Dialog Box, page B-33
Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
Note For the procedure to configure VPNSM on a Catalyst 6500/7600 device, see Procedure for Configuring a VPNSM or VPN SPA Blade.
Security Manager supports Catalyst 6500/7600 devices and Cisco IOS 7600 routers fitted with an IPSec VPN Services Module (VPNSM blade). This module uses virtual LANs (VLANs) to connect to platform LAN and WAN interfaces. The device can be a hub or spoke in a hub-and-spoke, point-to-point, or full mesh VPN topology, managed by Security Manager (except in an Easy VPN configuration, where the device cannot be a spoke).
Security Manager also supports the configuration of a Firewall Services Module (FWSM blade) with a VPN Services Module (VPNSM blade) on a Catalyst 6500/7600 device. For a description of this feature, see Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA.
Note•Security Manager supports the configuration of multiple VPNSM blades on a Catalyst 6500/7600 device, but only one blade (or two if you are configuring intra chassis high availability) can be configured per VPN topology.
•In a remote access VPN, you can configure only one VPNSM failover blade per IPSec proposal. See VPNSM/VPN SPA Settings Dialog Box, page C-846.
•VPNSM configuration requires that its parent Catalyst 6500/7600 device is running Catalyst OS release 12.2(18)SXD1 and later.
To configure a VPNSM on a Catalyst 6500/7600 device, you must first import the device to your Security Manager inventory and discover its interfaces. For more information, see Adding Catalyst 6500/7600 Devices from the Network, page 5-42.
The next step in configuring VPNSM is to create an inside VLAN on the Catalyst 6500/7600 device, or edit an existing port or VLAN configuration. If the device is configured with VRF-Aware IPSec, you must create a forwarding VLAN.
You do this device configuration using Cisco Catalyst Device Manager (Cisco CDM)—an embedded device manager for single chassis setup, switch and services configuration, and monitoring of the Cisco Catalyst 6500/7600 family of products. Cisco CDM enables the management of Catalyst 6500/7600 devices, and specifically the creation of VLANs.
Note You can use only Layer 3 VLANs for VPNSM configuration. For more information, see Creating a Single Layer 3 Ethernet VLAN, page 14-102.
After creating or editing the VLANs or ports for your device using Cisco CDM, you must configure VPNSM on the device using the Site-to-Site VPN Manager. You configure the following VPNSM parameters when specifying the VPN interfaces for your VPN topology:
•The inside VLAN on the inside trunk interface of the VPNSM to which the crypto map will be attached. This VLAN serves as the inside interface to the VPNSM, and is also the hub or spoke endpoint of the VPN tunnel (unless VRF-Aware IPSec is configured on the device).
•The VPNSM blade to which the inside VLAN will be connected.
•The external port or VLAN that connects to the inside VLAN. Security Manager connects the inside VLAN with the Catalyst's external port according to the external port configuration.
•If you are configuring high availability between blades, you must specify a failover VPNSM blade.
For more information, see Defining VPN Services Module (VPNSM) or VPN SPA Settings, page B-21.
Related Topics
•Procedure for Configuring a VPNSM or VPN SPA Blade
•Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
•Defining VPN Services Module (VPNSM) or VPN SPA Settings, page B-21
Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade
In addition to supporting Catalyst 6500/7600 devices and Cisco IOS 7600 routers fitted with a VPN Services Module (VPNSM blade), Security Manager supports the configuration of Cisco IPSec VPN Shared Port Adapter (VPN SPA) blades on these devices. The device can be a hub or spoke in a hub-and-spoke, point-to-point, or full mesh VPN topology managed by Security Manager (except in an Easy VPN configuration, where the device cannot be a spoke).
A Catalyst 6500/7600 device can contain from 3 to 13 chassis slots. The main difference between a VPNSM and a VPN SPA is that two VPN SPA blades can be inserted in a single Catalyst 6500/7600 chassis slot, whereas only one VPNSM blade can be inserted per slot. The location of a VPN SPA blade is identified with a slot and subslot number. Security Manager stores VPN SPA blade information (slot and subslot location and interfaces) in its inventory, so that Security Manager can manage the blades in VPN topologies.
For information on how to configure a VPN SPA blade on a Catalyst 6500/7600 device, see Procedure for Configuring a VPNSM or VPN SPA Blade.
Note The VPN SPA supports the AES encryption algorithm for all key sizes (128-, 192-, and 256-bit), as well as the DES and 3DES encryption algorithms. For more information, see Deciding Which Encryption Algorithm to Use.
The following outlines the steps you must do to configure a VPN SPA blade on a Catalyst 6500/7600 device:
1. Import the device to your Security Manager inventory and discover its interfaces.
Note During the Catalyst 6500/7600 device discovery, you will be required to enter the VPN SPA card slot locations. Since a slot in a Catalyst 6500/7600 chassis can hold two separate VPN SPA cards, you must enter a subslot number (0 or 1). For more information, see Adding VPN SPA Slot Locations, page 5-44.
2. If you need to create an inside VLAN on the device or edit an existing port or VLAN configuration, you can use Cisco Catalyst Device Manager (Cisco CDM). If the device is configured with VRF-Aware IPSec, you must create a forwarding VLAN.
3. In Security Manager, you must create the interface roles for the VLANs or ports that will be used for configuring the VPN SPA on the device. You configure the following VPN SPA parameters when specifying the VPN interfaces for your VPN topology:
–The inside VLAN that serves as the inside interface to the VPN SPA, and is also the endpoint of the VPN tunnel (unless VRF-Aware IPSec is configured on the device).
–The number of the VPN SPA blade slot to which the inside VLAN is connected.
–The number of the subslot on which the blade is installed.
–The external port or VLAN that connects to the inside VLAN. Security Manager connects the inside VLAN with the Catalyst's external port according to the external port configuration.
–If you are configuring high availability between blades, you must specify a failover VPN SPA blade.
For more information, see Defining VPN Services Module (VPNSM) or VPN SPA Settings, page B-21.
Important Notes About Configuring a VPN SPA
Before you configure a VPN SPA blade on a Catalyst 6500/7600 in your VPN topology, you should be aware of the following:
•If you are configuring intra chassis high availability, you cannot use a VPNSM blade and a SPA blade on the same device, as primary and failover blades.
•In the case of a DMVPN topology in which multiple hubs participate, if one of the hubs is configured with a VPN SPA blade, a tunnel key must not be configured on any of the devices, whether they are spokes or hubs. Devices that participate in such a topology must be running IOS version 12.3T and later, in order to support tunnels without keys.
•In a remote access VPN, you can configure only one VPN SPA failover blade per IPSec proposal. See VPNSM/VPN SPA Settings Dialog Box, page C-846.
Related topics
•Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
•Procedure for Configuring a VPNSM or VPN SPA Blade
•Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
•Defining VPN Services Module (VPNSM) or VPN SPA Settings, page B-21
Procedure for Configuring a VPNSM or VPN SPA Blade
This procedure describes how to configure a VPN Services Module (VPNSM) or VPN SPA blade on a Catalyst 6500/7600 device.
Before You Begin:
•Import the required Catalyst 6500/7600 device into the Security Manager inventory and discover its interfaces. For a description of this procedure, see Adding Catalyst 6500/7600 Devices from the Network, page 5-42.
Note If you are configuring a VPN SPA blade, you must enter the VPN SPA card slot locations during device discovery. Because a slot in a Catalyst 6500/7600 chassis can hold two VPN SPA cards, you must enter a subslot number (0 or 1). For more information, see Adding VPN SPA Slot Locations, page 5-44.
•For VPN SPA configuration, make sure that the Catalyst 6500/7600 device is running Catalyst OS release 12.2(18)SXE2 or later.
•If you are configuring a VPNSM or VPN SPA with VRF-Aware IPSec on a device, verify that the device does not belong to a different VPN topology in which VRF-Aware IPSec is not configured. Similarly, if you are configuring a VPNSM or VPN SPA without VRF-Aware IPSec, make sure that the device belongs to a different VPN topology in which VRF-Aware IPSec is configured.
•For VPN SPA configuration, please read Important Notes About Configuring a VPN SPA.
Procedure
Step 1 Select View > Device View or click the Device View button on the toolbar.
Step 2 Select your Catalyst 6500/7600 device from the Device selector.
Step 3 Right-click the device and select Catalyst Manager. Cisco CDM opens.
Step 4 In Cisco CDM, create the VLANs you require for the device or edit any existing ports or VLANs. For more information, see Creating a Single Layer 3 Ethernet VLAN, page 14-102.
Step 5 Click Save to save the configuration changes and close Cisco CDM. VPN Manager can now use the new VLANs.
Step 6 In Security Manager, select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 7 Open the Endpoints page to define or edit the VPNSM/VPN SPA settings for the Catalyst 6500/7600 device:
•To create a VPN topology:
–Click Create VPN Topology above the VPNs selector, and select the type of VPN topology to create—Hub and Spoke, Point to Point, or Full Mesh.
The Create VPN wizard displays the Name and Technology page. For a description of the elements on this page, see Table B-4 on page B-10.
–Enter a name and description for the VPN topology, and select the IPSec technology to assign to it, then click Next.
–On the Device Selection page, select the devices for your VPN topology, including the required Catalyst 6500/7600 device. For a description of the elements on the Device Selection page, see Table B-5 on page B-12.
–Click Next. The Endpoints page opens. For a description of the elements on the Endpoints page, see Table B-6 on page B-14.
•To edit a VPN topology:
–In the VPNs selector, right-click the VPN topology that contains your Catalyst 6500/7600 device, and select Edit. The Edit VPN page opens.
–Click the Endpoints tab.
Step 8 Select the row in the table that contains the required Catalyst 6500/7600 device, and click Edit. The Edit Endpoints dialog box displays the VPN Interface tab.
Note You can select more than one Catalyst 6500/7600 device at the same time. Your changes are applied to all selected devices.
Step 9 Configure the VPNSM or VPN SPA settings, as follows:
•To configure a VPNSM:
–In the VPN Interface field, select the inside VLAN you created or edited.
–Select the VPNSM blade slot to which the inside VLAN interface will be connected.
–Select the external port or VLAN to connect to the inside VLAN.
–If required, select a VPNSM blade to serve as a failover blade.
•To configure a VPN SPA:
–In the VPN Interface field, select the inside VLAN you created or edited.
–Select the VPN SPA blade slot number to which the inside VLAN is connected.
–Select the number of the subslot (0 or 1) on which the blade is installed.
–Select the external port or VLAN that will connect to the inside VLAN.
–(Optional) To configure high availability between blades, select the Enable Failover Blade check box. Then select the VPN SPA failover blade slot number, and the number of the subslot (0 or 1) on which the failover blade is installed.
For a description of the elements on the VPN Interface tab, see Table B-8 on page B-22.
Step 10 Click one of the following radio buttons in the Peer IP Address area to define the IP address of the VPN interface of the peer device:
•VPN Interface IP Address—To use the configured IP address on the selected VPN interface.
•IP Address for IPSec Termination—To enter the IP address of the peer device manually. Enter the IP address in the field provided.
•IP Address of Another Existing Interface to be Used as Local Address—To use the configured IP address as a local address on any interface (not necessarily a VPN interface). Enter the interface in the field provided.
You can click Select to choose the required interface. A dialog box displays a list of all available predefined interface roles, and in which you can create an interface role object. For more information, see Editing Interface Role Objects, page 8-124.
Step 11 Click OK to save your changes locally on the client.
The inside VLAN is shown next to the Catalyst 6500/7600 device in the Endpoints table for the selected topology in the Site-to-Site VPN Manager window.
Related Topics
•Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
•Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade
•Defining VPN Services Module (VPNSM) or VPN SPA Settings, page B-21
Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPN SPA
Security Manager supports the configuration of a Firewall Services Module with a VPN Services Module or VPN SPA on a Catalyst 6500/7600 device. This feature enables a Cisco Catalyst 6500/7600 Series Firewall Services Module (FWSM) to apply firewall policies to untrusted clients, while the Cisco Catalyst 6500/7600 IPSec VPN Services Module or VPN SPA provides secure access to the internal network.
For information about configuring a VPN Services Module on a Catalyst 6500/7600 device, see Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface. For information about configuring a VPN SPA blade on a Catalyst 6500/7600 device, see Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade.
To configure FWSM on a Catalyst 6500/7600 device, you must first import the device to your inventory and discover its policies. For more information, see Discovering Policies, page 6-5.
After importing the Catalyst 6500/7600 device, you can create security contexts for it. A security context is an independent virtual firewall that has its own security policies, interfaces, and administrators. A single physical Firewall Services Module can contain multiple security contexts. In Security Manager, you can configure up to three security contexts. For more information, see Security Contexts Page, page C-475.
The next step in configuring FWSM with VPNSM or VPN SPA, is to open Cisco Catalyst Device Manager (Cisco CDM) and discover the Firewall Services Module (FWSM) configurations on the device. If an inside interface is not already created on the Catalyst 6500/7600 device, you must create it using Cisco CDM (see Creating a Single Layer 3 Ethernet VLAN, page 14-102). Then, you must assign the FWSM inside interface (VLAN) to the appropriate security context, or directly to the FWSM blade.
After creating the FWSM inside interface for your device, you must specify FWSM settings on the device, using the Site-to-Site VPN Manager. You configure the following settings during the creation or editing of your VPN topology:
•The VLAN which serves as the inside interface to the FWSM.
•The FWSM blade to which the Firewall inside VLAN is connected.
•If defined, the security context to which the inside VLAN is connected.
This procedure describes how to configure a Firewall Services Module on a Catalyst 6500/7600 device.
Before You Begin:
•If the required Catalyst 6500/7600 device is not already in the Security Manager inventory, import it into the inventory and define (or discover) its security contexts. See Adding Catalyst 6500/7600 Devices from the Network, page 5-42 and Security Contexts Page, page C-475.
Procedure
Step 1 Select View > Device View or click the Device View button on the toolbar.
Step 2 Select your Catalyst 6500/7600 device from the Device selector.
Step 3 Right-click the device and select Catalyst Device Manager. Wait for Cisco CDM to open.
Step 4 In Cisco CDM:
a. Run a discovery for FWSM configurations on the device. See Discovering Policies, page 6-5.
b. Select or create the VLAN that will serve as the inside interface to the FWSM, and assign it to the appropriate security context, or directly to the FWSM blade.
c. Click Save to save the configuration changes and close Cisco CDM. The VLANs configuration can now be used by the VPN Manager.
Step 5 In Security Manager, select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 6 Open the Endpoints page, as follows:
•If you are creating a VPN topology:
–Click Create VPN Topology above the VPNs selector and select the type of VPN topology you want to create—Hub and Spoke, Point to Point, or Full Mesh.
The Create VPN wizard opens, displaying the Name and Technology page. For a description of the elements on this page, see Table B-4 on page B-10.
–Enter a name and description for the VPN topology, and select the IPSec technology that will be assigned to it, then click Next.
–On the Device Selection page, select the devices that will be included in your VPN topology, including the required Catalyst 6500/7600 device. For a description of the elements on the Device Selection page, see Table B-5 on page B-12.
–Click Next. The Endpoints page opens. For a description of the elements on the Endpoints page, see Table B-6 on page B-14.
•If you are editing a VPN topology:
–In the VPNs selector, right-click the VPN topology which contains your Catalyst 6500/7600 device, and select Edit. The Edit VPN page opens.
–Click the Endpoints tab.
Step 7 Select the row in the table that contains the required Catalyst 6500/7600 device, and click Edit. The Edit Endpoints dialog box opens.
Note You can select more than one Catalyst 6500/7600 device at a time for editing. The changes you make can be applied to all the selected devices.
Step 8 In the VPN Interface tab, configure the VPNSM or VPN SPA settings. For a description of the elements on this tab, see Table B-8 on page B-22.
Step 9 Click the FWSM tab, and configure the FWSM settings, as follows. For a description of the elements on this tab, see Table B-10 on page B-28.
a. Select the Enable FWSM Settings check box.
b. Specify the Firewall inside VLAN you created or edited in Cisco CDM.
c. Select the FWSM blade number to which the inside VLAN interface is connected.
d. If the inside VLAN is part of a security context, specify its name in the Security Context field. The name is case-sensitive.
Step 10 Click OK to save your changes locally on the client.
Related Topics
•FWSM Tab, page B-26
•Defining the Endpoints and Protected Networks
•Configuring a Catalyst VPN Services Module (VPNSM) VPN Interface
•Configuring a Catalyst VPN Shared Port Adapter (VPN SPA) Blade
•Adding Devices to the Security Manager Inventory, page 5-29
•Creating a Single Layer 3 Ethernet VLAN, page 14-102
Understanding VRF-Aware IPSec
Note For the procedure to configure VRF-Aware IPSec on a hub in your hub-and-spoke VPN topology, see Configuring VRF-Aware IPSec Settings.
One obstacle to successfully deploying peer-to-peer VPNs is the separation of routing tables, and the use of overlapping addresses, which usually results from using private IP addresses in customer networks. The VRF-Aware IPSec feature, which introduces IPSec tunnel mapping to Multiprotocol Label Switching (MPLS) VPNs, solves this problem.
The VRF-Aware IPSec feature enables you to map IPSec tunnels to Virtual Routing Forwarding (VRF) instances, using a single public-facing address. A VRF instance defines the VPN membership of a customer site attached to the Provider Edge (PE) router. A VRF comprises an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table. A set of routing and CEF tables is maintained for each VPN customer across the MPLS/VPN network.
Since each VPN has its own routing and forwarding table in the router, any customer or site that belongs to a VPN is provided access only to the set of routes contained within that table. Any PE router maintains a number of routing tables and a global routing table per VPN, which can be used to reach other routers in the provider network. Effectively, a number of virtual routers are created in a single physical router. Across the MPLS core to the other PE routers, this routing separation is maintained by adding unique VPN identifiers, such as the route distinguisher (RD).
Note VRF-Aware IPSec can also be configured on devices in a remote access VPN. For more information, see Understanding IPSec Proposals in Remote Access VPNs, page 10-9.
In Security Manager, you can configure VRF-Aware IPSec in your hub-and spoke VPN topology, with either a single device providing all functionality ("one-box" solution) or with multiple devices, each providing a part of the functionality ("two-box" solution). The solution of one device providing all the functionality can affect performance by overloading the system, whereas separating the functionality provides better scaling for each function.
The following topics describe:
•VRF-Aware IPSec One-Box Solution
•VRF-Aware IPSec Two-Box Solution
VRF-Aware IPSec One-Box Solution
In the one-box solution, IPSec tunnels terminate on a Cisco IOS router, which serves as the Provider Edge (PE) device. The PE device maps these tunnels to the appropriate MPLS/VPN network and serves as the IPSec Aggregator, by performing IPSec encryption and decryption from the Customer Edge (CE) devices.
Note The configuration of routing between the PE device and the MPLS cloud is done by Cisco IP Solution Center. See the Cisco IP Solution Center MPLS VPN User Guide at this URL: http://www.cisco.com/en/US/partner/products/sw/netmgtsw/ps4748/products_user_guide_chapter09186a008019abbf.html
Figure 9-4 shows the architectural topology of a one-box solution.
Figure 9-4 VRF-Aware IPSec One-Box Solution
Related Topics
•Understanding VRF-Aware IPSec
•Configuring VRF-Aware IPSec Settings
•Defining the Endpoints and Protected Networks
VRF-Aware IPSec Two-Box Solution
In the two-box solution, the PE device does just the MPLS mapping, while a separate IPSec Aggregator device does the IPSec encryption and decryption from the CEs.
Note Security Manager fully manages the IPSec Aggregator, including routing to the PE device. The PE device is fully managed by Cisco IP Solution Center. This includes routing between the PE device and the MPLS cloud, and routing from the PE to the IPSec Aggregator. For more information, see the Cisco IP Solution Center MPLS VPN User Guide at this URL: http://www.cisco.com/en/US/partner/products/sw/netmgtsw/ps4748/products_user_guide_chapter09186a008019abbf.html
Figure 9-5 shows the architectural topology of a two-box solution.
Figure 9-5 VRF-Aware IPSec Two-Box Solution
Using the two-box solution, you configure VRF-Aware IPSec on devices in your VPN topology, as follows:
1. Configure the connection between the IPSec Aggregator and the PE device.
Create a hub-and-spoke VPN topology and assign an IPSec technology to it. In this topology, the hub is the IPSec Aggregator, and the spokes may be Cisco IOS routers, PIX Firewalls, Catalyst VPN service modules, or Adaptive Security Appliance (ASA) devices. The IPSec Aggregator may be a security router or a Catalyst VPN service module. You then define the VRF parameters (VRF name and unique routing identifier) on the hub.
Note VRF-Aware IPSec supports the configuration of IPSec, GRE, or Easy VPN technologies on Cisco IOS routers and Catalyst VPN service modules. DMVPN is also supported, but only on Cisco IOS routers.
2. Specify the VRF forwarding interface (or VLAN for a Catalyst VPN service module) between the IPSec Aggregator and the PE device.
3. Define the routing protocol and autonomous system (AS) number to be used between the IPSec Aggregator and the PE. Available routing protocols include BGP, EIGRP, OSPF, RIPv2, and Static Route.
If the routing protocol defined between the IPSec Aggregator and the PE differs from the routing protocol used for the secured IGP, routing will be redistributed to the secured IGP, using this routing protocol and AS number. Routing is also redistributed from the secured IGP to the PE.
Note Redistributing the routing is only relevant when GRE or DMVPN is the selected technology.
Related Topics
•Understanding VRF-Aware IPSec
•Configuring VRF-Aware IPSec Settings
•Defining the Endpoints and Protected Networks
Configuring VRF-Aware IPSec Settings
Note For a description of the VRF-Aware IPSec feature, see Understanding VRF-Aware IPSec.
Follow the procedure below to configure VRF-Aware IPSec on a hub in a hub-and-spoke topology.
Before You Begin
•Create your hub-and-spoke VPN topology. See Creating a VPN Topology.
•Before you configure VRF-Aware IPSec on your devices, you should be aware of the following:
–VRF-Aware IPSec may be configured only on hubs in a hub-and-spoke VPN topology.
–You cannot configure VRF-Aware IPSec on a device that belongs to another VPN topology in which VRF-Aware IPSec is not configured.
–You cannot configure VRF-Aware IPSec on hubs that have been configured with high availability. See Understanding High Availability.
–Deployment may fail if the IPSec Aggregator is configured with a keyring CLI command that is the same as the existing preshared key (keyring) command, and is not referenced by any other command. In this case, Security Manager does not use the VRF keyring CLI, but generates the keyring with a different name, causing deployment to fail. You must manually remove the preshared key keyring command through the CLI, before you can deploy the configuration.
Procedure
Step 1 In the Site-to-Site VPN Manager window, right-click the hub-and-spoke VPN topology on which you want to configure VRF-Aware IPSec, and click Edit. The Edit VPN dialog box opens.
Step 2 Click the Endpoints tab. For a description of the elements on the Endpoints tab, see Table B-6 on page B-14.
Step 3 Select the row in the Endpoints table that contains the required hub device (the IPSec Aggregator) and click Edit. The Edit Endpoints dialog box opens.
Note You can select more than one hub for editing. The configuration changes can be applied to all selected devices.
Step 4 Click the VRF Aware IPSec tab in the Edit Endpoints dialog box. For a description of the elements on the VRF Aware IPSec tab, see Table B-11 on page B-30.
Step 5 Select the Enable VRF Settings check box to enable the configuration of VRF settings on the hub(s) for the selected hub-and-spoke topology.
Note To remove previously defined VRF settings, deselect the Enable VRF Settings check box.
Step 6 Select the 1-Box or 2-Box radio button, depending on the solution you want to configure.
In the one-box solution, one device serves as the Provider Edge (PE) router that does the MPLS tagging of the packets in addition to IPSec encryption and decryption from the Customer Edge (CE) devices. See VRF-Aware IPSec One-Box Solution.
In the two-box solution, the PE device does just the MPLS tagging, while the IPSec Aggregator device does the IPSec encryption and decryption from the CEs. See VRF-Aware IPSec Two-Box Solution.
Step 7 Enter the name of the VRF routing table and its unique route distinguisher in the appropriate fields. The VRF name is case-sensitive.
Step 8 If you are configuring a two-box solution, select the VRF forwarding interface (or VLAN) between the IPSec Aggregator (hub) and the PE device.
Note If the IPSec Aggregator is a Catalyst VPN service module (VPNSM) or VPN SPA, you select a VLAN.
Step 9 Select the routing protocol and specify the AS number to be used between the IPSec Aggregator and the PE. In the one-box solution, only the BGP protocol is supported.
If the routing protocol used for the secured IGP differs from the routing protocol between the IPSec Aggregator and the PE, the routing is redistributed to the secured IGP. Routing is also redistributed from the secured IGP to the PE. This applies if GRE or DMVPN is the assigned technology.
Note In a one-box solution, these fields are unavailable as you do not need to specify the routing protocol and AS number.
Step 10 If you are configuring a two-box solution with the OSPF routing protocol, specify the ID number of the area in which the packet belongs.
Step 11 If you are configuring a two-box solution with static routing, you must specify the next hop IP address. This is the IP address of the PE (or the interface that is connected to the IPSec Aggregator).
Step 12 If you are configuring a two-box solution with any routing protocol other than Static route, you can enable static routes to be advertised in the routing protocol configured on the IPSec Aggregator towards the PE device.
Step 13 Click OK to save your changes locally on the client.
Note When you select the new or edited hub-and-spoke topology in the Site-to-Site VPN Manager window, the configuration of a VRF-Aware IPSec policy is displayed in the VPN Summary page. See VPN Summary Page, page B-3.
Related topics
•Defining the Endpoints and Protected Networks
•Understanding VRF-Aware IPSec
•VRF Aware IPSec Tab, page B-28
Understanding High Availability
Note The configuration of High Availability is an optional step of the Create VPN wizard. For the procedure to configure High Availability in your VPN topology, see Configuring High Availability in Your VPN Topology.
High Availability (HA) policies provide automatic device backup when configured on Cisco IOS routers or Catalyst 6500/7600 devices, running IP over LANs. High Availability can be configured only in a hub-and-spoke VPN topology when IPSec is the assigned technology.
In Security Manager, High Availability (HA) is supported by the creation of an HA group made up of two or more hub devices that use Hot Standby Routing Protocol (HSRP) to provide transparent, automatic device failover. By sharing a virtual IP address, the hubs in the HA group present the appearance of a single virtual device or default gateway to the hosts on a LAN. One hub in the HA group is always active and assumes the virtual IP address, while the others are standby hubs. The hubs in the group watch for hello packets from active and standby devices. If the active device becomes unavailable for any reason, a standby hub takes ownership of the virtual IP address and takes over the hub functionality. This transfer is seamless and transparent to hosts on the LAN, and to the peering devices.
Keep the following points in mind when working with HA groups:
•A device in an HA group can belong to more than one hub-and-spoke topology.
•You cannot configure high availability on hubs that have been configured with VRF-Aware IPSec. See Understanding VRF-Aware IPSec.
•GRE cannot be configured on an HA group.
•The same auto-generated preshared key must be used for authentication on all peers. If you specified not to use this option when configuring a preshared key policy, this is overridden during configuration of High Availability. For more information, see Configuring Preshared Key Policies.
•During generation of configurations, all hubs in the HA group receive the same commands, which must be deployed to the HA group as a unit. You cannot deploy to individual hubs in the group.
For each HA group, you must provide the following information:
•The virtual IP address and subnet mask that will be shared by the outside interfaces on the hubs in the group. This virtual IP address will serve as the VPN interface for the tunnel, when a spoke is assigned to the HA group.
•The virtual IP address that will be shared by the inside interfaces on the hubs in the group.
•The interval between each hello message sent by a hub to the other hubs in the group to indicate status and priority.
•The duration (in seconds) that a standby hub will wait to receive a hello message from the active hub before concluding that the hub is down.
For a description of the High Availability tab, on which you can provide this information, see Table B-13 on page B-36.
Enabling Stateful Failover
You can enable stateful failover for your HA groups. With stateful failover, Stateful SwitchOver (SSO) is used to ensure that state information is shared between the HSRP devices in the HA group. If a device fails, the shared state information enables the standby device to maintain IPSec sessions without having to re-establish the tunnel or renegotiate the security associations.
Note•Stateful failover is supported on Cisco IOS routers only.
•Stateful failover cannot be used when RSA Signature is the IKE authentication method.
•An HA group configured with stateful failover cannot contain more than two hubs.
•Stateful failover can only be configured together with PKI configuration, on devices with Cisco IOS version 12.3(14)T and later.
•If you do not enable stateful failover, stateless failover (HSRP without SSO) will be configured on the HA group. Stateless failover is also configured if the HA group contains more than two hubs.
Related Topics
•Creating a VPN Topology
•Configuring High Availability in Your VPN Topology
•Understanding Public Key Infrastructure Policies
Configuring High Availability in Your VPN Topology
Note For a description of the high availability feature, see Understanding High Availability.
This procedure describes the steps required to define a group of hubs as an HA group.
Before You Begin:
•Before you configure High Availability, you should be aware of the following:
–High Availability may be configured only on hubs in a hub-and-spoke VPN topology, when the assigned technology is IPSec.
–You cannot configure High Availability on hubs that have been configured with VRF-Aware IPSec. See Understanding VRF-Aware IPSec.
–You cannot assign GRE in an HA group.
–You can configure high availability only on Cisco IOS routers or Catalyst 6500/7600 devices.
–An HA group cannot contain both Cisco IOS routers and Catalyst 6500/7600 devices.
–If you want to configure stateful failover, the High Availability (HA) group may contain only two hubs which are Cisco IOS routers.
•Create your hub-and-spoke VPN topology. See Creating a VPN Topology.
•Make sure your device selection includes the appropriate devices.
Procedure
Step 1 In the Site-to-Site VPN Manager window, right-click the hub-and-spoke VPN topology on which you want to configure High Availability, and click Edit. The Edit VPN dialog box opens.
Note If you need to first create a hub-and-spoke VPN topology, follow the procedures described in Creating a VPN Topology. You can configure High Availability in the last step of the Create VPN wizard.
Step 2 Click the High Availability tab on the Edit VPN page. For a description of the elements on the High Availability tab, see Table B-13 on page B-36.
Step 3 Select the Enable check box.
Note If you want to remove a previously defined HA group, deselect this check box, then click OK.
Step 4 Enter the virtual IP addresses and masks that represent the inside interface and the VPN interface of the HA group, in the relevant fields. Also enter the hello interval and hold time in seconds.
Step 5 Enter the standby number of the inside hub interface that matches the internal virtual IP subnet, and the outside hub interface that matches the external virtual IP subnet, for the hubs in the HA group. The numbers must be within the range of 0-255.
Note Inside and outside standby group numbers must be different.
Step 6 If required, select the Stateful Failover check box to enable the use of SSO for stateful failover on the HA group. You can only configure stateful failover on an HA group that contains two hubs which are Cisco IOS routers.
Note When this check box is deselected, stateless failover is configured on the HA group. Stateless failover (HSRP without SSO) is also configured if the HA group contains more than two hubs. The hubs can be Cisco IOS routers or Catalyst 6500/7600 devices.
Step 7 Click OK to save your changes locally on the client.
Note When you select the new or edited hub-and-spoke topology in the Site-to-Site VPN Manager window, the VPN Summary page displays the details of the High Availability policy configured. For more information, see VPN Summary Page, page B-3.
Related Topics
•Hub-and-Spoke VPN Topologies
•About Selecting Devices in a VPN Topology
Managing VPN Devices in Device View
Device view provides an easy way to view and edit your VPN topologies at the device level. You can create and delete VPN topologies, edit the properties of a VPN topology, including its device selection, and edit the policies defined for it. You can also view the VPN topology (topologies) to which each device in the Security Manager inventory belongs, and if necessary, change its assignment to or from a VPN topology.
In Security Manager, global objects are used in the definition of some VPN policies. By default, objects are applied identically to every object and policy that references them. However, the definition of certain object types can be overridden at the device level, so that any subsequent changes made to the policy definition at the global level will not affect the device where the object was overridden. Since a VPN policy applies to every device in a VPN topology, you may need to override the object definitions at the device level. For example, when defining a PKI policy, you need to select a PKI enrollment object. If the hub of your VPN uses a different CA server than the spokes, you must use device-level overrides to specify the CA server used by the hub. Although the PKI policy references a single PKI enrollment object, the actual CA server represented by this object will differ for the hub, based on the device-level override you define. For more information about overriding a VPN policy object at the device level, see Overriding Global Objects for Individual Devices, page 8-250.
This procedure describes how to create or edit a VPN topology from Device view.
Procedure
Step 1 Select View > Device View or click the Device View button on the toolbar.
Step 2 Select the required device from the Device selector.
Step 3 Select Site to Site VPN from the Device Policies selector. The Site to Site VPN page opens, displaying a list of VPN topologies to which the selected device belongs. If the device does not belong to a VPN topology, none is displayed. For a description of the elements on this page, see Table B-30 on page B-90.
Step 4 To create a VPN topology to which the selected device will belong:
a. Click Create VPN Topology, and select the type of VPN topology you want to create—Hub and Spoke, Point to Point, or Full Mesh. The first step of the Create VPN wizard opens.
b. Follow the procedure to create a new VPN topology, as described in Creating a VPN Topology. For a description of the elements in the pages of the wizard, see Create VPN Wizard, page B-8.
Step 5 To add or remove the selected device from an existing VPN topology, or edit any other properties:
a. Select the VPN topology in the table, and click Edit VPN Topology. The Edit VPN dialog box opens, displaying the Device Selection tab. For a description of the elements on the Device Selection tab, see Device Selection Page, page B-10.
b. Edit the device structure or any other properties of the VPN topology, as required.
c. When you finish editing the VPN topology, click OK to save your changes locally on the client.
Step 6 To edit the policies defined for a VPN topology:
a. Select the VPN topology in the table, and click Edit VPN Policies. The VPN Summary page opens, displaying information about the VPN topology, including its policies.
b. To edit a policy, select it in the Policies selector. A page opens, on which you can view or edit the parameters for the selected policy.
c. Edit the selected policy, as required. For more information, see Site to Site VPN Policies, page B-37.
Related Topics
•About Editing a VPN Topology
•About Selecting Devices in a VPN Topology
•Managing VPN Devices in Device View
•Working with Site-to-Site VPN Policies
•Create VPN Wizard, page B-8
Working with Site-to-Site VPN Policies
Security Manager supports many policies that are available for site-to-site VPN configuration.
Policies are grouped according to their IPSec technology type. When you assign a technology to a VPN topology, all policies that can be applied to your VPN topology using the assigned technology, become available. For more information about IPSec technologies, see Understanding IPSec Technologies and Policies.
You can view the policies that are can be assigned to a VPN topology in the Site-to-Site VPN Manager window. To open this window, select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. To view the policies, select a VPN topology from the VPNs selector. The policies associated with the selected topology are listed in the lower left pane of the page. Select a policy from the list to view or edit its parameters. For a description of the Site-to-Site VPN Manager window, see Table B-1 on page B-2.
Note You define policies within your own private view. Your definitions are not committed to the database and cannot be seen by other Security Manager users until you submit them.
Working with Site-to-Site VPN Policies in Policy View
You can use Policy view to view all shared policies that have been defined for each policy type in a site-to-site VPN, edit individual policies, and modify their assignments to VPN topologies. See Managing Shared Site-to-Site VPN Policies in Policy View.
Working with Site-to-Site VPN Policies in Device View
In Device view, you can view and edit your VPN topologies at the device level. You can view any VPN topologies to which each device in the Security Manager inventory belongs, and if necessary, change its assignment to or from a VPN topology. For more information, see Managing VPN Devices in Device View.
Note You can right-click a policy in the Policies selector to display menu options that enable you to share the policy, assign the shared policy to, or unassign it from the selected device or VPN topology.
Related Topics
•Understanding Policies, page 6-1
•Working with VPN Topologies
•About Locking in Site-to-Site VPN Topologies
•Site to Site VPN Policies, page B-37
Managing Shared Site-to-Site VPN Policies in Policy View
In Policy view, you can view all shared policies that have been defined for each policy type in a site-to-site VPN, edit their definitions, modify their assignments to VPN topologies, or apply them globally to multiple VPN topologies. You can also create shared policies to assign to VPN topologies later.
This procedure describes how to create or edit site-to-site VPN policies, and modify their assignments to VPN topologies, from Policy view.
Procedure
Step 1 Select View > Policy View or click the Policy View button on the toolbar.
Step 2 Select the Site-to-Site VPN folder from the Policy Type selector in the upper pane. The folder opens, listing the IPSec policy types that can be defined for a site-to-site VPN topology. For more information, see Policy View Selectors, page 6-37.
Step 3 To view the shared policies defined for a policy type, select the policy type in the selector. If any policies are defined for the selected policy type, they will be displayed in the Policies list in the lower pane.
Step 4 To create a shared policy for a policy type:
a. Click Create. The Create a Policy dialog box opens.
b. Enter a name for the new policy and click OK. The new policy appears in the Policies selector for the selected policy type, displaying predefined definitions, which you can edit, if required.
Step 5 To view or edit the policy definition:
a. Select the policy in the Policies selector. The Details tab in the work area of Policy view opens, displaying the policy definitions.
b. If required, modify the definitions for the policy. See Working with Site-to-Site VPN Policies.
Step 6 To view or edit the policy assignment:
a. Select the policy in the Policies selector, and click the Assignments tab in the work area. For a description of the elements on this tab, see Policy View—Assignments Tab, page C-26.
b. If required, modify the list of VPN topologies to which the policy is assigned. See Modifying Policy Assignments in Policy View, page 6-41.
Step 7 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Working with VPN Topologies
•Working with Site-to-Site VPN Policies
•Working with Site-to-Site VPN Policies in Policy View
•Managing Shared Policies in Policy View, page 6-35
Understanding IKE
Note For the procedure to configure an IKE proposal in your VPN topology, see Configuring an IKE Proposal.
Internet Key Exchange (IKE) is a key management protocol that facilitates the management of IPSec-based communications. It is used to authenticate IPSec peers, negotiate and distribute IPSec encryption keys, and automatically establish IPSec security associations (SAs).
The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for other applications, such as IPSec. Both phases use proposals when they negotiate a connection.
Phase 1 negotiation can occur using one of two modes: main mode or aggressive mode:
•Main mode tries to protect all information during the negotiation from potential attackers. In main mode, the identities of the two sides are hidden. While this mode of operation provides the highest security, it takes a long time to complete the negotiation.
•Aggressive mode takes less time to negotiate keys between peers, but is less secure than main mode negotiation. For example, the identities of the two parties trying to establish a security association can be exposed to an eavesdropper.
An IKE proposal is a set of algorithms that two peers use to secure the IKE negotiation between them. IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations. You can create multiple, prioritized policies at each peer to ensure that at least one policy will match a remote peer's policy. You can define several IKE proposals per VPN.
To define an IKE proposal, you must specify:
•Which encryption algorithm to use for the IKE negotiation. See Deciding Which Encryption Algorithm to Use.
•Which hash algorithm to use for integrity checking. See Deciding Which Hash Algorithm to Use.
•Which Diffie-Hellman group to use to operate the encryption algorithm. Deciding Which Diffie-Hellman Group to Use.
•Which device authentication method to use. See Deciding Which Authentication Method to Use.
•For how long the IKE SA will be valid.
Related Topics
•Configuring an IKE Proposal
•IKE Proposal Page, page B-38
Deciding Which Encryption Algorithm to Use
When deciding which encryption and hash algorithms to use for the IKE proposal, your choice is limited to algorithms that are supported by the devices in the VPN.
You can choose from the following encryption algorithms:
•DES (Data Encryption Standard) is a symmetric secret-key block algorithm. It is faster than 3DES and uses less system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, you should choose DES.
•3DES (Triple DES) is more secure because it processes each block of data three times, each time with a different key. However, it uses more system resources and is slower than DES. 3DES is the recommended encryption algorithm, assuming that the devices support it.
•AES (Advanced Encryption Standard) provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192- and 256-bit keys. A longer key provides higher security but a reduction in performance. AES is supported only on routers running IOS version 12.3T and later.
Note AES cannot be used in conjunction with a hardware encryption card.
Related Topics
•Understanding IKE
•Configuring an IKE Proposal
Deciding Which Hash Algorithm to Use
You can choose from the following hash algorithms:
•SHA produces a 160-bit digest, and is more resistant to brute-force attacks than MD5. However, it is also more resource intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.
•MD5 produces a 128-bit digest, and uses less processing time for an overall faster performance than SHA, but it is considered to be weaker than SHA.
Related Topics
•Understanding IKE
•Configuring an IKE Proposal
Deciding Which Diffie-Hellman Group to Use
Security Manager supports Diffie-Hellman group 1, group 2, group 5, and group 7 key derivation algorithms to generate IPSec SA keys. Each group has a different size modulus. A larger modulus provides higher security, but requires more processing time. You must have a matching modulus group on both peers.
•Diffie-Hellman Group 1: 768-bit modulus. Use to generate IPSec SA keys, where the prime and generator numbers are 768 bits.
•Diffie-Hellman Group 2: 1024-bit modulus. Use to generate IPSec SA keys, where the prime and generator numbers are 1024 bits.
•Diffie-Hellman Group 5: 1536-bit modulus. Use to generate IPSec SA keys, where the prime and generator numbers are 2048 bits.
•Diffie-Hellman Group 7: Use to generate IPSec SA keys, when the elliptical curve field size is 163 characters. Group 7 is not supported on a Catalyst 6500/7600 device with VPNSM or VPN SPA configuration.
Related Topics
•Understanding IKE
•Configuring an IKE Proposal
Deciding Which Authentication Method to Use
Security Manager supports two methods for peer device authentication in a VPN communication:
•Preshared Key—Preshared keys allow for a secret key to be shared between two peers and used by IKE during the authentication phase. The same shared key must be configured at each peer or the IKE SA cannot be established.
To use IKE successfully with this device authentication method, you must define various preshared key parameters. For more information, see Understanding Preshared Key Policies.
•RSA Signature—An authentication method in which RSA key pairs are used to sign and encrypt IKE key management messages. RSA Signature provides non-repudiation of communication between two peers, meaning that it can be proved that the communication actually took place. When using this authentication method, peers are configured to obtain digital certificates from a Certification Authority (CA). CAs manage certificate requests and issue certificates to participating IPSec network devices. These services provide centralized key management for the participating devices.
While the use of preshared keys does not scale well, using a CA does improve the manageability and scalability of your IPSec network. With a CA, you do not need to configure keys between all encrypting devices. Instead, each participating device is registered with the CA, and requests a certificate from the CA. Each device that has its own certificate and the public key of the CA can authenticate every other device within a given CA's domain.
To use IKE successfully with the RSA Signature device authentication method, you must define parameters for CA authentication and enrollment. For more information, see Understanding Public Key Infrastructure Policies.
Related Topics
•Understanding IKE
•Configuring an IKE Proposal
Configuring an IKE Proposal
In Security Manager, an IKE proposal is a mandatory policy, with predefined security parameters, that is automatically assigned to a VPN topology. On the IKE Proposal page, you can view the parameters of the selected IKE proposal, select a different one from a list of predefined IKE proposals, or create a new one.
Note For more information about the IKE (Internet Key Exchange) key management protocol, see Understanding IKE.
This procedure describes how to view the parameters of the selected IKE proposal, select a different one from a list of predefined IKE proposals, or create a new one.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select IKE Proposal in the Policies selector.
The IKE Proposal page appears, displaying the assigned IKE proposal with its default values. For a description of the elements on this page, see Table B-14 on page B-39.
Step 4 To assign a different IKE proposal, select it in the Available IKE Proposals list, and click <->. The IKE proposal replaces the one in the Selected IKE Proposal list.
IKE proposals are predefined objects. If the required IKE proposal is not included in the list, click Add to open the IKE Editor dialog box that enables you to create an IKE proposal object. For more information, see IKE Proposal Dialog Box, page C-123.
Note After creating an IKE proposal object, you can modify its properties by selecting it, and clicking Edit.
Step 5 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding IKE
•Understanding Preshared Key Policies
•IKE Proposal Page, page B-38
Understanding IPSec Tunnel Policies
Note For the procedure to configure IPSec proposals in your VPN topology, see Configuring IPSec Proposals.
IPSec is one of the most secure methods for setting up a VPN. IPSec provides data encryption at the IP packet level, offering a robust security solution that is standards-based. Pure IPSec configurations cannot use routing protocols—the policy created is used for pure IPSec provisioning. You can configure pure IPSec on Cisco IOS routers, PIX Firewalls, Catalyst VPN Service Modules, and Adaptive Security Appliance (ASA) devices.
With IPSec, data is transmitted over a public network through tunnels. A tunnel is a secure, logical communication path between two peers. Traffic that enters an IPSec tunnel is secured by a combination of security protocols and algorithms, called a transform set.
In Security Manager, you configure IPSec proposals on devices in your VPN topology. An IPSec proposal is a collection of one or more crypto maps that are applied to the VPN interfaces on the devices.
The following topics describe:
•About Transform Sets
•About Crypto Maps
About Transform Sets
A transform set is a combination of security protocols and algorithms that secure traffic in an IPSec tunnel. During the IPSec security association negotiation, peers search for a transform set that is the same at both peers. When such a transform set is found, it is applied to the traffic as part of both peers' IPSec security associations.
You can specify a number of transform sets per tunnel policy. If you are defining the policy on a spoke or a group of spokes, it is usually not necessary to specify more than one transform set. This is because the spoke's assigned hub would typically be a higher performance router capable of supporting any transform set that the spoke supports. However, if you are defining the policy on a hub for dynamic crypto, you should specify more than one transform set to ensure that there will be a transform set match between the hub and the unknown spoke. You can specify up to six transform sets in a crypto map entry. If more than one of your selected transform sets is supported by both peers, the transform set that provides the highest security is used.
When defining a transform set, you must specify which IPSec mode of operation to use—tunnel mode or transport mode. You can use the AH and ESP protocols to protect an entire IP payload (Tunnel mode) or just the upper-layer protocols of an IP payload (Transport mode).
In tunnel mode (the default), the entire original IP datagram is encrypted, and it becomes the payload in a new IP packet. This mode allows a router to act as an IPSec proxy. That is, the router performs encryption on behalf of the hosts. The source's router encrypts packets and forwards them along the IPSec tunnel. The destination's router decrypts the original IP datagram and forwards it on to the destination system. The major advantage of tunnel mode is that the end systems do not need to be modified to enjoy the benefits of IPSec. Tunnel mode also protects against traffic analysis. With tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.
In transport mode, only the IP payload is encrypted, and the original IP headers are left intact. This mode has the advantage of adding only a few bytes to each packet. It also allows devices on the public network to see the final source and destination of the packet. However, by passing the IP header in the clear, transport mode allows an attacker to perform some traffic analysis. For example, an attacker could see when a company's CEO sent many packets to another senior executive. However, the attacker would only know that IP packets were sent; the attacker would not be able to decipher the contents of the packets. With transport mode, the destination of the flow must be an IPSec termination device.
Note You cannot use transport mode when IPSec or Easy VPN are the assigned technologies.
Security Manager provides predefined transform sets that you can use in your tunnel policies. You can also create your own transform sets. For more information, see Working with IPSec Transform Set Objects, page 8-132.
Related Topics
•Understanding IPSec Tunnel Policies
•About Crypto Maps
•Configuring IPSec Proposals
About Crypto Maps
A crypto map combines all components required to set up IPSec security associations, including IPSec rules, transform sets, remote peer(s), and other parameters that might be necessary to define an IPSec SA. A crypto map entry is a named series of CLI commands. Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set, which is applied to the VPN interfaces on relevant devices. All IP traffic passing through the interface is evaluated against the applied crypto map set.
When two peers try to establish an SA, they must each have at least one compatible crypto map entry. The transform set defined in the crypto map entry is used in the IPSec security negotiation to protect the data flows specified by that crypto map's IPSec rules.
Dynamic crypto map policies are used when an unknown remote peer tries to initiate an IPSec security association with the local hub. The hub cannot be the initiator of the security association negotiation. Dynamic crypto policies allow remote peers to exchange IPSec traffic with a local hub, even if the hub does not know the remote peer's identity. You can create a dynamic crypto policy on individual hubs or on a device group that contains hubs. The policy is written only to the hubs, not to any spokes that might be contained in the group. A dynamic crypto map policy essentially creates a crypto map entry without all the parameters configured. The missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a remote peer's requirements. The peer addresses for dynamic or static crypto maps are deduced from the VPN topology.
Dynamic crypto map policies apply only in a hub-and-spoke VPN configuration—in a point-to-point or full mesh VPN topology, you can apply only static crypto map policies.
Note Security Manager can manage an existing VPN tunnel, only if the tunnel's peers are managed by Security Manager. In such a case, Security Manager uses the same crypto map name for the tunnel on the peers. On subsequent deployments, only Security Manager tunnels are managed (Security Manager maintains a log of all tunnels that were configured).
Related Topics
•Understanding IPSec Tunnel Policies
•About Transform Sets
•Configuring IPSec Proposals
Configuring IPSec Proposals
Note For information about IPSec tunnel policies, see Understanding IPSec Tunnel Policies.
In Security Manager, an IPSec proposal is a policy that you can assign to a VPN topology. In the Site-to-Site VPN Manager window, you can view the predefined IPSec proposal that you can assign to a selected VPN topology. From this page, you can edit the IPSec proposal, if required.
This procedure describes how to edit the parameters of an IPSec proposal.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select IPSec Proposal in the Policies selector.
The IPSec Proposal page appears, displaying the defined parameters for the selected IPSec proposal. For a description of the elements on this page, see Table B-15 on page B-41.
Step 4 Click the Static or Dynamic radio button, depending on the crypto map type.
Step 5 Select the required transform set(s) for your tunnel policy.
The Transform Sets field displays a default transform set. If you want to use a different transform set or select additional transform sets, click Select to open a dialog box that lists all available predefined transform sets, and in which you can create transform set objects. For more information, see Working with IPSec Transform Set Objects, page 8-132.
Note You can select up to six transform sets.
Step 6 Select the PFS check box if you want to generate and use a unique session key for each encrypted exchange. Then select the required Diffie-Hellman key derivation algorithm from the Modulus Group list box.
Step 7 In the Lifetime fields, specify the lifetime settings for the crypto IPSec security association (SA) in seconds, in kilobytes, or both.
Step 8 Select the QoS Preclassify check box if you want to enable Cisco IOS Quality of Service services to operate in conjunction with tunneling and encryption on an interface.
Step 9 Select the Reverse Route check box if you want to enable the Reverse Route Injection (RRI) feature in the IPSec crypto map. Then select one of the following radio buttons:
•Reverse Route—To create a route in the routing table from the host address.
•Reverse Route Remote Peer—To create a route in the routing table for the remote tunnel endpoint. Then in the field provided enter the IP address of the remote peer.
Note Security Manager automatically configures RRI on devices with High Availability (HA), or on the IPSec Aggregator when VRF-Aware IPSec is configured.
Step 10 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding IPSec Tunnel Policies
•IPSec Proposal Page, page B-40
Understanding VPN Global Settings
In Security Manager, you can define VPN global settings that apply to all devices in your VPN topology. These settings include Internet Key Exchange (IKE), IPSec, NAT, and fragmentation definitions.
The following topics describe these global VPN settings:
•Understanding ISAKMP/IPSec Settings
•Understanding NAT
•Understanding Fragmentation
Note For the procedure to configure global settings in your VPN topology, see Configuring VPN Global Settings.
Understanding ISAKMP/IPSec Settings
The Internet Key Exchange (IKE) protocol, also called the Internet Security Association and Key Management Protocol (ISAKMP) is the negotiation protocol that lets two hosts agree on how to build an IPSec security association. Each ISAKMP negotiation is divided into a Phase 1 and Phase 2. Phase 1 creates the first tunnel, that protects ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.
To set terms for ISAKMP negotiations, you create an IKE proposal. For more information, see Configuring an IKE Proposal.
About IKE Keepalive
With IKE keepalive, tunnel peers exchange messages that demonstrate they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals, and any disruption in that interval results in the creation of a new tunnel, using a backup device.
Devices that rely on IKE keepalive for resiliency transmit their keepalive messages regardless of whether they are exchanging other information. These keepalive messages can therefore create a small but additional demand on your network.
A variation on IKE keepalive called keepalive dead-peer detection (DPD) sends keepalive messages between peer devices only when no incoming traffic is received and outbound traffic needs to be sent. If you want to send DPD keepalive messages when no incoming traffic is received regardless of whether there is any outbound traffic, you can specify this using the Periodic option. See ISAKMP/IPSec Settings Tab, page B-45.
Related Topics
•Configuring VPN Global Settings
•ISAKMP/IPSec Settings Tab, page B-45
Understanding NAT
Network Address Translation (NAT) enables devices that use internal IP addresses to send and receive data through the Internet. It converts private, internal LAN addresses into globally routable IP addresses when they try to access data on the Internet. In this way, NAT enables a small number of public IP addresses to provide global connectivity for a large number of hosts.
NAT enhances the stability of your hub-and-spoke VPN tunnels because resources required for VPN connections are not used for other purposes, and the VPN tunnel is kept available for traffic requiring complete security. Sites inside the VPN can use NAT through a split tunnel to exchange non secure traffic with outside devices, and they do not squander VPN bandwidth or overwhelm the hub at the tunnel head-end by directing nonessential traffic through it.
Security Manager supports only NAT with dynamic IP addressing, and applies to it an "overload" feature that permits what is known as port-level NAT or Port Address Translation (PAT). PAT uses port addressing to associate thousands of private NAT addresses with a small group of public IP address. PAT is used if the addressing requirements of your network exceed the available addresses in your dynamic NAT pool.
Note•When you enable PAT on Cisco IOS routers, an additional NAT rule is implicitly created for split-tunneled traffic, on deployment. This NAT rule, which denies VPN-tunneled traffic and permits all other traffic (using the external interface as the IP address pool), will not be reflected as a router platform policy. You can remove the NAT rule by disabling this feature. For more information, see Defining Dynamic NAT Rules, page 12-20.
•If required, you can configure traffic to bypass NAT configuration on site-to-site VPN traffic. To bypass NAT configuration on Cisco IOS routers, make sure the Do Not Translate VPN Traffic check box is enabled in the NAT Dynamic Rule platform policy (see NAT Dynamic Rule Dialog Box, page C-503). To exclude NAT on PIX Firewalls or ASA devices, make sure this check box is enabled in the NAT Translation Options platform policy (see Translation Options Page, page C-232).
About NAT Traversal
NAT traversal is required when there is a device (middle device) located between a VPN-connected hub and spoke, and that device performs NAT on the IPSec flow.
If the IP address of the VPN interface on the spoke is not globally routable, the NAT on the middle device replaces it with a new globally routable IP address. This change is made in the IPSec header, and violates the checksum of the spoke causing a mismatch with the hub's checksum calculation. This results in loss of connectivity between the hub and the spoke.
With NAT traversal, the spoke adds a UDP header to the payload. The NAT on the middle device changes the IP address in the UDP header, leaving the IPSec header and checksum intact. On a middle device that uses static NAT, you must provide the static NAT IP address (globally routable) on the inside interface. The static NAT IP address is provided for all traffic through that interface that requires NAT. However, if the middle device uses dynamic NAT where the NAT IP address is unknown, you must define dynamic crypto on the hub to serve any connection request from the spoke. Security Manager generates the required tunnel configuration for the spoke.
Note NAT traversal is supported on routers running IOS version 12.3T and later.
You can define global NAT settings on the NAT Settings tab of the Global VPN Settings page.
Related Topics
•Configuring VPN Global Settings
•NAT Settings Tab, page B-49
Understanding Fragmentation
Fragmentation breaks a packet into smaller units when it is transmitted over a physical interface that cannot support the original size of the packet. Fragmentation minimizes packet loss in a VPN tunnel, because it enables transmission of secured packets that might otherwise be too large to transmit. This is particularly relevant when using GRE, because any packet of more than 1420 bytes will not have enough room in its header for the additional 80 bytes that the combined use of IPSec and GRE adds to the packet payload.
The maximum transmission unit (MTU) specifies the maximum packet size, in bytes, that an interface can handle. If a packet exceeds the MTU, it is fragmented, typically after encryption. If the DF (Don't Fragment) bit is set, the packet is dropped. A DF bit is a bit within the IP header that indicates if a device can fragment a packet. If you enable the DF feature, you must specify whether the device can clear, set, or copy the DF bit from the encapsulated header.
Because reassembly of an encrypted packet is difficult, fragmentation can degrade network performance. To prevent network performance problems, fragmentation settings configure the device so that fragmentation occurs before encryption.
Security Manager instructs a device to handle packets that are larger than the MTU, either with end-to-end MTU discovery or by setting the MTU on the device.
•MTU Discovery: End-to-end MTU discovery uses Internet Control Message Protocol (ICMP) messages to determine the maximum MTU that a host can use to send a packet through the VPN tunnel without causing fragmentation. The MTU setting for each link in a transmission path is checked to ensure that no transmitted packet exceeds the smallest MTU in that path. The discovered MTU is used to decide whether fragmentation is necessary.
•Local MTU handling: Typically used when ICMP is blocked. You can define an MTU size between 540 and 1500 bytes.
By default, Security Manager uses end-to-end MTU discovery using ICMP messages. If ICMP is blocked, MTU discovery fails and packets are either lost (if the DF bit is set) or fragmented after encryption (if the DF bit is not set).
On the General Settings tab of the VPN Global Settings page, you can define fragmentation settings and enable the DF bit feature on the devices in your VPN topology. For more information, see Table B-18 on page B-52.
Related Topics
•Configuring VPN Global Settings
•General Settings Tab, page B-51
Configuring VPN Global Settings
On the VPN Global Settings page, you can define global settings for IKE, IPSec, NAT, and fragmentation, to apply to devices in your VPN topology. A VPN Global Settings policy applies to any IPSec technology assigned to your VPN topology.
Follow the procedure below to define global settings in your VPN topology.
Note For more information about global VPN settings, see Understanding VPN Global Settings.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select VPN Global Settings in the Policies selector. The VPN Global Settings dialog box opens, displaying the ISAKMP/IPSec Settings tab.
Step 4 In the ISAKMP/IPSec Settings tab, specify global settings for IKE and IPSec. For a description of the elements on this tab, see Table B-16 on page B-46.
Step 5 Click the NAT Settings tab to define global NAT settings that apply to devices that use internal IP addresses to send and receive data through the Internet. For a description of the elements on this tab, see Table B-17 on page B-50.
Step 6 Click the General Settings tab to define fragmentation settings on the devices in your VPN topology. For a description of the elements on this tab, see Table B-18 on page B-52.
Step 7 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding ISAKMP/IPSec Settings
•Understanding NAT
•Understanding Fragmentation
•ISAKMP/IPSec Settings Tab, page B-45
•NAT Settings Tab, page B-49
•General Settings Tab, page B-51
Understanding Preshared Key Policies
Note For the procedure to configure preshared key policies in your VPN topology, see Configuring Preshared Key Policies.
If you want to use preshared key as your authentication method (see Deciding Which Authentication Method to Use), you must define a shared key for each tunnel between two peers, that will be their shared secret for authenticating the connection. The key will be configured on each peer. If the key is not the same on both peers of the tunnel, the connection cannot be established. The peer addresses that are required for configuring the preshared key are deduced from the VPN topology.
Preshared keys are configured on spokes. In a hub-and-spoke VPN topology, Security Manager mirrors the spoke's preshared key and configures it on its assigned hub, so that the key on the spoke and hub are the same. In a point-to-point VPN topology, you must configure the same preshared key on both peers. In a full mesh VPN topology, any two devices that are connected must have the same preshared key.
In a preshared key policy, you can manually specify to use a specific key, or you can use automatically generated keys for peers participating in each communication session. Using automatically generated keys (the default method) is preferred, because security can be compromised if all connections in a VPN use the same preshared key.
There are three methods for negotiating key information and setting up IKE SAs:
•Main mode address—Negotiation is based on IP address. Main mode provides the highest security because it has three two-way exchanges between the initiator and receiver. This is the default negotiation method.
This method has three options for creating keys:
–You can create a key for each peer, based on the unique IP address of each peer, providing high security.
–You can create a group preshared key on a hub in a hub-and-spoke VPN topology, to be used for communication with any device in a specified subnet. Each peer is identified by its subnet, even if the IP address of the device is unknown. In a point-to-point or full mesh VPN topology, a group preshared key is created on the peers.
–You can create a wildcard key on a hub in a hub-and-spoke VPN topology, or on a group containing hubs, to be used for dynamic crypto where a spoke does not have a fixed IP address or belong to a specific subnet. All spokes connecting to the hub have the same preshared key, which could compromise security. In a point-to-point or full mesh VPN topology, a wildcard key is created on the peers.
Note If you are configuring DMVPN with direct spoke-to-spoke connectivity, you create a wildcard key on the spokes.
•Main mode fully qualified domain name (FQDN)—Negotiation is based on DNS resolution, with no reliance on IP address. This option can only be used if the DNS resolution service is available for the host. It is useful when managing devices with dynamic IP addresses that have DNS resolution capabilities.
•Aggressive mode—Negotiation is based on hostname (without DNS resolution) and domain name. Aggressive mode is less secure than main mode. However, it provides more security than using group preshared keys if the IP address of the VPN interface on the host is unknown, and the FQDN of the dynamic IP peer is not DNS resolvable. This negotiation method is recommended for use with a GRE Dynamic IP or DMVPN failover and routing policy.
Related Topics
•Configuring Preshared Key Policies
•Preshared Key Page, page B-54
Configuring Preshared Key Policies
Note For an understanding of preshared key policies, see Understanding Preshared Key Policies.
Follow the procedure below to edit the parameters of a preshared key policy defined for a VPN topology:
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select Preshared Key in the Policies selector.
The Preshared Key page appears, displaying the defined parameters for the selected preshared key policy. For a description of the elements on this page, see Table B-19 on page B-55.
Step 4 Select the required key specification by selecting one of the following radio buttons:
•User Defined—To use a specific preshared key. Then enter the preshared key in the Key field.
•Auto Generated—To automatically generate a random key to the participating peers. Enter the required length of the preshared key to be generated in the Key Length field (maximum of 127 characters).
If required, select one of the following radio buttons:
–Same Key for All Tunnels—To use the same auto-generated key for all tunnels.
Note If you do not select this check box, different keys are used for the tunnels, except in cases, such as DMVPN configuration, when different multipoint GRE interfaces in the same network must use the same preshared key.
–Regenerate Key (Only in Next Deployment)—To generate a new key for the next deployment to the device(s). This is useful if there is a possibility that the secrecy of the keys might be compromised.
Note When you submit the job for deployment, the Regenerate Key check box is cleared. It does not remain selected because the new key will only be generated for the upcoming deployment, not for subsequent deployments (unless you select it again before subsequent deployments).
Step 5 Select the required negotiation method for exchanging key information by clicking one of the following radio buttons:
•Main Mode Address—If the IP address of the devices is known. Then click one of the following radio buttons to define the negotiation address type:
–Peer Address—To create a key for each peer based on the unique IP address of each peer.
–Subnet—To create a group preshared key on a hub, to be used for communication with any device in a specified subnet, even if the IP address of the device is unknown. Each peer is identified by its subnet. Then enter the required key in the field provided.
–Wildcard—To create a wildcard key on a hub or on a group containing hubs, to be used for dynamic crypto when a spoke does not have a fixed IP address or belong to a specific subnet.
•Main Mode FQDN—If the IP address is not known and DNS resolution is available for the device(s).
•Aggressive Mode—If the IP address is not known and DNS resolution might not be available on the devices.
Step 6 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding Preshared Key Policies
•Preshared Key Page, page B-54
Understanding Public Key Infrastructure Policies
Note For the procedure to configure Public Key Infrastructure policies in your VPN topology, see Configuring Public Key Infrastructure Policies.
Security Manager supports IPSec configuration with Certification Authority (CA) servers that manage certificate requests and issue certificates to devices in your VPN topology. You can create a Public Key Infrastructure (PKI) policy to generate enrollment requests for CA certificates and RSA keys, and manage keys and certificates, providing centralized key management for the participating devices.
CA servers, also known as trustpoints, manage public CA certificate requests and issue certificates to participating IPSec network devices. When you use RSA Signature as the device authentication method for IKE and IPSec proposal policies, peers are configured to obtain digital certificates from a CA server. With a CA server, you do not have to configure keys between all the encrypting devices. Instead, you individually enroll each participating device with the CA server, which is explicitly trusted to validate identities and create a digital certificate for the device. When this has been accomplished, each participating peer can validate the identities of the other participating peers and establish encrypted sessions with the public keys contained in the certificates.
CAs can also revoke certificates for peers that no longer participate in an IPSec VPN topology. Revoked certificates are either managed by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation list (CRL) stored on an LDAP server, which each peer can check before accepting a certificate from another peer.
PKI enrollment can be set up in a hierarchical framework consisting of multiple CAs. At the top of the hierarchy is a root CA, which holds a self-signed certificate. The trust within the entire hierarchy is derived from the RSA key pair of the root CA. Subordinate CAs within the hierarchy can enroll with either the root CA or with another subordinate CA. Within a hierarchical PKI, all enrolled peers can validate each other's certificate if the peers share a trusted root CA certificate or a common subordinate CA.
Note•PKI policies may be configured on Cisco IOS routers, PIX Firewalls, and Adaptive Security Appliance (ASA) devices.
•Security Manager only supports PKI configuration on devices with Cisco IOS version 12.3(7)T and later.
•To save the RSA key pairs and the CA certificates between reloads permanently to Flash memory on a PIX Firewall version 6.3, you must configure the "ca save all" command. You can do this manually on the device or using a FlexConfig (see Working with FlexConfigs, page 16-40).
•PKI policies may also be configured on devices in a remote access VPN. For more information, see Public Key Infrastructure Policies in Remote Access VPNs, page 10-18.
CA Server Authentication Methods
You can authenticate the CA server using one of the following methods:
•Using the Simple Certificate Enrollment Protocol (SCEP) to retrieve the CA's certificates from the CA server. Using SCEP, you establish a direct connection between your device and the CA server. Be sure your device is connected to the CA server before beginning the enrollment process. Since this method of retrieving CA certificates for routers is interactive, you can deploy your PKI policy to live devices only, not to files.
Note When using SCEP, you must enter the fingerprint for the CA server. If the value you enter does not match the fingerprint on the certificate, the certificate is rejected. You can obtain the CA's fingerprint by contacting the server directly, or by entering the following address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll.
•Manually creating an enrollment request that you can submit to a CA server offline, by copying the CA server's certificates from another device.
Use this method if your device cannot establish a direct connection to the CA server or if you want to generate an enrollment request and send it to the server at a later time.
Note This method enables you to deploy the PKI policy either to devices or to files.
For more information, see PKI Enrollment Dialog Box, page C-140.
Note You can also use Cisco Secure Device Provisioning (SDP) to enroll for a certificate. For more information about using SDP for certificate enrollment, see Configuring Secure Device Provisioning on Cisco IOS Routers, page 12-35.
The following topic describes:
•Prerequisites for Successful PKI Enrollment
Related Topics
•Configuring Public Key Infrastructure Policies
•Working with PKI Enrollment Objects, page 8-153
•Public Key Infrastructure Page, page B-58
Prerequisites for Successful PKI Enrollment
The following are prerequisites for configuring a PKI policy in your network:
•The IKE authentication method used with CA can only be RSA Signature.
•The domain name must be defined on the devices for PKI enrollment to be successful (unless you specify the CA server nickname).
•To enroll with the CA server directly, you must specify the server's enrollment URL.
•To enroll with the CA server by means of a TFTP server, you must ensure that the CA certificates file is saved to the TFTP server. After deployment of the PKI policy, you must copy the certificate request from your TFTP server to the CA server. For more information, see Prerequisites for PKI Enrollment Using TFTP.
•When configuring a trustpoint, you must specify one of the Certificate Revocation List (CRL) checking options. For more information, see Defining CA Server Properties, page 8-157.
•You may specify an RSA public key to use in the enrollment request. If you do not specify an RSA key pair, the Fully Qualified domain Name (FQDN) key will be used.
If using RSA keys, once the certificate has been granted, the public key is included in the certificate so that peers can use it to encrypt data sent to the device. The private key is kept on the device and used to decrypt data sent by peers, and to digitally sign transactions when negotiating with peers. You can use an existing key pair or generate a new one. If you want to generate a new key pair to use in the certificate for router devices, you must also specify the modulus to determine the size of the key.
For more information, see Defining PKI Enrollment Parameters, page 8-159.
•If you are making a PKI enrollment request on a Cisco Easy VPN IPSec remote access system, you must configure each remote component (spoke) with the name of the user group to which it connects. You specify this information in the Organization Unit (OU) field in the Certificate Subject Name tab of the PKI Enrollment Editor dialog box.
Note You do not need to configure the name of the user group on the hub (Easy VPN Server).
For more information, see Defining Additional PKI Attributes, page 8-162.
•To deploy PKI policies to files (not to live devices), the following prerequisites must be met:
–Devices must have IOS 12.3(7)T or later (trustpoint PKI devices).
–CA authentication certificates must be cut and pasted into the Security Manager user interface (so that CA authentication is not interactive and does not require communication with the live device).
•If you are deploying to live devices, the PKI server must be online.
•Security Manager supports the Microsoft, Verisign, and Entrust PKIs.
•Security Manager supports Cisco IOS Certificate Servers. The Cisco IOS Certificate Server feature embeds a simple certificate server, with limited CA functionality, into the Cisco IOS software. An IOS Certificate Server can be configured as a FlexConfig policy. For more information, see Working with FlexConfigs, page 16-40.
Prerequisites for PKI Enrollment Using TFTP
If you do not have constant direct access to the CA server, you can enroll using TFTP, if your devices are routers running IOS 12.3(7)T or later.
On deployment, Security Manager generates the corresponding CA trustpoint command and authenticate command. The trustpoint command is configured with the enrollment URL tftp://<certserver> <file_specification> entry to retrieve the CA certificate using TFTP. If the file_specification is not specified, the FQDN of the router is used.
Before using this option, you must make sure that the CA certificates file (.ca) is saved on the TFTP server. To do this, use this procedure:
1. Connect to http://servername/certsrv, where servername is the name of the Windows 2000 web server on which the CA you want to access is located.
2. Select Retrieve the CA certificate or certificate revocation list, then click Next.
3. Select Base64 encoded, then click Download CA certificate.
4. Save the .crt file as a .ca file on the TFTP server using your browser's Save As function.
After deployment, you must transfer the certificate request generated by Security Manager on the TFTP server to the CA, and then transfer the device's certificates from the CA to the device.
Transferring the Certificate Request from the TFTP Server to the CA Server
Security Manager creates a PKCS#10 formatted enrollment request (.req) on the TFTP server. You must transfer it to the PKI server using this procedure:
1. Connect to http://servername/certsrv, where servername is the name of the Windows 2000 Web server where the CA you want to access is located.
2. Select Request a certificate, then click Next.
3. Select Advanced request, then click Next.
4. Select Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file, then click Next.
5. Either select browse for a file (and browse to the TFTP server and select the .req file) or open the just received by TFTP .req file with WordPad/Notepad and copy/paste the contents in the first window.
6. Export the .crt file from the CA and put it on the TFTP server.
7. Configure the 'crypto ca import <label> certificate' to import the device's certificates from the tftp server.
Related Topics
•Configuring Public Key Infrastructure Policies
•Working with PKI Enrollment Objects, page 8-153
•Public Key Infrastructure Page, page B-58
•Configuring a User Group Policy for Easy VPN
Configuring Public Key Infrastructure Policies
You can create a Public Key Infrastructure (PKI) policy to generate enrollment requests for CA certificates and RSA keys, and to manage keys and certificates. Certification Authority (CA) servers are used to manage these certificate requests and issue certificates to the participating devices in your VPN topology.
In Security Manager, CA servers are predefined as PKI enrollment objects that you can use in your PKI policies. A PKI enrollment object contains the server information and enrollment parameters that are required for creating enrollment requests for CA certificates.
Note For more information about Public Key Infrastructure policies, see Understanding Public Key Infrastructure Policies.
This procedure describes how to specify the CA server that will be used to create a Public Key Infrastructure (PKI) policy, in your VPN topology.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure the devices on which you are configuring PKI have IOS versions 12.3(7)T and later.
•Please read Prerequisites for Successful PKI Enrollment.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select Public Key Infrastructure in the Policies selector. The Public Key Infrastructure page opens, displaying the currently selected CA server. For a description of the elements on this page, see Table B-20 on page B-59.
Step 4 If you want to assign a different CA server, select it in the Available CA Servers list. The CA server replaces the one in the Selected field.
CA servers are predefined as PKI enrollments objects. If the required CA server is not included in the list, click Create to open a dialog box that enables you to create a PKI enrollment object. For more information, see PKI Enrollment Dialog Box, page C-140.
Note After creating a PKI enrollment object, you can modify its properties by selecting it, and clicking Edit.
Step 5 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Note To save the RSA key pairs and the CA certificates between reloads permanently to Flash memory on a PIX Firewall version 6.3, you must configure the "ca save all" command. You can do this manually on the device or using a FlexConfig (see Working with FlexConfigs, page 16-40).
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding Public Key Infrastructure Policies
•Working with PKI Enrollment Objects, page 8-153
•Deciding Which Authentication Method to Use
•Public Key Infrastructure Page, page B-58
Understanding GRE
Note For the procedure to configure GRE policies in your VPN topology, see Configuring GRE or GRE Dynamic IP Policies.
Generic Routing Encapsulation (GRE) is a tunneling protocol that encapsulates a variety of protocol packet types inside IP tunnels, creating a virtual point-to-point connection to devices at remote points over an IP network. With this technology, GRE encapsulates the entire original packet with a standard IP header and GRE header before the IPSec process. Then, IPSec views the GRE packet as an unremarkable IP packet and performs encryption and authentication services, as dictated by the IKE negotiated parameters. Because GRE can carry multicast and broadcast traffic, it is possible to configure a routing protocol for virtual GRE tunnels. The routing protocol detects loss of connectivity and reroutes packets to the backup GRE tunnel, thus providing high resiliency.
For VPN resilience, a spoke must be configured with two GRE tunnels, one to the primary hub and the other to the backup hub. Both GRE tunnels are secured with IPSec: each one has its own IKE SA and a pair of IPSec SAs. An associated routing protocol automates the failover mechanism, transferring to the backup tunnel if virtual link loss is detected.
Note GRE can be configured on Cisco IOS security routers and Catalyst 6500/7600 devices in hub-and-spoke, point-to-point, and full mesh VPN topologies.
Advantages of IPSec Tunneling with GRE
The main advantages of IPSec tunneling with GRE are:
•GRE uses a routing protocol by which every IPSec peer knows the status of every other peer at all times.
•GRE provides higher resiliency than IKE keepalive (see About IKE Keepalive).
•Spoke-to-spoke connectivity is supported when you use GRE.
•GRE supports multicast and broadcast transmissions.
Note GRE does not support the use of dynamic cryptographic tunnels.
How Does Security Manager Implement GRE?
Security Manager implements a double Interior Gateway Protocol (IGP) solution for GRE. An IGP refers to a group of devices that receive routing updates from one another by a routing protocol, EIGRP, OSPF, or RIP. Each "routing group" is identified by a logical number. For general routing purposes, the interfaces on the routers in your networks belong to an IGP. Security Manager adds an additional IGP that is dedicated for IPSec and GRE-secured communication. This additional IGP is the secured IGP. The existing IGP (unsecured IGP), is used for routing traffic that does not require encryption.
When a GRE tunnel is established, a virtual interface is configured on each device. These virtual interfaces are the endpoints of the GRE tunnel. Each virtual interface is unique and is assigned with its own crypto map. The GRE tunnel interface has an IP address (inside tunnel IP address) which is taken from a loopback interface that Security Manager creates. The GRE tunnel points to the source and destination IP addresses of the physical VPN interfaces on the hub and spoke. The GRE virtual interfaces on the hub and its assigned spokes belong to the secured IGP, as do the inside interfaces you defined for the hub and spoke. Routing updates within the secured IGP are GRE encapsulated and IPSec is applied. A flow whose destination is a secured interface (according to the routing updates of the secured IGP) is directed through the GRE interface where it is GRE encapsulated and then evaluated against the crypto ACL. If it matches the crypto ACL, it is routed through the GRE and VPN tunnels.
Prerequisites for Successful Configuration of GRE
Consider the following prerequisites before using GRE in your network:
•You must identify the inside interfaces on your devices—the physical interfaces on the device that connect the device with its internal subnets and networks.
•You must select a routing protocol (known as an Interior Gateway Protocol (IGP) or a static route, whenever you enable GRE.
Security Manager supports the EIGRP, OSPF, and RIPv2 dynamic routing protocols, and GRE static routes.
–EIGRP—Enhanced Interior Gateway Routing Protocol enables the exchange of routing information within an autonomous system and addresses some of the more difficult issues associated with routing in large, heterogeneous networks. Compared to other protocols, EIGRP provides superior convergence properties and operating efficiency, and combines the advantages of several different protocols.
–OSPF—Open Shortest Path First is a link-state, hierarchical protocol that features least-cost routing, multipath routing, and load balancing.
Using OSPF, a host that obtains a change to a routing table or detects a change in the network immediately multicasts the information to all other hosts in the network, so that all will have the same routing table information.
–RIPv2—Routing Information Protocol is a distance-vector protocol that sends routing-update messages at regular intervals and whenever the network topology changes.
Using RIPv2, a gateway host (with a router) sends its entire routing table to its closest neighbor host every 30 seconds, which in turn passes the information on to its next neighbor, and so on, until all hosts within the network have the same knowledge of routing paths. RIPv2 uses a hop count to determine network distance. Each host with a router in the network uses the routing table information to determine the next host to route a packet to for a specified destination.
RIP is considered an effective solution for small homogeneous networks. For larger, more complicated networks, RIP's transmission of the entire routing table every 30 seconds may put a heavy amount of extra traffic in the network.
–Static route—Use a static routing policy to provide a robust, stable IPSec-protected GRE tunnel if there is a fixed, unchanging route between two devices. For each of the device subnets, a static route is created on the device pointing to the corresponding tunnel interface.
For more information about routing protocols, see Chapter 12, "Managing Routers".
•You must specify an IGP process number. The IGP process number identifies the IGP process to which the inside interface on the device belongs. When GRE is implemented, this will be the secured IGP. For secure communication, the inside interfaces on the devices in your VPN must use the same IGP process. The IGP process number must be within a specified range. If you have an existing IGP process on the device that is within this range, but is different from the IGP process number specified in your GRE settings, Security Manager removes the existing IGP process. If the existing IGP process matches the one specified in your GRE settings, any networks included in the existing IGP process that do not match the specified inside interfaces are removed.
•If the inside interfaces on your devices are configured to use an IGP process other than the IGP process specified in your GRE settings (meaning that the interfaces belong to an unsecured IGP):
–For spokes: Manually remove the inside interfaces from the unsecured IGP through the device CLI before configuring GRE.
–For hubs: If the hub inside interface is used as a network access point for Security Manager, then on deployment, the interface is advertised in both secured and unsecured IGPs. To ensure that the spoke peers use only the secured IGP, manually add the auto-summary command for the unsecured IGP or remove the unsecured IGP for that inside interface.
•You must provide a subnet that is unique yet it can be non-globally-routable for loopback. This subnet must only be used to support the implementation of loopback for GRE. The loopback interfaces are created, maintained, and used only by Security Manager. You should not use them for any other purpose.
•If you are using static routes, not unsecured IGP, make sure you configure static routes on the spokes through to the hub inside interfaces.
Note You can configure the above settings in the GRE Modes page when GRE is the selected IPSec technology. See Understanding IPSec Technologies and Policies.
Related Topics
•GRE Modes Page, page B-60
•Understanding GRE Configuration for Dynamically Addressed Spokes
•Configuring GRE or GRE Dynamic IP Policies
Understanding GRE Configuration for Dynamically Addressed Spokes
Note For the procedure to configure GRE Dynamic IP policies in your VPN topology, see Configuring GRE or GRE Dynamic IP Policies.
When a spoke has a dynamic IP address, there is no fixed GRE tunnel source address (to be used by the GRE tunnel on the spoke side) or destination address (to be used by the GRE tunnel on the hub side). Therefore, Security Manager creates additional loopback interfaces on the hub and the spoke, to be used as the GRE tunnel endpoints. You must specify a subnet from which Security Manager can allocate an IP address for the loopback interfaces.
Note GRE Dynamic IP can only be configured on Cisco IOS routers and Catalyst 6500/7600 devices in hub-and-spoke VPN topologies.
Security Manager uses the Cisco Configuration Engine (Cisco CE) to retrieve device IP addresses and other information from dynamically addressed devices. Cisco IOS routers and PIX Firewalls that have dynamic IP addresses connect to the Cisco CE manager at periodic intervals to upgrade device configuration files and to pass device and status information.
For more information, see Understanding Auto Update Server and Configuration Engine, page 5-64.
Note You can configure the GRE Dynamic IP settings in the GRE Modes page when GRE Dynamic IP is the selected IPSec technology. See Understanding IPSec Technologies and Policies.
Related Topics
•Understanding GRE
•Configuring GRE or GRE Dynamic IP Policies
•GRE Modes Page, page B-60
Configuring GRE or GRE Dynamic IP Policies
Note For an understanding of GRE and GRE Dynamic IP policies, see Understanding GRE and Understanding GRE Configuration for Dynamically Addressed Spokes.
Follow the procedure below to configure IPSec tunneling with GRE or GRE Dynamic IP in your site-to-site VPN.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure that the selected IPSec technology is GRE or GRE Dynamic IP. For more information, see Understanding IPSec Technologies and Policies.
•Please read the following topic:
–Prerequisites for Successful Configuration of GRE
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select GRE Modes in the Policies selector.
The GRE Modes page opens to display the fields that are relevant for the selected IPSec technology—GRE or GRE Dynamic IP. For a description of the elements on the GRE Modes page for a GRE or GRE Dynamic IP policy, see Table B-21 on page B-61.
Step 4 In the Routing Parameters tab, Select the required dynamic routing protocol (EIGRP, OSPF, or RIPv2), or static route to be used for your GRE or GRE Dynamic IP tunnel.
a. If you selected the EIGRP routing protocol:
–Enter or edit the number that will be used to identify the autonomous system (AS) area to which the EIGRP packet belongs. The default number is 110.
–Specify the interval between hello packets sent on the interface, and the number of seconds the router will wait to receive a hello message before invalidating the connection.
–Specify the throughput delay for the primary route interface (default is 1000) and the failover route interface (default is 1500), in microseconds.
b. If you selected the OSPF routing protocol:
–Enter the routing process ID number that will be used to identify the secured IGP that Security Manager adds when configuring GRE or GRE Dynamic IP.
–Enter the ID number of the area in which the hub's protected networks will be advertised, including the tunnel subnet. The default is 1.
–Enter the ID number of the area in which the remote protected networks will be advertised, including the tunnel subnet. The default is 2.
–Enter a string that specifies the OSPF authentication key (up to eight characters long).
–Specify the cost of sending a packet on the primary route interface (default 100) and the secondary (failover) route interface (default 125).
c. If you selected the RIPv2 routing protocol:
–Enter a string that specifies the RIPv2 authentication key (up to eight characters long).
–Specify the cost of sending a packet on the primary route interface (default 100) and the secondary (failover) route interface (default 125).
Note Security Manager adds a routing protocol to all the devices in the secured IGP, on deployment. If you want to maintain this secured IGP, you must create a router platform policy using the same routing protocol, and autonomous system (or process ID) number defined here. For instructions on how to define routing policies for the different protocols, see Chapter 12, "Managing Routers".
Step 5 If required, select the Filter Dynamic Updates on Spokes check box to enable the creation of a redistribution list that filters all dynamic routing updates on spokes.
Step 6 Select the Tunnel Parameters tab, then do the following:
a. Click one of the following radio buttons to specify the GRE or GRE Dynamic IP tunnel interface IP address:
–Use Physical Interface—To use the private IP address of the tunnel taken from the protected network.
–Use Subnet—To use the tunnel IP address taken from an IP range. Then, in the Subnet field, enter the private IP address including the unique subnet mask, for example 10.1.1.0/24. If you are also configuring a dial backup interface, enter its subnet in the Dial Backup Subnet field provided.
–Use Loopback Interface—To use the tunnel IP address taken from an existing loopback interface. Then, in the Role field, enter the interface, or select it from the list of interface roles provided.
b. If the assigned IPSec technology is GRE Dynamic IP, enter the private IP address including the unique subnet mask that supports the loopback for GRE.
c. Select the Enable IP Multicast check box to enable multicast transmissions across your GRE tunnels. You can enter the IP address of the interface that will serve as the rendezvous point (RP) for the multicast transmissions.
Note To view the newly created GRE tunnel and/or loopback interfaces in the Router Interfaces page, you must rediscover the device inventory details after successfully deploying the VPN to the device. For more information, see Configuring Cisco IOS Router Interfaces, page 12-2.
Step 7 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding GRE
•Understanding GRE Configuration for Dynamically Addressed Spokes
•GRE Modes Page, page B-60
Understanding DMVPN
Note For a the procedure to configure DMVPN in your VPN topology, see Configuring DMVPN Policies.
Dynamic Multipoint VPN (DMVPN) enables better scaling of large and small IPSec VPNs by combining generic routing encapsulation (GRE) tunnels, IP Security (IPSec) encryption, and Next Hop Resolution Protocol (NHRP) routing.
Security Manager supports DMVPN using the EIGRP, OSPF, and RIPv2 dynamic routing protocols, and GRE static routes. In addition, On-Demand Routing (ODR) is supported. ODR is not a routing protocol. It may be used in a hub-and-spoke VPN topology when the spoke routers do not connect to any router other than the hub. If you are running dynamic protocols, ODR is not suitable for your network environment.
For more information about routing protocols, see Chapter 12, "Managing Routers".
Note•DMVPN can only be configured on a hub-and-spoke VPN topology.
•DMVPN configuration is supported on Cisco IOS 12.3T devices and later. If your device does not support DMVPN, use GRE dynamic IP to configure GRE for dynamically addressed spokes. See Understanding GRE Configuration for Dynamically Addressed Spokes.
•DMVPN is not supported on Catalyst VPN Services Module devices or on High Availability (HA) groups.
How Does Security Manager Implement GRE with DMVPN?
In a hub-and-spoke VPN topology, each spoke has a permanent IPSec tunnel to the hub, but not to the other spokes within the topology. Using NHRP, the hub maintains an NHRP database of the public interface addresses of all the spokes (the clients). Each spoke registers its real address with the hub when it boots. When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the VPN address of the destination spoke. After the source spoke learns the peer address of the target spoke, it initiates a dynamic IPSec tunnel to the target spoke. The spoke-to-spoke tunnel is built over the multipoint GRE interface. The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets can bypass the hub and use the spoke-to-spoke tunnel.
Advantages of DMVPN with GRE
Using DMVPN with GRE provides the following advantages:
•Simplified GRE configuration on the hub
With GRE, a tunnel is configured on the hub for each connected spoke. With GRE + DMVPN, only one tunnel is configured for all the connected spokes.
•Support for dynamically addressed spokes
When using GRE, the physical interface IP address of the spoke routers must be configured as the GRE tunnel destination address, when configuring the hub router. DMVPN enables spoke routers to have dynamic external interface IP addresses, and provides robust configuration that does not have to be redeployed to the device even if the external interface IP address changes. When the spoke comes online, it sends to the hub registration packets that contain the physical interface IP address of the spoke.
•Dynamic tunnel creation for direct spoke-to-spoke communication
NHRP enables spoke routers to dynamically learn the external interface IP address of the routers in the VPN network. When a spoke wants to transmit a packet to another spoke, it can use NHRP to dynamically determine the required destination address of the destination spoke. The hub acts as the NHRP server, handling the request for the source spoke. This enables the dynamic creation of an IPsec+GRE tunnel directly between spoke routers, without having to go through a hub router, thus reducing the delay of multiple encryption and decryption actions on the hub.
Note You can configure the DMVPN settings in the GRE Modes page when DMVPN is the selected IPSec technology. See Understanding IPSec Technologies and Policies.
Related Topics
•Configuring DMVPN Policies
•GRE Modes Page, page B-60
Configuring DMVPN Policies
Note For an understanding of DMVPN policies, see Understanding DMVPN.
Follow the procedure below to configure DMVPN with GRE in your site-to-site VPN.
Before You Begin
•Create your hub-and-spoke VPN topology. See Creating a VPN Topology.
•Make sure that the selected IPSec technology is DMVPN. For more information, see Understanding IPSec Technologies and Policies.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select GRE Modes in the Policies selector.
The GRE Modes page opens to display the fields that are relevant for the selected IPSec technology—DMVPN. For a description of the elements on the GRE Modes page for a DMVPN policy, see Table B-22 on page B-66.
Step 4 In the Routing Parameters tab, select the required dynamic routing protocol (EIGRP, OSPF, or RIP), static route, or On-Demand Routing, to be used for your DMVPN tunnel.
a. If you selected the EIGRP routing protocol:
–Enter or edit the number that will be used to identify the autonomous system (AS) area to which the EIGRP packet belongs. The default number is 110.
–Specify the interval between hello packets sent on the interface, and the number of seconds the router will wait to receive a hello message before invalidating the connection.
–Specify the throughput delay for the primary route interface (default is 1000) and the failover route interface (default is 1500), in microseconds.
b. If you selected the OSPF routing protocol:
–Enter the routing process ID number that will be used to identify the secured IGP that Security Manager adds when configuring DMVPN.
–Enter the ID number of the area in which the hub's protected networks will be advertised, including the tunnel subnet. The default is 1.
–Enter the ID number of the area in which the remote protected networks will be advertised, including the tunnel subnet. The default is 2.
–Enter a string that specifies the OSPF authentication key (up to eight characters long).
–Specify the cost of sending a packet on the primary route interface (default 100) and the secondary (failover) route interface (default 100).
c. If you selected the RIPv2 routing protocol:
–Enter a string that specifies the RIPv2 authentication key (up to eight characters long).
–Specify the cost of sending a packet on the primary route interface (default 100) and the secondary (failover) route interface (default 100).
Note Security Manager adds a routing protocol to all devices in the secured IGP on deployment. If you want to maintain this secured IGP, you must create a router platform policy that uses the same routing protocol, and autonomous system (or process ID) number defined here. See Chapter 12, "Managing Routers" for how to define routing policies for the different protocols.
Step 5 Select the Allow Direct Spoke-to-Spoke Connectivity check box if you want to enable direct communication between spokes, without going through the hub.
Step 6 Select the Filter Dynamic Updates on Spokes check box to enable the creation of a redistribution list that filters all dynamic routing updates on spokes (unavailable if you are using On-Demand Routing or a static route for your DMVPN tunnel).
Step 7 Select the Tunnel Parameters tab, then do the following:
a. In the Tunnel IP Range field, enter the inside tunnel interface IP address, including the subnet mask.
Note If Security Manager detects that a tunnel interface IP address already exists on the device, and its IP address matches the tunnel's IP subnet field, it will use that interface as the GRE tunnel.
b. If you are configuring a dial backup interface, enter its inside tunnel interface IP address, including the unique subnet mask in the Dial Backup Tunnel IP Range field.
c. Select the Server Load Balance check box to enable load balancing on a Cisco IOS router hub in a multiple hubs configuration.
d. Select the Enable IP Multicast check box to enable multicast transmissions across your DMVPN tunnels. Then, if required, enter the IP address of the interface that will serve as the rendezvous point (RP) for the multicast transmissions.
e. Enter a number that identifies the tunnel key (default is 1).
Note To view the newly created tunnel interfaces in the Router Interfaces page, you must rediscover the device inventory details after successfully deploying the VPN to the device. For more information, see Configuring Cisco IOS Router Interfaces, page 12-2.
Step 8 In the NHRP Parameters area:
a. Enter a globally unique, 32-bit network identifier for the NHRP stations (within the range of 1 to 4294967295).
b. Enter the time that routers will keep information provided in authoritative NHRP responses (default is 600 seconds).
c. Enter an authentication string that controls whether the source and destination NHRP stations allow intercommunication (up to eight characters). All routers within the same network using NHRP must share the same authentication string.
Step 9 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding DMVPN
•GRE Modes Page, page B-60
Understanding Easy VPN
Note For the procedure to configure Easy VPN policies, see Configuring Easy VPN Policies.
Easy VPN simplifies VPN deployment for remote offices. Using Easy VPN, security policies defined at the head end are pushed to remote VPN devices, ensuring that clients have up-to-date policies in place before establishing a secure connection.
Easy VPN can be configured in client mode or network extension mode. Client mode is the default configuration and allows devices at the client site to access resources at the central site, but resources at the client site are unavailable to the central site. Network extension mode allows users at the central site to access the network resources at the client site and allows the client site to access resources at the central site.
Security Manager supports the configuration of Easy VPN policies on hub-and-spoke VPN topologies. In such a configuration, most VPN parameters are defined on the Easy VPN server, which acts as the hub device. The centrally managed IPSec policies are pushed to the Easy VPN client devices by the server, minimizing the remote (spoke) devices configuration.
Note Easy VPN is supported on Cisco IOS routers, PIX Firewalls, Catalyst VPN Service Modules, and ASA devices. The Easy VPN Server can be a Cisco IOS router, a PIX Firewall, or an ASA device. The Easy VPN client is supported on PIX Firewalls and Cisco 800-3800 Series routers only.
When a remote client initiates a connection to a VPN server, device authentication between the peers occurs via IKE, followed by user authentication using IKE Extended Authentication (Xauth), VPN policy push (in Client or Network Extension mode), and IPSec security association (SA) creation.
The following provides an overview of this process:
1. The client initiates IKE Phase 1 via aggressive mode if a preshared key is to be used for authentication, or main mode if digital certificates are used. If the client identifies itself with a preshared key, the accompanying user group name (defined during configuration) is used to identify the group profile associated with this client. If digital certificates are used, the organizational unit (OU) field of a distinguished name (DN) is used to identify the user group name. See Defining Additional PKI Attributes, page 8-162.
Note Because the client may be configured for preshared key authentication, which initiates IKE aggressive mode, the administrator should change the identity of the VPN device via the crypto isakmp identity hostname command. This will not affect certificate authentication via IKE main mode.
2. The client attempts to establish an IKE SA between its public IP address and the public IP address of the VPN server. To reduce the amount of manual configuration on the client, every combination of encryption and hash algorithms, in addition to authentication methods and D-H group sizes, is proposed.
3. Depending on its IKE policy configuration, the VPN server determines which proposal is acceptable to continue negotiating Phase 1.
Note Device authentication ends and user authentication begins at this point.
4. After the IKE SA is successfully established, and if the VPN server is configured for Xauth, the client waits for a "username/password" challenge and then responds to the challenge of the peer. The information that is entered is checked against authentication entities using authentication, authorization, and accounting (AAA) protocols such as RADIUS and TACACS+. Token cards may also be used via AAA proxy. During Xauth, a user-specific attribute can be retrieved if the credentials of that user are validated via RADIUS.
Note VPN servers that are configured to handle remote clients should always be configured to enforce user authentication.
5. If the server indicates that authentication was successful, the client requests further configuration parameters from the peer. The remaining system parameters (for example, IP address, DNS, and split tunnel attributes) are pushed to the client using client or network extension mode configuration.
Note The IP address pool and group preshared key (if Rivest, Shamir, and Adelman [RSA] signatures are not being used) are the only required parameter in a group profile. All other parameters are optional.
6. After each client is assigned an internal IP address via mode configuration, Reverse Route injection (RRI) ensures that a static route is created on the device for each client internal IP address.
Note You should enable RRI on the crypto map (static or dynamic) to support VPN clients, unless the crypto map is being applied to a GRE tunnel that is already being used to distribute routing information.
7. IKE quick mode is initiated to negotiate and create IPSec SAs.
The connection is complete.
Tip You can also configure remote access policies in remote access VPNs. In remote access VPNs, policies are configured between servers and mobile remote PCs running Cisco VPN client software, whereas, in site-to-site Easy VPN topologies, the clients are hardware devices. For information about configuring remote access VPNs, see Chapter 10, "Managing Remote Access VPNs".
Important Notes About Site-to-Site Easy VPN Configuration
Before you configure an Easy VPN policy in your topology, you should be aware of the following:
•In an Easy VPN topology configuration, deployment fails if a 72xx series router is used as a remote client device. The Easy VPN client is supported on PIX Firewalls and Cisco 800-3800 Series routers only.
•If you try to configure a Public Key Infrastructure (PKI) policy on a PIX 6.3 remote client in an Easy VPN topology configuration, deployment fails. For successful deployment on this device, you must first issue the PKI certificate on the CA server, and then try again to deploy the device. For more information about PKI policies, see Understanding Public Key Infrastructure Policies.
•In some cases, deployment fails on a device that serves as an Easy VPN client if the crypto map is configured on the NAT (or PAT) internal interface instead of the external interface. On some platforms, the inside and outside interfaces are fixed. For example, in the case of a Cisco 831 router, the VPN interface must be the device's external Ethernet0 interface and the protected networks must be the Ethernet1 internal interface.
Related Topics
•Configuring Easy VPN Policies
Configuring Easy VPN Policies
When configuring Easy VPN in a hub-and-spoke VPN topology, most VPN parameters are defined on the Easy VPN server, which acts as the hub device. The centrally managed IPSec policies are pushed to the Easy VPN client devices by the server, minimizing the remote (spoke) devices configuration.
These procedures describe how to configure Easy VPN policies in your VPN topology:
•Configuring an IPSec Proposal for Easy VPN
•Configuring a User Group Policy for Easy VPN
•Configuring a Tunnel Group Policy for Easy VPN
•Configuring Client Connection Characteristics for Easy VPN
Configuring an IPSec Proposal for Easy VPN
Configuring an IPSec proposal on an Easy VPN server device enables you to:
•Select the transform set(s) to use to secure the traffic that enters your VPN tunnel. For more information, see About Transform Sets.
•Configure Reverse Route Injection (RRI) on the crypto map to ensure that a static route is created on a device for each client internal IP address (for Cisco IOS routers or ASA devices).
•Configure NAT traversal on an ASA device. Use NAT traversal when there is a device between a VPN-connected hub and spoke, and that performs Network Address Translation (NAT) on the IPSec traffic.
•Specify a group authorization (Group Policy Lookup) method that defines the order in which the group policies are searched on the local server or on external AAA servers. Remote users are grouped, so that when the remote client establishes a successful connection to the VPN server, the group policies for that particular user group are pushed to all clients belonging to the user group.
•Specify a user authentication (Xauth) method list that defines the order in which user accounts are searched. After the IKE SA is successfully established, and if the device is configured for Xauth, the client waits for a "username/password" challenge and then responds to the challenge of the peer. The information that is entered is checked against authentication entities using authentication, authorization, and accounting (AAA) protocols such as RADIUS and TACACS+.
In Security Manager, an IPSec proposal is a mandatory policy that is already configured on the Easy VPN server with predefined default values.
This procedure describes how to edit these IPSec policy definitions, if required.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure that the selected IPSec technology is Easy VPN. For more information, see Understanding IPSec Technologies and Policies.
•Please read Important Notes About Site-to-Site Easy VPN Configuration.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select Easy VPN IPSec Proposal in the Policies selector.
Step 4 The Easy VPN IPSec Proposal page appears, displaying the defined parameters for configuring an IPSec proposal on an Easy VPN server device. For a description of the elements on this page, see Table B-22 on page B-70.
Step 5 Specify the transform set(s) to be used for your tunnel policy. If you want to use a different transform set to the displayed default one, or select additional transform sets, click Select to open a dialog box that lists all available transform sets, and in which you can create your own transform set object. For more information, see IPSec Transform Sets Page, page C-130.
Step 6 If required, select the Enable RRI check box to configure Reverse Route Injection (RRI) on the crypto map for the support of VPN clients.
Step 7 If required, select the Enable Network Address Translation check box to configure NAT, if the selected device is a PIX 7.0 or ASA device.
Step 8 If required, specify an AAA authorization (Group Policy Lookup) method list that defines the order in which the group policies are searched on the local server or on external AAA servers.
You can click Select to open a dialog box that lists all available AAA group servers, and in which you can create AAA group server objects. For more information, see Working with AAA Server Objects, page 8-19.
Step 9 If required, select the User Authentication (Xauth) Method check box to use Xauth as the user authentication method for a Cisco IOS router device. The AAA configuration list-name must match the Xauth configuration list-name for user authentication to occur.
You can click Select to open a dialog box that lists all available AAA group servers from which you can make your selection, and in which you can create additional AAA group server objects. For more information, see Working with AAA Server Group Objects, page 8-6.
Step 10 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding Easy VPN
•Easy VPN IPSec Proposal Page, page B-70
Configuring a User Group Policy for Easy VPN
When you configure an Easy VPN server, you can create user groups for remote clients to belong to. As you add remote clients, you can specify that they inherit parameters from the user group policy. Thus you can quickly configure VPN access for large numbers of users.
Remote clients must have the same group name as the user group configured on the server in order to connect to the device, otherwise no connection is established. When the remote client establishes a successful connection to the VPN server, the group policies for that particular user group are pushed to all clients belonging to the user group.
This procedure describes how to specify the user group you want to assign to your Easy VPN server.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure that the selected IPSec technology is Easy VPN. For more information, see Understanding IPSec Technologies and Policies.
•Please read Important Notes About Site-to-Site Easy VPN Configuration.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select User Group Policy in the Policies selector.
The User Group Policy page appears, displaying the currently selected user group. For a description of the elements on this page, see Table B-24 on page B-78.
Step 4 If you want to select a different user group, select it in the Available User Groups list, and click <->. The user group replaces the selected one.
User groups are predefined objects. If the required user group is not included in the list, click Add to open a dialog box that displays all the user group objects, and enables you to create a user group. For more information, see Editing User Group Objects, page 8-245.
Note After creating a user group, you can modify its properties by selecting it, and clicking Edit.
Step 5 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Working with User Group Objects, page 8-237
•Understanding Easy VPN
•User Group Policy Page, page B-77
Configuring a Tunnel Group Policy for Easy VPN
A tunnel group consists of a set of records that contain IPSec tunnel connection policies. Tunnel groups identify the group policy for a specific connection, and include user-oriented attributes. If you do not assign a particular group policy to a user, the default group policy for the connection applies. For a successful connection, the username of the remote client must exist in the database, otherwise the connection is denied.
In site-to site VPNs, you configure tunnel group policies on an Easy VPN server, which can be a PIX Firewall version 7.0, or an ASA device.
Note In remote access VPNs, you can configure tunnel group policies on a remote access VPN server. For more information, see Understanding Tunnel Group Policies in Remote Access VPNs, page 10-7.
Creating a tunnel group policy involves specifying:
•The group policy—A collection of user-oriented attributes stored either internally on the device or externally on RADIUS/LDAP server.
•Global AAA settings—Authentication, Authorization, and Accounting servers.
•The DHCP servers to be used for client address assignment, and the address pools from which the IP addresses will be assigned.
•Settings for Internet Key Exchange (IKE) and IPSec (such as, preshared key).
•(Optional) Interface-specific information (for authentication server groups and client address pools).
•Client VPN software information.
On the PIX7.0/ASA Tunnel Group Policy page, you can create tunnel group policies or edit the parameters defined for existing tunnel group policies on your Easy VPN server.
This procedure describes how to configure a tunnel group policy on your Easy VPN server.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure that the selected IPSec technology is Easy VPN. For more information, see Understanding IPSec Technologies and Policies.
•Please read Important Notes About Site-to-Site Easy VPN Configuration.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select Tunnel Group Policy (PIX 7.0/ASA) in the Policies selector. The Tunnel Group Policy page opens, displaying the General tab.
Step 4 On the General tab, specify the global AAA settings for your tunnel group and select the method (or methods) of address assignment to use. For a description of the elements on the General tab of the Tunnel Group Policy page, see Table B-25 on page B-80.
Step 5 Click the IPSec tab to specify IPSec and IKE parameters for the tunnel group policy. For a description of the elements on the IPSec tab of the Tunnel Group Policy page, see Table B-26 on page B-83.
Step 6 Click the Advanced tab to specify interface-specific information for your tunnel group policy. For a description of the elements on the Advanced tab of the Tunnel Group Policy page, see Table B-27 on page B-86.
Step 7 Click the Client VPN Software Update tab to view and edit the client type, VPN Client revisions, and image URL for each client VPN software package installed. For a description of the elements on the Client VPN Software Update tab of the Tunnel Group Policy page, see Table B-28 on page B-88.
Step 8 When you have finished configuring your tunnel group parameters, click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding Easy VPN
•Tunnel Group Policy (PIX 7.0/ASA) Page, page B-79
Configuring Client Connection Characteristics for Easy VPN
Easy VPN connection characteristics specify how traffic will be routed in the VPN and how the VPN tunnel will be established. Easy VPN can be configured in client mode or network extension mode.
Client mode is the default configuration and allows devices at the client site to access resources at the central site, but resources at the client site are unavailable to the central site. Client mode specifies that Network Address Translation (NAT) be done, so that the hosts at the client end of the VPN tunnel form a private network that does not use any IP addresses in the destination server's IP address space. Easy VPN configures the NAT translation and access lists that are needed to implement the VPN tunnel. These configurations are created when the IPSec VPN connection is initiated. When the tunnel is torn down, the NAT and access list configurations are deleted. In other words, the whole LAN behind the spoke is NATed to the ip addresses which will be pushed down by the Easy VPN server (the hub).
Network Extension mode allows users at the central site to access the network resources at the remote client site and allows the client site to access resources at the central site. Network Extension mode specifies that the hosts at the client end of the VPN tunnel should be given IP addresses that are fully routable and reachable by the destination network over the tunneled network, so that they form one logical network. NAT is not used, so the hosts at the client end have direct access to the hosts at the destination network. In other words, the Easy VPN server (the hub) gives routable addresses to the Easy VPN client (the spoke), while the whole LAN behind the client will not undergo NAT.
Note Both modes of operation can also support split tunneling, which allows secure access to corporate resources through the VPN tunnel while also allowing Internet access through a connection to an ISP or other service (thereby eliminating the corporate network from the path for web access).
This procedure describes how to configure the client connection characteristics for Easy VPN.
Before You Begin
•Create your VPN topology. See Creating a VPN Topology.
•Make sure that the selected IPSec technology is Easy VPN. For more information, see Understanding IPSec Technologies and Policies.
•Please read Important Notes About Site-to-Site Easy VPN Configuration.
Procedure
Step 1 Select Tools > Site-To-Site VPN Manager or click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.
Step 2 In the VPNs selector, select the required VPN topology.
Step 3 Select Client Connection Characteristics in the Policies selector. The Client Connection Characteristics page opens. For a description of the elements on this page, see Table B-29 on page B-89.
Step 4 Select Client or Network Extension, from the Mode drop-down list.
Step 5 Click Save to save your changes to the server.
Note To publish your changes, click the Submit button on the toolbar.
Related Topics
•Managing Shared Site-to-Site VPN Policies in Policy View
•Understanding Easy VPN
•Client Connection Characteristics Page, page B-88
