Managing Site-to-Site VPNs€¦ · DMVPN and Easy VPN technologies can only be applied in a hub-and-spoke topology. For more information, see Understanding IPsec Technologies and

OL-19983-01

C H A P T E R 9
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.

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. In Policy View, you can assign IPsec policies to VPN topologies. For more information, see:

Managing Shared Site-to-Site VPN Policies in Policy View, page 9-44

Managing VPN Devices in Device View, page 9-42

Modifying Policy Assignments in Policy View, page 6-39

The following topics describe:

• Understanding VPN Topologies, page 9-2

• Understanding IPsec Technologies and Policies, page 9-5

• Site-To-Site VPN Discovery, page 9-8

• Working with VPN Topologies, page 9-14

• Managing VPN Devices in Device View, page 9-42

• Working with Site-to-Site VPN Policies, page 9-43

9-1User Guide for Cisco Security Manager 3.3

Chapter 9 Managing Site-to-Site VPNsUnderstanding VPN Topologies

Understanding VPN TopologiesA 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, depending on the assigned IPsec technology.

Security Manager supports three main 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, page 9-5.

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.


• Hub-and-Spoke VPN Topologies, page 9-2

• Point-to-Point VPN Topologies, page 9-3

• Full Mesh VPN Topologies, page 9-4

• Implicitly Supported Topologies, page 9-5

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

Secure tunnelSecure tunnel

SecuretunnelSecure tunnel

Spoke

Spoke

Spoke

Spoke

Branchoffice

Branchoffice

Hub

Mainoffice

Optionalsecondary hubs

for resilience

1300

52

Internet


OL-19983-01


This topology usually represents an intranet VPN that connects an enterprise’s main office with branch offices using persistent connections to a third-party network or the Internet. VPNs in a hub-and-spoke topology 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. Spoke devices are 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 is 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, page 9-5.

Related Topics




Point-to-Point VPN TopologiesIn 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 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 IPsec/GRE. For more information, see Understanding IPsec Technologies and Policies, page 9-5.

Figure 9-2 shows a typical point-to-point VPN topology.

Figure 9-2 Point-to-Point VPN Topology

Related Topics




Site 2Site 113

0053

Internet

Secure tunnel


OL-19983-01


Full Mesh VPN TopologiesA full mesh topology works well in a complicated network where all peers need to communicate with each other. In this topology type, every device in the network communicates with every other device via a unique IPsec tunnel. All devices have direct peer relationships with one another, preventing a bottleneck at the VPN gateway device, and saving the overhead of encryption and decryption on the device.

Note You can assign only Regular IPsec, IPsec/GRE, and GET VPN technologies to a full mesh VPN topology. See Understanding IPsec Technologies and Policies, page 9-5.

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. GET VPN is based on the group trust model. In this model, group members register with a key server. The key server uses the Group Domain of Interpretation (GDOI) protocol for distributing the security policy and keys for encrypting traffic between the group members. Because you can configure a primary key server and secondary key servers that synchronize their policies with the primary one, if the primary key server becomes unavailable, a secondary key server can take over.

Note 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.

Site 2

Site 1

Site 4

Site 3

1300

54

Secure

tunnel

Secure tunnelSecu

retu

nnel

Secu

retu

nnel

Secure tunnel

Secure tunnel

Internet


OL-19983-01

Chapter 9 Managing Site-to-Site VPNsUnderstanding IPsec Technologies and Policies

Related Topics




Implicitly Supported TopologiesIn 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 it is less expensive to implement. Partial mesh topologies are generally used in 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



• Point-to-Point VPN Topologies, page 9-3

• Full Mesh VPN Topologies, page 9-4

Understanding IPsec Technologies and PoliciesSite-to-site VPN policies are grouped according to their IPsec technology type. Security Manager provides seven types of IPsec technologies that you can configure on the devices in your site-to-site VPN topology—Regular IPsec, IPsec/GRE, GRE Dynamic IP, standard and large scale DMVPN, Easy VPN, and GET VPN. 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.

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, page 9-16.

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.


OL-19983-01


Note You can deploy mandatory policies with their default configurations to your devices immediately after creating the VPN topology. All you need to do is complete the steps of the Create VPN wizard. See Using the Create VPN Wizard, page 9-14.

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, page 9-47). 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, Part 1 on page 9-6 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, Part 1 Site-to-Site VPN IPsec Technologies and Policies

Technology Mandatory Policies Optional Policies Supported Platforms

Regular IPsec

See Understanding IPsec Tunnel Policies, page 9-48.

• 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.

IPsec/GRE (Generic Routing Encapsulation)

See Understanding GRE, page 9-62.

• IKE Proposal

• IPsec Proposal

• Preshared Key1

• GRE Modes



GRE policies can be configured on Cisco I OS security routers and Catalyst 6500/7600 devices.

GRE Dynamic IP

See Understanding GRE Configuration for Dynamically Addressed Spokes, page 9-64.

• IKE Proposal

• IPsec Proposal

• Preshared Key1

• GRE Modes



GRE Dynamic IP can be configured on Cisco I OS security routers and Catalyst 6500/7600 devices.

Dynamic Multipoint VPN (DMVPN).

See Understanding DMVPN, page 9-67.

• IKE Proposal

• IPsec Proposal

• Preshared Key1

• GRE Modes



DMVPN configuration is supported on Cisco IOS 12.3T devices and later.

Large Scale DMVPN

See Configuring Large Scale DMVPNs, page 9-70.

• IKE Proposal

• IPsec Proposal

• Preshared Key1

• GRE Modes

• Server Load Balance



Large Scale DMVPN configuration is supported on Catalyst 6500/7600 devices (IPsec Terminators), and Cisco IOS 12.3T devices and later.


OL-19983-01


Related Topics

• Understanding VPN Default Policies, page 9-8



• Understanding Policies, page 6-1

Easy VPN

See Understanding Easy VPN, page 9-71.

• IKE Proposal

• IPsec Proposal

• Client Connection Characteristics

• User Group (mandatory on an IOS router or PIX 6.3 hub in VPN topology)

• Tunnel Group (mandatory on an ASA hub device in VPN topology)



Easy VPN configuration is supported on Cisco IOS security routers, PIX Firewalls, Catalyst VPN service modules, and ASA devices.

GET VPN

See Understanding Group Encrypted Transport (GET) VPNs, page 9-82.

• Group Encryption

• IKE Proposal

• Preshared Key

Public Key Infrastructure


• Key servers can be configured on Cisco 1800/2800/3800 Series ISR, Cisco 7200 Series Routers, and Cisco 7301 Routers.

• Group members can be configured on Cisco 1800/2800/3800 Series ISR, Cisco 7200 Series Routers, and Cisco 7301 Routers. The Cisco 871 ISR can also be used as a group member if GET VPN is deployed with very few (1-3) IPSec SAs. In addition, you can configure Cisco 1002/1004/1006 ASR Routers at Release 3 (12.2(24)SRD) and above as group members.

1. A preshared key policy is mandatory only if the IKE authentication method is Preshared Key.

2. A public key infrastructure policy is mandatory if the IKE authentication method is RSA Signature.

Table 9-1, Part 1 Site-to-Site VPN IPsec Technologies and Policies (Continued)

Technology Mandatory Policies Optional Policies Supported Platforms


OL-19983-01

Chapter 9 Managing Site-to-Site VPNsSite-To-Site VPN Discovery

Understanding VPN Default PoliciesSecurity Manager provides mandatory policies as factory defaults, which means they are configured on the devices in your VPN topology with predefined values, depending on the assigned IPsec technology. Factory default policies enable you to deploy to your devices immediately after creating the VPN topology. Factory default policies are private policies, which can be assigned only to the VPN topology in which they are configured. Any changes you make to these policies affect only this VPN topology.

Optional policies are not provided as factory defaults. These policies are not assigned by default to your devices. They can be configured. If required, you can define an optional policy as a shared policy, which means you can assign it as a default policy to any VPN topologies that are newly created.

Any changes that you make to a shared policy affect all VPN topologies to which the policy is assigned. In Policy view, you can 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. For more information, see Managing Shared Policies in Policy View, page 6-35.

On the VPN Policy Defaults page of the Administration tool (Tools > Security Manager Administration > VPN Policy Defaults) you can view the default policies for each IPsec technology that can be assigned to a VPN topology. These include the factory defaults that are provided by Security Manager, in addition to any shared VPN policies that were created, and submitted or approved (depending on the workflow mode), using Security Manager. Selecting a VPN shared policy assigns this shared policy as the default policy to all VPN topologies that are created after the selection is made. For information on configuring default VPN policies, see VPN Policy Defaults Page, page A-41.

In the last step of the Create VPN wizard, you can view all the available policy types (both mandatory and optional) that can be assigned to your VPN topology, according to the selected IPsec technology. For each policy type, you can select the policies to assign to your VPN topology.

Related Topics

• Assigning Default Policies to Your VPN Topology, page 9-24

• VPN Defaults Page, page G-28

Site-To-Site VPN DiscoverySecurity Manager allows you to discover the VPN topologies that are already deployed in your network so that you use Security Manager to manage them. Your VPN configurations are brought into Security Manager and displayed as site-to-site VPN policies.

Security Manager also allows you to rediscover the configurations of existing VPN topologies that are already managed with Security Manager. For information about Site-to-Site VPN rediscovery, see Rediscovering Site-to-Site VPNs, page 9-13.

Note You can also discover configurations on devices in remote access VPNs that are already deployed in your network. See Discovering Remote Access VPN Policies, page 10-6.

These topics provide information about Site-to-Site VPN discovery:

• Supported Technologies and Topologies for VPN Discovery, page 9-9

• Prerequisites for VPN Discovery, page 9-10

• VPN Discovery Rules, page 9-10


OL-19983-01


• Discovering Site-to-Site VPNs, page 9-12

• Rediscovering Site-to-Site VPNs, page 9-13

• Discover VPN Policies Wizard, page G-77

Supported Technologies and Topologies for VPN DiscoveryThis topic lists the technologies and topologies that Security Manager can discover, as well as the VPN features that are provisioned by Security Manager but cannot be discovered.

Supported Technologies for VPN Discovery

• IPsec

• IPsec + GRE

• IPsec + GRE dynamic IP

• DMVPN

• Easy VPN

• GET VPN

Supported Topologies for VPN Discovery

• Point to point

• Hub and spoke

• Full mesh

VPN Features Provisioned by Security Manager but Unsupported for VPN Discovery

• SSL VPN

• Large Scale DMVPN with IPsec Terminator

• VRF-Aware IPsec

• Dial backup

• IPsec and ISAKMP profiles for Easy VPN

• Easy VPN with High Availability

Related Topics






OL-19983-01


Prerequisites for VPN DiscoveryFor successful VPN discovery, the following prerequisites must be met:

• All devices participating in the VPN must be added to the Security Manager inventory.

• You must provide Security Manager with some basic information about the VPN. The VPN discovery wizard prompts you for the following information:

– VPN topology (hub and spoke, point to point, full mesh).

– VPN technology (Regular IPsec, IPsec/GRE, GRE dynamic IP, DMVPN, Easy VPN, GET VPN).

– Devices in the VPN and their roles (hub/spoke).

– Source of the VPN configuration. The VPN can be discovered directly from the live network or from Security Manager’s Configuration Archive.

• Each device in the VPN must have a crypto map associated with a physical interface.

• Each PIX 6.3 or ASA 5505 client device in an Easy VPN topology must have a vpnclient configuration.

Related Topics





VPN Discovery RulesTable 9-2 on page 9-11 describes the rules by which Security Manager translates and discovers your VPN configurations, and how it handles instances where your configuration on the device does not match what is supported by Security Manager.


OL-19983-01


Table 9-2 VPN Discovery Rules

If this condition exists: The VPN discovery will be handled as follows:

Security Manager cannot contact a device in the VPN for live device discovery.

• If the device is the only hub or spoke in the VPN, discovery fails.

• If there are other hubs or spokes in the VPN, discovery proceeds but the unavailable device is not discovered.

• If the device is a peer in a point-to-point topology, discovery fails.

• If the device is a peer in a full mesh topology and there are only two devices, including the unavailable one, in the topology, discovery fails. If there are more than two devices, discovery proceeds but the unavailable device is not discovered.

There are inconsistencies in the policies/values in the VPN configurations across the devices in the VPN.

• If the values on the hub and the spokes differ, preference is given to the values on the hub.

• If a simple selection of one policy or value from several eligible policies or values is required and does not put functionality at risk, Security Manager selects a single policy/value that is common to all devices. For example, a VPN can have a single IKE policy only, whereas there can be more than one IKE policy on the devices.

• If selecting one value puts the functionality at risk, no value is discovered for the policy and a validation message is received upon deployment.

• If numeric values differ, a message is generated during discovery, and the lower value is discovered. For example, the lowest SA lifetime value in an IPsec policy.

• If none of the above options are possible, VPN discovery fails.

Preshared key configuration—there is a different key per set of peers.

The preshared key policy is not discovered.

There is more than one eligible crypto map on the device.

The crypto map that is associated with all or the majority of the devices selected for VPN discovery is used.

A spoke does not have a crypto map associated with the hub.

VPN discovery proceeds but the spoke is not discovered and an error message is generated.

A device does not have the selected transform set value.

VPN discovery proceeds but the device may be removed from the VPN topology.

A device does not have the selected IKE proposal. VPN discovery proceeds but the device may be removed from the VPN topology.

A device supports DVTI, but does not have DVTI or a crypto map configured.

VPN discovery fails.

A server supports DVTI, but does not have an IP address configured in the DVTI configuration.

VPN discovery proceeds but with a warning.

A client does not support DVTI. If the hub is configured with DVTI, discovery proceeds without any warning or Error.

A Hub and Spoke topology where the spokes are not using the same VPNSPA/VSPA slot on the hub (Catalyst 6500/7600).

VPN discovery fails.


OL-19983-01


Related Topics




• Rediscovering Site-to-Site VPNs, page 9-13


• Rediscover VPN Policies Wizard, page G-80

Discovering Site-to-Site VPNsThis procedure describes how to discover a Site-to-Site VPN that is already working in your network, but that has not yet been defined in Security Manager.

Related Topics

• Discovering Policies, page 6-11

• Viewing Policy Discovery Task Status, page 6-16





Step 1 Select Policy > Discover VPN Polices. The Discover VPN Policies wizard opens, displaying the Name and Technology page. For a description of the elements on the Name and Technology page, see Table G-43 on page G-78.

Step 2 Specify a name for the VPN, topology type, and IPsec technology of the VPN to be discovered, and whether you want to discover the VPN directly from the live devices in your network or from the Config Archive.

Step 3 Click Next to open the Device Selection page of the wizard.

Step 4 Select the devices participating in the VPN, and their role in the VPN (hub, spoke, peer one, peer two, key server, group member) depending on the topology type. For a description of the elements on the Device Selection page, see Table G-44 on page G-79.

The same set of key servers and group members are participating in more than one GET VPN.

Security Manager discovers only one of the topologies.

A User Group policy is configured with backup servers using hostnames instead of an IP addresses.

VPN Policy Discovery fails with the following error:

Policy Discovery Failed: com.cisco.nm.vms.discovery.DiscoveryException: Internal Error

In order for discovery to be successful, you need to reconfigure the user group policy on the device with backup servers using IP address, not hostnames.

Table 9-2 VPN Discovery Rules (Continued)

If this condition exists: The VPN discovery will be handled as follows:


OL-19983-01


Step 5 Click Finish to close the wizard and start the discovery process. The Discovery Status window displays the status of the discovery and indicates whether the discovery of each device has been successful or has failed. Error or warning messages are provided to indicate the source of any problems, which may be VPN specific or device specific.

When the discovery process is complete, the Site-to-Site VPN Manager opens and displays the summary information for the VPN that was discovered.

Step 6 Verify that the VPN polices are as required. Edit the policies as necessary.

Rediscovering Site-to-Site VPNsYou can also rediscover the configurations of existing VPN topologies that are already managed with Security Manager.

Note Easy VPN topologies with Dynamic VTI cannot be rediscovered.

The same rules by which Security Manager translates and discovers VPN configurations apply also to rediscovery. However, you can perform rediscovery only on devices that participate in a VPN topology, and you cannot make any changes to the IPsec technology or topology type. In addition, only the configurations of device specific policies, such as VPN interfaces and protected networks, and any High Availability (HA) policies that are configured on hubs, can be rediscovered. VPN global policies, such as IKE proposals or PKI enrollments cannot be rediscovered.

This procedure describes how to rediscover the configurations of a Site-to-Site VPN topology that already exists in Security Manager.

Related Topics

• Rediscover VPN Policies Wizard, page G-80

• Site-To-Site VPN Discovery, page 9-8



Step 1 In the Site-to-Site VPN Manager window, right-click the VPN topology whose configurations you want to rediscover, and click Rediscover Peers.

The Rediscover VPN Policies wizard opens, displaying the Name and Technology page. For a description of the elements on the Name and Technology page, see Table G-45 on page G-81.

Step 2 Specify whether you want to rediscover the VPN directly from the live devices in your network or from the Config Archive.

Note You cannot make any changes to the VPN’s topology type or IPsec technology.

Step 3 Click Next to open the Device Selection page.

Step 4 Select the devices whose peer level policies need to be rediscovered, and their role in the VPN (hub, spoke, peer one, peer two, key server, or group member) depending on the topology type. For a description of the elements on the Device Selection page, see Table G-46 on page G-82.


OL-19983-01

Chapter 9 Managing Site-to-Site VPNsWorking with VPN Topologies

Step 5 Click Finish to close the wizard and start the rediscovery process. The Discovery Status window displays the status of the rediscovery and indicates whether the rediscovery of each device has been successful or has failed. Error or warning messages are provided to indicate the source of any problems.

When the rediscovery process is complete, the Site-to-Site VPN Manager opens and displays the summary information for the VPN that was rediscovered.

Working with VPN TopologiesSecurity 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 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, page 9-42.


• Using the Create VPN Wizard, page 9-14

• Editing a VPN Topology, page 9-27

• Deleting a VPN Topology, page 9-28



Related Topics



• Site-to-Site VPN Manager Window, page G-1

Using the Create VPN WizardThis procedure describes how to select devices to include in your VPN topology using the Create VPN Wizard. For more information about selecting devices in a VPN topology, see About Selecting Devices in a VPN Topology, page 9-17.

You can use the Create VPN wizard to create hub-and-spoke, point-to-point, and full mesh VPN topologies across multiple device types. Then, after creating the VPN topology, you can deploy the default policy configurations provided by Security Manager immediately to your devices. All you need to do is complete the steps of the Create VPN wizard.

Creating a VPN topology involves specifying the devices and the networks that make up the site-to-site VPN. You define the devices and their roles (such as hub, spoke, peer, key server, group member), 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 topologies. When you create a VPN topology, you assign to it the IPsec technology (such as Regular


OL-19983-01


IPSec, IPSec/GRE, GRE Dynamic IP, DMVPN, Large Scale DMVPN, Easy VPN, GET VPN) with which a predefined set of policies is associated. See Understanding IPsec Technologies and Policies, page 9-5.

Related Topics

• About Selecting Devices in a VPN Topology, page 9-17

• Device Selection Page, page G-4


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 in Map View, page 3-15.

Step 1 To access the Create VPN Wizard, click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.

Step 2 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.

The Create VPN wizard opens. Depending on the type of VPN topology you are creating, different pages appear. The following Table 9-3 on page 9-15 shows the steps you take depending on the VPN topology that you are creating.

Step 3 After you create 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, page 9-41).

• VRF-Aware IPsec on a hub in a hub-and-spoke topology (see Configuring VRF-Aware IPsec Settings, page 9-38).

• A VPNSM or VPNSPA/VSPA on a Catalyst 6500/7600 in a hub-and-spoke, point-to-point, or full mesh VPN topology (see Procedure for Configuring a VPNSM or VPN SPA/VSPA, page 9-31).

Table 9-3 Create VPN Wizard Steps

TopicHub and Spoke

Point to Point

Full Mesh (Regular IPSec/IPSec GRE)

Full Mesh (GET VPN)

Defining a Name and IPsec Technology, page 9-16

Step 1 Step 1 Step 1 Step 1

Selecting Devices for Your VPN Topology, page 9-18


Defining the Endpoints and Protected Networks, page 9-20

Step 3 Step 3 Step 3 —

Configuring High Availability in Your VPN Topology, page 9-41

Step 4 — — —

Defining GET VPN Group Encryption, page 9-22

— — — Step 3

Defining GET VPN Peers, page 9-23 — — — Step 4

Assigning Default Policies to Your VPN Topology, page 9-24



OL-19983-01


• 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 VPNSPA/VSPA, page 9-33).

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.

Related Topics



• Name and Technology Page, page G-3

Step 1 Click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.

Step 2 Open the Create VPN Wizard. For information, see Using the Create VPN Wizard, page 9-14.

The Create VPN wizard opens, displaying the Name and Technology page. For a description of the elements on this page, see Table G-2 on page G-4.

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. Options shown depend on the VPN topology chosen:

• Regular IPsec

• IPsec/GRE

• DMVPN (Hub and Spoke VPN only)

• Easy VPN (Hub and Spoke VPN only)

• GET VPN (Full Mesh VPN only)

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 If you are creating a hub-and-spoke topology, define the technology type:

• For IPsec/GRE technology, select either Standard (for IPsec/GRE) or Spokes with Dynamic IP (to configure GRE Dynamic IP), from the Type list.

• For DMVPN technology, select either Standard (for regular DMVPN) or Large Scale with IPsec Terminator (to configure a large scale DMVPN), from the Type list.

Step 6 Click Next. The Device Selection page opens. See Selecting Devices for Your VPN Topology, page 9-18.


OL-19983-01


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, page 9-18.

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, large scale DMVPN, point-to-point, or full mesh VPN topology.

Only the devices that can be used for the selected VPN topology, 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 IPsec/GRE, GRE Dynamic IP, or DMVPN, PIX Firewalls and ASA devices are not displayed. For more information, see the supported platforms described in Table 9-1, Part 1 on page 9-6.

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, page 9-42.

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 Devices to the Device Inventory, page 5-7.

Cloning a Device in a VPN Topology

Cloning (duplicating) a device enables you to share the configurations and properties of one device on another, without having to recreate the configuration and properties.

In a VPN topology, you can clone a device that is a spoke in a hub-and-spoke configuration, or a device that participates in a full mesh topology. If you clone a spoke device in a hub-and-spoke VPN topology, the new device is added to the VPN as a new spoke with the same policies. If you clone a device in a full mesh VPN, the new device is added to the full mesh VPN with the same policies.

Note You cannot clone a device in a point-to-point VPN topology.

You can clone a VPN device in Device view, by selecting the Clone VPN Assignments check box in the Create a Clone Device page. For more information, seeCloning a Device, page 5-24.

Related Topics

• Selecting Devices for Your VPN Topology, page 9-18

• About Editing a VPN Topology, page 9-25


OL-19983-01




Selecting Devices for Your VPN Topology

This procedure describes how to select devices to include in your VPN topology using the Create VPN Wizard. For more information about selecting devices in a VPN topology, see About Selecting Devices in a VPN Topology, page 9-17.

Related Topics






Step 3 From the Name and Technology page, click Next.

The Device Selection page opens. For a description of the elements on this page, see Table G-3 on page G-5.

Step 4 To select devices for a hub-and-spoke VPN 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.

Note Click the Up and Down buttons to change the order of the devices in the Hubs list, so that the primary hub appears first. If you selected only one device, it becomes the primary hub.

• 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.

Note If you selected Large Scale with IPsec Terminator as the DMVPN technology type in the Name and Technology page, you must also select the Catalyst 6500/7600 devices you want to be IPsec Terminators in your Large Scale DMVPN configuration.

Step 5 To select devices for a point-to-point VPN 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 >>.

Step 6 To select devices for a full mesh VPN topology with Regular IPSec or IPSec/GRE technology, select them in the Available Devices list, then click >>. The devices appear in the Selected Devices list.


OL-19983-01


Step 7 To select devices for a full mesh VPN topology with GET VPN technology:

• From the Devices list, select one or more devices to be key servers in your VPN topology, then click >> next to the Key Servers field.

• From the Devices list, select one or more devices to be group members in your VPN topology, and click >> next to the Group Members field.

Step 8 Click Next. One of the following pages appear:

• If you are creating a GET VPN, the GET VPN Group Encryption page appears. For the procedure, see Defining GET VPN Group Encryption, page 9-22.

• If you are creating any other type of VPN, the End Points page appears. For the procedure, see Defining the Endpoints and Protected Networks, page 9-20.

About Defining and Editing 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 table on the Endpoints page lists the VPN interfaces and protected networks defined for all selected devices in the VPN topology, including the interface roles, or the interfaces that match each interface role.

Note The internal and external interfaces that appear on the Endpoints page are the default interfaces that are defined on the Administration tool’s VPN Defaults page. For more information, see VPN Policy Defaults Page, page A-41.

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 Understanding Interface Role Objects, page 8-33.

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 Understanding Network/Host Objects, page 8-65.

If the assigned technology is IPsec, you can also use access control lists (ACLs) to specify the protected networks. For more information, see Creating Access Control List Objects, page 8-23.

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.

• Editing a hub interface that is connected to an IPsec Terminator in a large scale DMVPN.

• Configuring a VPN Services Module (VPNSM) interface or VPN SPA for a Catalyst 6500/7600 device.


OL-19983-01


• 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, page 9-20


• Endpoints Page, page G-7

• Configuring Dial Backup, page 9-29

• Procedure for Configuring a VPNSM or VPN SPA/VSPA, page 9-31

• Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPNSPA/VSPA, page 9-33

• Configuring VRF-Aware IPsec Settings, page 9-38

• Configuring Large Scale DMVPNs, page 9-70

Defining the Endpoints and Protected Networks

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.

Consider the following notes before you use this procedure:

Note If you are configuring a VPN interface for a Catalyst 6500/7600 device (which may be an IPsec Terminator in a large scale DMVPN), see.Procedure for Configuring a VPNSM or VPN SPA/VSPA, page 9-31

To configure a Firewall Services Module together with a VPN Services Module on a Catalyst 6500/7600 device (which may be an IPsec Terminator in a large scale DMVPN), see Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPNSPA/VSPA, page 9-33.

If the selected device is a hub (IPsec Aggregator) on which you want to configure VRF-Aware IPsec, see Configuring VRF-Aware IPsec Settings, page 9-38.

Related Topics


• About Defining and Editing the Endpoints and Protected Networks, page 9-19

• Endpoints Page, page G-7

• Edit Endpoints Dialog Box, page G-10





OL-19983-01




Step 3 From the Device Selection page, click Next. The Endpoints page opens. For a description of the elements on this page, see Table G-5 on page G-8.

Step 4 To edit the VPN interface or protected networks for a device, select the row in the table that contains the device and click Edit. The Edit Endpoints dialog box opens. For a description of the tabs on the Edit Endpoints dialog box, see Edit Endpoints Dialog Box, page G-10.

Note You can select more than one device at a time for editing. The changes you make on the VPN Interface or Protected Networks tab are applied to all selected devices. When selecting multiple devices, you cannot include Catalyst 6500/7600 devices in your selection.

Step 5 To edit the primary VPN interface for the selected device, click the VPN Interface tab (for a description of the elements on this tab, see Table G-6 on page G-11):

a. Specify the VPN interface defined for the selected device.

Note If the selected device is a hub in a large scale DMVPN, specify the interface that is connected to the IPsec Terminator in the Hub Interface tab. See Configuring Large Scale DMVPNs, page 9-70.

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.

c. Specify the IP address of the VPN interface of the peer device under Peer IP Address.

d. If you have enabled the setting to use a unique tunnel source per tunnel interface in the GRE Modes > Tunnel Parameters tab, the Override Unique Tunnel Source per Tunnel Interface checkbox is available. Click this check box to specify a different tunnel source for the selected device.

e. If the device is a hub and the selected technology is IPsec/GRE or DMVPN, specify the tunnel source address to be used by the GRE or DMVPN tunnel on the spoke side, under Tunnel Source.

f. To enable the configuration of a backup interface to be used as a fallback link for the primary route VPN interface, select the Enable check box under Backup, then complete the fields provided. For the procedure to configure dial backup, see Configuring Dial Backup, page 9-29.

Step 6 To edit the protected networks for the selected device:

a. Click the Protected Networks tab on the Edit Endpoints dialog box. For a description of the elements on the Protected Networks tab, see Table G-8 on page G-17.

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.


OL-19983-01


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 7 Click Next.

• If you are creating a hub-and-spoke VPN topology, the High Availability page appears. To configure high availability, see Configuring High Availability in Your VPN Topology, page 9-41. To skip this page, click Next again. The Defaults page appears. See Assigning Default Policies to Your VPN Topology, page 9-24.

• If you are creating a point-to-point VPN topology or full mesh VPN topology with Regular IPSec or IPSec/GRE, the Defaults page appears. See Assigning Default Policies to Your VPN Topology, page 9-24.

• If you are creating a full mesh VPN topology with GET VPN, the GET VPN Group Encryption page appears. See Defining GET VPN Group Encryption, page 9-22.

Defining GET VPN Group Encryption

This procedure describes how to create encryption policies for GET VPN.

Related Topics





Step 3 From the Device Selection page, click Next. The GET VPN Group Encryption page opens. For a description of the elements on this page, see GET VPN Group Encryption Page, page G-6.

Step 4 Enter a name for the Group Domain of Interpretation (GDOI) group. This name is the same as a VPN name.

Step 5 For the Group Identity, enter a number or IP address to identify the group.

Step 6 Leave the Receive Only check box unchecked, unless you are testing the VPN. When enabled, group members decrypt traffic and forward it in clear text.

Step 7 Select the ACL Policy object to be used as the security policy.

Note If the method to distribute the keys is multicast, then the ACL policy object must contain a deny ACE for the multicast address. In this way, the rekey packets sent using multicast will not be encrypted by the TEK.

Step 8 Select the type of authorization mechanism to be used by the group: None, Certificates, or Preshared Key.


OL-19983-01


Step 9 Select the transport method to be used to distribute keys to each group member:

• Unicast or Multicast—If unicast is selected, the key server sends a rekey message to each registered group member and waits for an acknowledgment. If multicast is selected, the key server sends a rekey message to all group members at once.

Note If you select multicast, make sure that the router used as the key server is multicast enabled.

• Group IP Address—IP Address of the multicast group.

• Use Static IGMP Joins on Group Members—If multicast is selected as the transport method, this option is available. If you select this option, the static Source Specific Multicast (SSM) mappings are enabled, which reveal the source of multicast traffic to the group member. In the case of GET VPN, the group member learns the key server address.

Step 10 Enter a label for the RSA key (the key with which the rekey messages from the key server to group members are encrypted).

Step 11 In the Lifetime field, enter the number of seconds that the key used for encrypting traffic keys is valid.

Step 12 In the Encryption Algorithm field, enter the algorithm used to encrypt the rekey message form the key server to the group member.

Step 13 Enter the number of times the rekey message can be retransmitted and the interval or number of seconds between retries.

Step 14 Do one of the following:

• Click Next. The GET VPN Peers page appears. See Defining GET VPN Peers, page 9-23

• Click Finish to complete the VPN topology creation. The 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 G-73.

Defining GET VPN Peers

This procedure describes how to define peers for GET VPN.

Related Topics





Step 3 From the GET VPN Group Encryption page, click Next. The GET VPN Peers page opens. For a description of the elements on this page, see GET VPN Peers Page, page G-25.


OL-19983-01


Step 4 Define key servers by selecting them and clicking the Edit button. Configure the fields as follows:

• Identity Interface—Select the interface that group members use to identify the key server and register with it. The default is Loopback.

• Priority—Define the role of the key server by entering a priority value between 1-100. If two or more key servers are assigned the same priority value, the device with the highest IP address is used. The default priority is 100 for the first key server, 95 for the second, and so on.

Note There can be more than one primary key server if the network is partitioned.

• Registration Interface—If desired, you can specify an interface to handle group domain of interpretation (GDOI) registrations. Otherwise, GDOI registrations occur on any interface.

Step 5 Add key servers by clicking the Add button in the Key Servers table. Select the server and click OK.

Step 6 Move key servers up or down in table to specify the order that group members use to register with key servers. Group members register with the first key server in the list. If the first key server cannot be reached, they will register with the second key server, and so on.

Step 7 Define group members by selecting them and clicking the Edit button. Configure the fields as follows:

• GET-Enabled Interface—Select the GET-enabled interface.

• Interface To Be Used As Local Address—IP address of the group member interface used to identify the group member to the key server for sending data, such as rekey information. If GET is enabled on only one interface, you do not need to specify the interface to be used as the local address. The single interface is used for both. If GET is enabled on more than one interface, you must specify the interface to be used as the local address.

• Security Policy—Select the policy that defines the traffic to be encrypted.

• Click the Override Key Servers checkbox to indicate that the policy assigned to group members supersedes the policy downloaded from the key server. Click the Select button to add additional key servers to the list.

Step 8 Add group members by clicking the Add button in the Group Members table. Select the group member and click OK.

Step 9 Do one of the following:

• Click Next. The Defaults page appears. See Assigning Default Policies to Your VPN Topology, page 9-24.

• Click Finish to complete the VPN topology creation. The 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 G-73.

Assigning Default Policies to Your VPN Topology

The VPN Defaults page of the Create VPN wizard displays all available mandatory and optional policies that can be assigned to your VPN topology, according to the selected IPsec technology. For each policy type, you can select the policies to assign to your VPN topology. These can be factory default policies (for mandatory policy types only) or shared VPN policies that were created (and submitted or approved, depending on the workflow mode) using Security Manager.


OL-19983-01


Note The policies you select are applied only to the specific VPN topology you are creating. If you want the selected policies to be applied to all future VPN topologies when they are created, you must change the policy defaults selection on the VPN Policy Defaults page (Tools > Security Manager Administration > VPN Policy Defaults). For more information, see VPN Policy Defaults Page, page A-41.

Note You cannot view or assign VPN policy defaults when editing a VPN topology.

For more information, see Understanding VPN Default Policies, page 9-8.

Before You Begin

Make sure that the default VPN policies you want to assign are selected on the VPN Policy Defaults page (VPN Policy Defaults Page, page A-41).

Related Topics

• VPN Defaults Page, page G-28


• Understanding VPN Default Policies, page 9-8



Step 3 From the Endpoints, High Availability, or GET VPN Peers page, click Next. The Defaults page opens. For a description of the elements on this page, see VPN Defaults Page, page G-28.

Step 4 For each policy type, select the VPN policy you want to assign to your VPN topology.

You can select the Factory Default policy (available for a mandatory policy only) or select a shared VPN policy that appears in the list. If a shared policy was not already selected in the Administration tool’s VPN Policy Defaults page for an optional policy, none will be assigned.

Note If you try to select a default policy that is locked by another user, a message is displayed warning you of a lock problem. To bypass the lock, select a different policy or cancel the VPN topology creation until the lock is approved. For more information, see Understanding Locking, page 6-7.

Step 5 To view the contents of a selected VPN policy, click the View Content button.

Step 6 Click Finish. The new 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 G-73.

About Editing a VPN TopologyYou 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,


OL-19983-01


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, for example, change an IKE algorithm that was originally defined to a more secured one, or change the DES encryption algorithm for a VPN to make it more secure.

For the procedure to edit a VPN topology, see Editing a VPN Topology, page 9-27.

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 edit 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, page 9-42.

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 to other users who access that policy. For more information, see Understanding Locking, page 6-7.

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 device 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 Installation Guide for Cisco Security Manager.

Note The information displayed on 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 maintains the device locking in this VPN topology, which means that these devices cannot be deleted from the inventory. See Peers Page, page G-59.

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.


OL-19983-01

http://www.cisco.com/en/US/products/ps6498/prod_installation_guides_list.html


Related Topics

• Editing a VPN Topology, page 9-27


Editing a VPN TopologyYou can edit most settings in a VPN topology using the Edit VPN dialog box. The tabs in the Edit VPN dialog box display the same contents that 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.

These are the exceptions to what you can edit:

• You cannot edit the assigned IPsec technology. To edit the technology, you must delete the VPN topology and create a new one.

• You can change only the name and description of a GET VPN using the Edit VPN wizard. If you need to make changes to other policies and settings, open the policies from the Site-to-Site Manager page. For more details, see Configuring GET VPN, page 9-88.

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 Managing VPN Devices in Device View, page 9-42.

Before You Begin

• Make sure the VPN topology you want to edit appears in the VPNs selector in the Site-to-Site VPN window.

Related Topics




• Defining a Name and IPsec Technology, page 9-16




• Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPNSPA/VSPA, page 9-33


• Configuring High Availability in Your VPN Topology, page 9-41



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 G-2 on page G-4.

Step 3 If required, edit the name and description of the VPN topology.


OL-19983-01


Step 4 Click the Device Selection tab 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, page 9-18.

Note To remove devices from your VPN topology, select them on the Device Selection tab, and click <<.

Step 5 Click the Endpoints tab to do any of the following:

• 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.

• Define FWSM settings for a Catalyst 6500/7600 device.

Then, select the device(s) you want to edit in the Endpoints table, 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 G-10.

Note You can also use the Edit Endpoints dialog box to define the VPN Services Module (VPNSM) or VPN SPA 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 G-12 on page G-24.

Step 7 Click OK.

Deleting a VPN TopologyDeleting a VPN topology removes 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.

Related Topics

• Site-to-Site VPN Manager Window, page G-1


Step 1 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.


OL-19983-01


Understanding Dial BackupDial 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). In Easy VPN, the backup configuration is attached to the dialer interface.

Depending on the IOS version, Response Time Reporter (RTR) or Service Level Agreement (SLA) IOS technology, 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 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 on Cisco IOS security routers which are spokes in a hub-and-spoke, point-to-point, or full mesh VPN topology. Dial backup can also be configured on a remote client router running IOS version 12.3(14)T in an Easy VPN topology. For more information, see Understanding Easy VPN, page 9-71.

Related Topics


• Dialer Interfaces on Cisco IOS Routers, page 13-22

• VPN Interface Tab, page G-10

• Dial Backup Settings Dialog Box, page G-22

Configuring Dial BackupThis procedure describes how to configure dial backup on a router that is in a point-to-point or full mesh VPN topology, or that is a spoke in a hub-and-spoke topology, or is a remote client in an Easy VPN topology.


OL-19983-01


Before You Begin

• Create your VPN topology. See Using the Create VPN Wizard, page 9-14.

• Make sure the selected device is a Cisco IOS security router.

• Make sure you have configured the dialer interface settings on the device. For more information, see Dialer Interfaces on Cisco IOS Routers, page 13-22.

• Make sure that the primary route is functioning.

Related Topics

• Understanding Dial Backup, page 9-29


• Understanding Easy VPN, page 9-71

• Edit Endpoints Dialog Box, page G-10

• VPN Interface Tab, page G-10

• Dial Backup Settings Dialog Box, page G-22

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 G-6 on page G-11.

Step 2 If required, edit the primary VPN interface for the selected device.

Step 3 To enable the configuration of a backup interface, select the Enable Backup check box.

Step 4 Specify the physical interface through which the secondary route traffic will be directed when the logical dialer interface is activated.

Step 5 If the selected IPsec technology is Regular IPsec, IPsec/GRE, GRE Dynamic IP, or Easy VPN, enter the next hop IP address. If you do not enter the next hop IP address, Security Manager configures a static route using the interface name.

Step 6 Specify the tracking IP address.

Note If you do not specify an IP address, the primary hub VPN interface is used for a hub-and-spoke VPN topology or Easy VPN topology. In a point-to-point or full mesh VPN topology, the peer VPN interface is used.

Step 7 If the selected IPsec technology is Regular IPsec, IPsec/GRE, GRE Dynamic IP, or Easy VPN, 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 G-11 on page G-23.

a. Enter the next hop IP address of the ISDN BRI or analog modem to which the backup interface will connect when it is active.


OL-19983-01


b. Specify the tracking object settings by entering the required values in the Timeout, Frequency, and Threshold fields.

c. Click OK.

Step 8 Click OK in the Edit Endpoints dialog box.

Procedure for Configuring a VPNSM or VPN SPA/VSPASecurity Manager supports the configuration of Cisco VPN Services Module (VPNSM), Cisco VPN Shared Port Adapters (VPN SPAs), and Cisco VPN Service Port Adapters (VSPAs) on Catalyst 6500/7600 devices and Cisco IOS 7600 routers.

The device can be in a point-to-point or full mesh VPN topology, or a hub or spoke in a hub-and-spoke 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. Due to the design of the blades, you can install one VPNSM or two VPNSPA/VSPA per slot. The location of a VPNSPA/VSPA is identified with a slot and subslot number. Security Manager stores this information in its inventory, so that Security Manager can manage the VPN topologies.

This procedure describes how to configure a VPN Services Module (VPNSM), VPN SPA, or VSPA on a Catalyst 6500/7600 device.

General Notes

• If you are configuring intra-chassis high availability, you cannot use a VPNSM blade and a VPNSPA/VSPA blade on the same device, as primary and failover blades.

• In a remote access VPN, you can configure only one failover unit for each IPsec proposal. See VPNSM/VPN SPA Settings Dialog Box, page H-87.

Notes for VPNSMs

• Security Manager also supports the configuration of a Firewall Services Module (FWSM) with a VPNSM on a Catalyst 6500/7600 device. For a description of this feature, see Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPNSPA/VSPA, page 9-33.

• Security Manager supports the configuration of multiple VPNSMs on a Catalyst 6500/7600 device, but only one module (or two if you are configuring intra chassis high availability) can be configured per VPN topology.

• VPNSM configuration requires that its parent Catalyst 6500/7600 device is running Catalyst OS release 12.2(18)SXD1 and later.

• You can use only Layer 3 VLANs for VPNSM configuration. For more information, see Creating or Editing VLANs, page 15-5.

Notes for VPNSPA/VSPAs

• This procedure also applies if you are configuring an IPsec Terminator in a large scale DMVPN configuration. For more information, see Configuring Large Scale DMVPNs, page 9-70.

• 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, page 9-45.


OL-19983-01


In VRF mode, the crypto engine slotslot/subslot {inside | outside} command is deployed on the inside and outside VPN interfaces.

• Make sure that the Catalyst 6500/7600 device is running Catalyst OS release 12.2(18)SXE2 or later.

• If you plan to use Crypto Connect Alternate mode (whereby encrypted traffic entering the VPNSM/VPN SPA is passed through and cleartext traffic is bypassed), the Catalyst 6500/7600 device must be running Catalyst OS 12.2(33)SXH or higher.

• In the case of a DMVPN topology in which multiple hubs participate, if one hub 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.

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 Devices from the Network, page 5-8.

• If you are configuring a VPNSM or VPNSPA/VSPA 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 VPNSPA/VSPA without VRF-Aware IPsec, make sure that the device belongs to a different VPN topology in which VRF-Aware IPsec is configured.

• 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.

Related Topics

• VPN Interface Tab—VPNSM/VPN SPA Settings, page G-14

Step 1 On the device, create the VLANs you require or edit any existing ports or VLANs. For more information, see Creating or Editing VLANs, page 15-5.

Step 2 In Security Manager, click the Site-To-Site VPN Manager button on the toolbar. The Site-to-Site VPN Manager window opens.

Step 3 Open the Endpoints page to define or edit the VPNSM/VPN SPA settings for the Catalyst 6500/7600 device. If you are creating a VPN topology, use the Create VPN wizard and go to the Endpoints page. For a description of the elements on the Endpoints page, see Table G-5 on page G-8. If you are editing a VPN topology, right-click it and select Edit, then click the Endpoints tab.

Step 4 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 5 Configure the settings, as follows:

• If the Catalyst 6500/7600 device is running Catalyst OS 12.2(33)SXH or higher, enable or disable the Use Crypto Connect Alternate (CCA) checkbox, as appropriate. When enabled, only encrypted traffic entering the VPNSM/VPN SPA on the Catalyst 6500/7600 is passed through. Cleartext traffic is not passed through the adapters.


OL-19983-01


This mode is recommended as an alternate to Crypto connect mode for Enterprise customers who have a need to support large VPN topologies (Financial institutions etc.,) or need to pass large amounts of data over an encrypted channel (remote disaster recovery or backup over Internet)

• In the Inside VLAN field, select the inside VLAN you created or edited.

• Select the slot to which the inside VLAN interface will be connected. If you are configuring a VPN SPA or VSPA, you must also specify the number of the subslot (0 or 1) on which the port adapter is installed.

• Select the outside VLAN or external port to the inside VLAN.

• Specify the tunnel source: inside VLAN, outside VLAN, or interface.

• For local peer IPSec termination, specify whether to use the tunnel source IP address or a specified IP address.

• (Optional) To configure high availability, select the Enable Failover Blade check box. Then select the failover blade slot number (and subslot number if using VPN SPA or VSPA).

For a description of the elements on the VPN Interface tab, see Table G-7 on page G-15.

Step 6 Click OK.

Configuring a Firewall Services Module (FWSM) Interface with VPNSM or VPNSPA/VSPA

Security Manager supports the configuration of a Firewall Services Module (FWSM) with a VPNSM or VPNSPA/VSPA on a Catalyst 6500 device. This feature enables a FWSM to apply firewall policies to untrusted clients, while the VPNSM or VPN SPA/VSPA provides secure access to the internal network.

Before You Begin

• If the required Catalyst 6500 device is not already in the Security Manager inventory, import it into the inventory and define (or discover) its security contexts. See Adding Devices from the Network, page 5-8 and Security Contexts Page, page K-198.

• If an inside interface is not already created on the Catalyst 6500 device, you must create it (see Creating or Editing VLANs, page 15-5). Then, you must assign the FWSM inside interface (VLAN) to the appropriate security context, or directly to the FWSM blade.

Related Topics

• FWSM Tab, page G-18



• Adding Devices from the Network, page 5-8

• Creating or Editing VLANs, page 15-5



OL-19983-01


Step 2 If you are creating a VPN topology:

a. Open the Create VPN wizard by clicking Create a VPN Topology and selecting a hub and spoke topology. The Create VPN wizard opens, displaying the Name and Technology page. For a description of the elements on this page, see Name and Technology Page, page G-3.

b. Enter a name and description for the VPN topology, and select the IPsec technology, then click Next.

c. On the Device Selection page, select the devices that will be included in your VPN topology. Designate the Catalyst 6500 device containing the FWSM as a hub. For a description of the elements on the Device Selection page, see Device Selection Page, page G-4.

d. Click Next. The Endpoints page opens. For a description of the elements on the Endpoints page, see Table G-5 on page G-8.

Step 3 If you are editing a VPN topology:

a. In the VPNs selector, right-click the VPN topology which contains your Catalyst 6500 device, and select Edit. The Edit VPN page opens.

b. Click the Endpoints tab.

Step 4 Select the row in the table that contains the required Catalyst 6500 device, and click Edit. The Edit Endpoints dialog box opens.

Note You can select more than one Catalyst 6500 device at a time for editing. The changes you make are applied to all the selected devices.

Step 5 In the VPN Interface tab, configure the VPNSM or VPNSPA/VSPA settings. For a description of the elements on this tab, see Table G-7 on page G-15.

Step 6 Click the FWSM tab, and configure the FWSM settings, as follows:

a. Select the Enable FWSM Settings check box.

b. Specify the Firewall inside VLAN you created or edited.

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.

For a description of the elements on this tab, see Table G-9 on page G-19.

Step 7 Click OK.

Understanding VRF-Aware IPsecOne 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


OL-19983-01


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-37.

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 in a two-box solution provides better scaling for each function.


• VRF-Aware IPsec One-Box Solution, page 9-35

• VRF-Aware IPsec Two-Box Solution, page 9-36

Related Topics


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.

Figure 9-4 shows the topology of a one-box solution.


OL-19983-01

http://www.cisco.com/en/US/products/sw/netmgtsw/ps4748/products_user_guide_list.html


Figure 9-4 VRF-Aware IPsec One-Box Solution

Related Topics

• Understanding VRF-Aware IPsec, page 9-34



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.

Figure 9-5 shows the topology of a two-box solution.


OL-19983-01




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 is 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 IPsec/GRE or DMVPN is the selected technology.


OL-19983-01


Related Topics




Configuring VRF-Aware IPsec SettingsThe following procedure describes how 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 Using the Create VPN Wizard, page 9-14.

• Before you configure VRF-Aware IPsec on your devices, you should know 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, page 9-39.

– 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.

Related topics


• VRF-Aware IPsec One-Box Solution, page 9-35

• VRF-Aware IPsec Two-Box Solution, page 9-36

• VRF Aware IPsec Tab, page G-19


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 G-5 on page G-8.

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 G-10 on page G-20.


OL-19983-01


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.

Step 7 Enter the name of the VRF routing table and its unique route distinguisher in the appropriate fields.

Step 8 To configure 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.

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 To configure a two-box solution with the OSPF routing protocol, specify the ID number of the area in which the packet belongs.

Step 11 To configure 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 To configure 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.

Understanding High AvailabilityHigh 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 in a hub-and-spoke VPN topology when Regular IPsec is the assigned technology, or in an Easy VPN topology.

In Security Manager, HA is supported by 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.

Enabling Stateful Failover


OL-19983-01


You can enable stateful failover for your HA groups. With stateful failover, Stateful SwitchOver (SSO) ensures 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 must be configured in an Easy VPN topology.

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 be configured together with PKI configuration, but only on devices with Cisco IOS version 12.3(14)T and later.

If you do not enable stateful failover, stateless failover (HSRP without SSO) is configured on the HA group. Stateless failover is also configured if the HA group contains more than two hubs.

Prerequisites for Successful High Availability Configuration

Keep the following points in mind when working with HA groups:

• High Availability may be configured only on hubs in a hub-and-spoke VPN topology when the assigned technology is Regular IPsec, or in an Easy VPN topology.

• You can configure high availability only on Cisco IOS routers or Catalyst 6500/7600 devices.

• You cannot configure High Availability on hubs that have been configured with VRF-Aware IPsec. See Understanding VRF-Aware IPsec, page 9-34.

• You cannot configure GRE on an HA group.

• A device in an HA group can belong to more than one hub-and-spoke topology.

• A device configured as a hub in a site-to-site VPN with an HA configuration cannot be configured as a hub in a different site-to-site VPN with an HA configuration using the same outside interface. Similarly, such a device cannot be configured as a remote access VPN server on which HA is configured, using the same outside interface.

• 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. See the section on Enabling Stateful Failover.

• 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, page 9-57.

• 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.

Related Topics

• Map Settings Dialog Box, page B-11

• Configuring High Availability in Your VPN Topology, page 9-41


OL-19983-01




Configuring High Availability in Your VPN TopologyThe configuration of High Availability is an optional step of the Create VPN wizard. You can configure High Availability in a hub-and-spoke VPN topology when Regular IPsec is the assigned technology, or in an Easy VPN topology.

For a description of the high availability feature, see Understanding High Availability, page 9-39.

You can configure High Availability in the fourth step of the Create VPN wizard. This procedure describes how to define a group of hubs as a High Availability (HA) group.

Before You Begin:

• Please read the prerequisites for successful High Availability configuration. See Understanding High Availability, page 9-39.

• Create your hub-and-spoke VPN topology with Regular IPsec or Easy VPN as the selected technology. See Using the Create VPN Wizard, page 9-14.

• Make sure your device selection includes the appropriate devices.

Related Topics

• Map Settings Dialog Box, page B-11

• Understanding High Availability, page 9-39



Step 1 In the Site-to-Site VPN Manager window, right-click the VPN topology on which you want to configure High Availability, and click Edit. The Edit VPN dialog box opens.

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 G-12 on page G-24.

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 address, including subnet mask, that will be shared by the hubs in the HA group and will represent the inside interface of the HA group.

Step 5 Enter the virtual IP address, including subnet mask, that will be shared by the hubs in the HA group and will represent the VPN interface of the HA group.

Step 6 Specify the interval between each hello message sent by a hub to the other hubs in the group to indicate status and priority.

Step 7 Specify 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.

Step 8 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.


OL-19983-01

Chapter 9 Managing Site-to-Site VPNsManaging VPN Devices in Device View

Note Inside and outside standby group numbers must be different.

Step 9 If required, select the Stateful Failover check box to enable the use of SSO for stateful failover on the HA group. When this check box is deselected, stateless failover is configured on the HA group.

Note In an Easy VPN topology, this check box appears selected and disabled, as stateful failover must always be configured.

For more information, see Understanding High Availability, page 9-39.

Step 10 Click OK.

Managing VPN Devices in Device ViewDevice 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 or topologies to which each device in the CSM 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 differs 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 Understanding Policy Object Overrides for Individual Devices, page 8-9.

This procedure describes how to create or edit a VPN topology from Device view.

Related Topics





• Create VPN Wizard, page G-2

Step 1 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 Policy 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 G-42 on page G-76.


OL-19983-01

Chapter 9 Managing Site-to-Site VPNsWorking with Site-to-Site VPN Policies

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 in Using the Create VPN Wizard, page 9-14. For a description of the elements in the pages of the wizard, see Create VPN Wizard, page G-2.

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 G-4.

b. Edit the device structure or any other properties of the VPN topology, as required.

c. 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 Policy 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 G-29.

Working with Site-to-Site VPN PoliciesSecurity 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.

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 G-1 on page G-2.

Note When you define policies, 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 Policies in Policy View, page 6-35.

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 CSM inventory belongs, and if necessary, change its assignment to or from a VPN topology. You can right-click a policy in the Policy 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.


OL-19983-01


For more information, see Managing VPN Devices in Device View, page 9-42.

Related Topics

• Understanding Policies, page 6-1




• Site to Site VPN Policies, page G-29

Managing Shared Site-to-Site VPN Policies in Policy ViewIn 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.

Related Topics



• Managing Shared Policies in Policy View, page 6-35

Step 1 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 are displayed in the Shared Policy selector 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 Shared Policy 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 Shared Policy 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, page 9-43.

Step 6 To view or edit the policy assignment:

a. Select the policy in the Shared Policy 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 D-17.


OL-19983-01


b. If required, modify the list of VPN topologies to which the policy is assigned. See Modifying Policy Assignments in Policy View, page 6-39.

Understanding IKEInternet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and to 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.

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 matches 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, page 9-45.

• Which hash algorithm to use for integrity checking. See Deciding Which Hash Algorithm to Use, page 9-46.

• Which Diffie-Hellman group to use to operate the encryption algorithm. See Deciding Which Diffie-Hellman Group to Use, page 9-46.

• Which device authentication method to use. See Deciding Which Authentication Method to Use, page 9-47.

• For how long the IKE SA will be valid.

Related Topics

• Configuring an IKE Proposal, page 9-47

• IKE Proposal Page, page G-53

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.


OL-19983-01


• 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, page 9-45


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



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. ,Considered good protection for 128-bit keys, but group 14 is better.

• 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.

• Diffie-Hellman Group 14: 2048-bit modulus, considered good protection for 128-bit keys.




OL-19983-01


Related Topics



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, page 9-56.

• 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, page 9-57.

Related Topics



Configuring an IKE ProposalIn 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 one.

Note For more information about the IKE (Internet Key Exchange) key management protocol, see Understanding IKE, page 9-45.

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 one.

Before You Begin



OL-19983-01


Related Topics

• Managing Shared Site-to-Site VPN Policies in Policy View, page 9-44

• Configuring Local Policies in Device View, page 6-20


• Understanding Preshared Key Policies, page 9-56

• IKE Proposal Page, page G-53


Step 2 In the VPNs selector, select the desired VPN topology.

Step 3 Select IKE Proposal Policy 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 G-29 on page G-54.

Step 4 To assign a different IKE proposal, click Select. The Select IKE Policy Object dialog box opens. Select the desired IKE proposal from list and click OK. If the required IKE proposal is not included in the list, click Add to create an IKE proposal object. For more information, see Add or Edit IKE Proposal Dialog Box, page F-53.

Understanding IPsec Tunnel PoliciesIPsec 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. A crypto map combines all the components required to set up IPsec security associations, including transform sets. A crypto map may also be configured with Reverse Route Injection (RRI).

The following topics provide more information:

• About Crypto Maps, page 9-49

• About Transform Sets, page 9-49

• About Reverse Route Injection, page 9-50

Related Topics

• Configuring IPsec Proposals, page 9-51


OL-19983-01


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, page 9-48

• About Transform Sets, page 9-49


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, you don’t usually have 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.


OL-19983-01


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 Creating IPSec Transform Set Objects, page 8-36.

Related Topics




About Reverse Route Injection

Reverse Route Injection (RRI) enables static routes to be automatically inserted into the routing process for those networks and hosts protected by a remote tunnel endpoint. These protected hosts and networks are known as remote proxy identities. Each route is created on the basis of the remote proxy network and mask, with the next hop to this network being the remote tunnel endpoint. By using the remote VPN router as the next hop, the traffic is forced through the crypto process to be encrypted.

After the static route is created on the VPN router, this information is propagated to upstream devices, allowing them to determine the appropriate VPN router to which to send returning traffic in order to maintain IPsec state flows. This is particularly useful if multiple VPN routers are used at a site to provide load balancing or failover, or if the remote VPN devices are not accessible via a default route. Routes are created in either the global routing table or the appropriate virtual route forwarding (VRF) table.

Note Security Manager automatically configures RRI on devices with High Availability (HA), or on the IPsec Aggregator when VRF-Aware IPsec is configured.

You can configure RRI on a device’s crypto map in a remote access VPN. See Configuring an IPsec Proposal on a Remote Access VPN Server, page 10-38.


OL-19983-01


In Security Manager, the following options are available for configuring Reverse Route Injection:

• For dynamic crypto maps, routes are created upon the successful establishment of IPsec SAs for those remote proxies. The next hop back to those remote proxies is via the remote VPN router whose address is learned and applied during the creation of the dynamic crypto map template. The routes are deleted after the SAs are deleted.

• The Remote Peer option enables you to specify an interface or address as the explicit next hop to the remote VPN device. Two routes are created. One route is the standard remote proxy ID and the next hop is the remote VPN client tunnel address. The second route is the actual route to the remote tunnel endpoint, when a recursive lookup is forced to impose that the remote endpoint is reachable via “next-hop.” Creation of the second route for the actual next hop is very important for VRF-Aware IPsec when a default route must be overridden by a more explicit route.

Note For devices using a VPN Services Module (VPNSM), the next hop is the interface or subinterface/VLAN on which the crypto map is applied.

• In the case of Remote Peer IP, one route is created to a remote proxy by way of a user-defined next hop. The next hop can be used to override a default route, to properly direct outgoing encrypted packets. This option reduces the number of routes created and supports those platforms that do not readily facilitate route recursion.

Related Topics




• Configuring an IPsec Proposal on a Remote Access VPN Server, page 10-38

Configuring IPsec ProposalsIn 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


Related Topics


• About Reverse Route Injection, page 9-50


• IPsec Proposal Page, page G-55


Step 2 In the VPNs selector, select the required VPN topology.


OL-19983-01


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 G-31 on page G-56.

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.

Step 6 To generate and use a unique session key for each encrypted exchange, select the Enable Perfect Forward Secrecy check box. Then, select the required Diffie-Hellman key derivation algorithm from the Modulus Group list.

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 To enable Cisco IOS Quality of Service services to operate in conjunction with tunneling and encryption on an interface, select the QoS Preclassify check box.

Step 9 Select the required option to configure Reverse Route Injection (RRI) on the crypto map (on a PIX 7.0, ASA, or IOS router except 7600 device).

Understanding VPN Global SettingsIn 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, page 9-52

• Understanding NAT, page 9-53

• Understanding Fragmentation, page 9-54

Related Topics

• Configuring VPN Global Settings, page 9-55

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, which 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, page 9-47.

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.


OL-19983-01


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 G-66.

Related Topics


• ISAKMP/IPsec Settings Tab, page G-66

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), is not 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 13-10.

Note 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 J-8). To exclude NAT on PIX Firewalls or ASA devices, make sure this check box is selected in the NAT Translation Options platform policy (see Translation Options Page, page K-6).

About NAT Traversal

NAT traversal is used for the transmission of keepalive messages 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.


OL-19983-01


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 enabled by default on routers running IOS version 12.3T and later. If you want to disable the NAT traversal feature, you must do this manually on the device or using a FlexConfig (see Chapter 18, “Managing FlexConfigs”).

You can define global NAT settings on the NAT Settings tab of the Global VPN Settings page.

Related Topics


• NAT Settings Tab, page G-68

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 68 and 65535 bytes, depending on the VPN interface.

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).


OL-19983-01


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 G-39 on page G-70.

Related Topics


• General Settings Tab, page G-69

Configuring VPN Global SettingsOn 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.

The following procedure describes how to define global settings in your VPN topology.

Note For more information about global VPN settings, see Understanding VPN Global Settings, page 9-52.

Before You Begin


Related Topics


• Understanding ISAKMP/IPsec Settings, page 9-52

• Understanding NAT, page 9-53

• Understanding Fragmentation, page 9-54

• ISAKMP/IPsec Settings Tab, page G-66

• NAT Settings Tab, page G-68

• General Settings Tab, page G-69



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 G-37 on page G-66.

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 G-38 on page G-69.

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 G-39 on page G-70.


OL-19983-01


Understanding Preshared Key PoliciesIf you want to use preshared key as your authentication method, 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 i n 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.


OL-19983-01


Related Topics

• Deciding Which Authentication Method to Use, page 9-47

• Configuring Preshared Key Policies, page 9-57

• Preshared Key Page, page G-59

Configuring Preshared Key PoliciesThe following procedure describes how to edit the parameters of a preshared key policy defined for a VPN topology:

Before You Begin


Related Topics

• Understanding Preshared Key Policies, page 9-56


• Configuring Local Policies in Device View, page 6-20

• Preshared Key Page, page G-59


Step 2 In the VPNs selector, select the desired VPN topology.

Step 3 Select Preshared Key in the Policies selector.

The Preshared Key page opens, displaying the defined parameters for the selected preshared key policy. For a description of the elements on this page, see Table G-32 on page G-60.

Step 4 Select to use either a specific preshared key, or to automatically generate a random key to the participating peers.

Step 5 Select the negotiation method required for exchanging key information, from the available options.

Understanding Public Key Infrastructure PoliciesSecurity 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.


OL-19983-01


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 Chapter 18, “Managing FlexConfigs”).

PKI policies may also be configured on devices in a remote access VPN.

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 Table F-98 on page F-143.

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 Secure Device Provisioning on Cisco IOS Routers, page 13-71.


OL-19983-01


Related Topics

• Prerequisites for Successful PKI Enrollment, page 9-59

• Configuring Public Key Infrastructure Policies, page 9-61

• Creating PKI Enrollment Objects, page 8-69

• Public Key Infrastructure Page, page G-62

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.

• When configuring a trustpoint, you must specify one of the Certificate Revocation List (CRL) checking options. For more information, see PKI Enrollment Dialog Box—CA Information Tab, page F-144.

• 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 PKI Enrollment Dialog Box—Enrollment Parameters Tab, page F-148.

• 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 PKI Enrollment Dialog Box—Certificate Subject Name Tab, page F-150.

• 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.


OL-19983-01


• 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 Chapter 18, “Managing FlexConfigs”.

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, page 9-61



• Configuring a User Group Policy for Easy VPN, page 9-77


OL-19983-01


Configuring Public Key Infrastructure PoliciesYou 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, page 9-57.

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


• 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, page 9-59.

Related Topics


• Understanding Public Key Infrastructure Policies, page 9-57


• Deciding Which Authentication Method to Use, page 9-47




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 G-33 on page G-62.

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 F-142.

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.


OL-19983-01


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 Chapter 18, “Managing FlexConfigs”).

Understanding GREGeneric 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 the following:

• 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.

• 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.


OL-19983-01


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 an 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 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 device subnet, a static route is created on the device pointing to the corresponding tunnel interface.

For more information about routing protocols, see Chapter 12, “Managing IPS Services”.

• 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


OL-19983-01


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 IPsec/GRE is the selected IPsec technology. See Understanding IPsec Technologies and Policies, page 9-5.

Related Topics

• GRE Modes Page, page G-42

• Understanding GRE Configuration for Dynamically Addressed Spokes, page 9-64

• Configuring GRE or GRE Dynamic IP Policies, page 9-65

Understanding GRE Configuration for Dynamically Addressed Spokes

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 I OS 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 Adding, Editing, or Deleting Auto Update Servers or Configuration Engines, page 5-14.


OL-19983-01


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, page 9-5.

Related Topics

• Understanding GRE, page 9-62

• Configuring GRE or GRE Dynamic IP Policies, page 9-65


Configuring GRE or GRE Dynamic IP PoliciesThe following procedure describes how to configure IPsec tunneling with GRE or GRE Dynamic IP in your site-to-site VPN.

Before You Begin


• 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, page 9-59.

Related Topics


• Understanding GRE, page 9-62

• Understanding GRE Configuration for Dynamically Addressed Spokes, page 9-64




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—IPsec/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 G-24 on page G-43.

Step 4 On 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.

• 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 and the failover route interface, in microseconds.


OL-19983-01


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.

• Enter the ID number of the area in which the remote protected networks will be advertised, including the tunnel subnet.

• Enter a string that specifies the OSPF authentication key.

• Specify the cost of sending a packet on the primary route interface and the secondary (failover) route interface.

•

c. If you selected the RIPv2 routing protocol:

• Enter a string that specifies the RIPv2 authentication key.


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 13, “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 radio buttons to specify the GRE or GRE Dynamic IP tunnel interface IP address. For more information, see Table G-24 on page G-43.

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 new 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 Basic Interface Settings on Cisco IOS Routers, page 13-13.


OL-19983-01


Understanding DMVPN

Note For information about large scale DMVPNs, see Configuring Large Scale DMVPNs, page 9-70.

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 IPS Services”.

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 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


OL-19983-01


support DMVPN, use GRE dynamic IP to configure GRE for dynamically addressed spokes. See Understanding GRE Configuration for Dynamically Addressed Spokes, page 9-64.

DMVPN is not supported on Catalyst VPN Services Module devices or on High Availability (HA) groups.

You can configure the DMVPN settings in the GRE Modes page when DMVPN is the selected IPsec technology. See Understanding IPsec Technologies and Policies, page 9-5.

An advanced phase of DMVPN enables the use of shortcut switching enhancements to increase network performance and scalability. For information about migrating to the next phase of DMVPN, see the following URL on Cisco.com: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6660/ps6808/prod_white_paper0900aecd8055c34e_ps6658_Products_White_Paper.html.

Related Topics

• Configuring DMVPN Policies, page 9-68

• Configuring Large Scale DMVPNs, page 9-70


Configuring DMVPN PoliciesThe following procedure describes how to configure DMVPN with GRE in your site-to-site VPN.

Before You Begin


• Make sure that the selected IPsec technology is DMVPN. For more information, see Understanding IPsec Technologies and Policies, page 9-5.

Related Topics


• Understanding DMVPN, page 9-67




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 G-25 on page G-47.

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.


OL-19983-01

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6660/ps6808/prod_white_paper0900aecd8055c34e_ps6658_Products_White_Paper.html

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6660/ps6808/prod_white_paper0900aecd8055c34e_ps6658_Products_White_Paper.html


• 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, 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.

• Enter the ID number of the area in which the remote protected networks will be advertised, including the tunnel subnet.

• Enter a string that specifies the OSPF authentication key.


•

c. If you selected the RIPv2 routing protocol:

• Enter a string that specifies the RIPv2 authentication key.


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 13, “Managing Routers”.

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 CSM 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.


OL-19983-01


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.

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 Basic Interface Settings on Cisco IOS Routers, page 13-13.

Step 8 In the NHRP Parameters area:

a. Enter a globally unique, 32-bit network identifier for the NHRP stations.

b. Enter the time that routers will keep information provided in authoritative NHRP responses.

c. Enter an authentication string that controls whether the source and destination NHRP stations allow intercommunication. All routers within the same network using NHRP must share the same authentication string.

Configuring Large Scale DMVPNsSecurity Manager supports DMVPN in large scale deployments that may comprise thousands of spokes. In large scale DMVPN topologies, IPsec Terminators, also referred to as Server Load Balance (SLB) devices, reside between the spokes and the hubs. The hubs are directly connected to the IPsec Terminator—there is no other device between them.

The IPsec Terminator, which is a Catalyst 6500/7600 device, performs encryption and decryption while the hubs handle all tasks related to Next Hop Resolution Protocol (NHRP) and multipoint generic routing encapsulation (mGRE). The IPsec Terminator is configured to specifically load balance GRE traffic to the hubs, and is configured with dynamic crypto to accept any spokes with any proxies. When using tunnel protection on spokes, these proxies are automatically set to match GRE traffic. One GRE tunnel is configured on the spokes. All hubs connecting to the same IPsec Terminator will use the same Tunnel IP, and the tunnel source is the Virtual IP address of the IPsec Terminator.

In Security Manager, you configure a Large Scale DMVPN during the creation of a hub-and-spoke VPN topology. You must select the IPsec Terminators in addition to the hubs and spokes.

Each hub in the DMVPN must identify itself and its protected networks, and must have an interface that is connected to at least one IPsec Terminator. For each IPsec Terminator in the DMVPN, you must specify a VPN external interface, the crypto engine slot and the Inside VLAN. The configuration of an IPsec Terminator is similar to that of a VPN SPA device. No protected networks are configured on an IPsec Terminator. After you create the DMVPN topology, a Server Load Balance policy is configured on the IPsec Terminators with all the required parameters, which you can edit, if required.

Note VRF-Aware IPsec cannot be configured in a large scale DMVPN.

This procedure describes how to configure a large scale DMVPN topology with a Server Load Balance policy.


OL-19983-01


Before You Begin

• Create your hub-and-spoke VPN topology, making sure that:

– The selected IPsec technology is DMVPN of type Large Scale with IPsec Terminator.

– The IPsec Terminators are Catalyst 6500/7600 devices.

– There is direct connectivity between the IPsec Terminators and the hubs.

Related Topics

• Server Load Balance Page, page G-63



Step 2 If you haven’t already done so, create your hub-and-spoke VPN topology, using the Create VPN wizard, making sure you do the following:

a. Select the DMVPN IPsec technology of type Large Scale with IPsec Terminator. See Defining a Name and IPsec Technology, page 9-16.

b. Select the required IPsec Terminators (Catalyst 6500/7600 devices), the hubs and all the spokes, in the Device Selection page. See Selecting Devices for Your VPN Topology, page 9-18.

c. In the Edit Endpoints dialog box:

• For each hub device, in the Hub Interface tab, select the interface that is connected to the IPsec Terminator. Each hub can be connected to only one IPsec Terminator.

• For each IPsec Terminator, specify a VPN external interface, the crypto engine slot and the Inside VLAN.

See Defining the Endpoints and Protected Networks, page 9-20.

A Server Load Balance policy is automatically configured on the IPsec Terminators with all the required parameters.

Step 3 In the VPNs selector, select the required hub-and-spoke large scale DMVPN topology.

Step 4 Select Server Load Balance in the Policies selector. The Server Load Balance page opens, displaying a table listing the server load balance parameters for each hub in the large scale DMVPN. For a description of the elements on this page, see Table G-34 on page G-63.

Step 5 If you want to modify the parameters of an entry in the table, select it and click Edit. The Edit Load Balancing Parameters dialog box opens. For a description of the elements on this dialog box, see Table G-35 on page G-64.

Step 6 Modify the Weight or Max Connections values, as required, and click OK. The dialog box closes and the modified entry is displayed in the table on the Server Load Balance page.

Understanding Easy VPNEasy VPN simplifies VPN deployment for remote offices. With 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.


OL-19983-01


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.

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, Cisco 800-3800 Series routers, and ASA 5505 devices running OS version 7.2 or later.

Note 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”.

The following sections describe:

• Easy VPN with Dial Backup

• Easy VPN with High Availability

• Easy VPN with Dynamic Virtual Tunnel Interfaces

Easy VPN with Dial Backup

Dial backup for Easy VPN allows you to configure a dial backup tunnel connection on your remote client device. The backup feature is activated only when real traffic is ready to be sent, eliminating the need for expensive dialup or ISDN links that must be created and maintained even when there is no traffic.

Note Easy VPN dial backup can be configured only on remote clients that are routers running IOS version 12.3(14)T or later.

In an Easy VPN configuration, when a remote device attempts to connect to the server and the tracked IP is no longer accessible, the primary connection is torn down and a new connection is established over the Easy VPN backup tunnel to the server. If the primary hub cannot be reached, the primary configuration switches to the failover hub with the same primary configuration and not to the backup configuration.

Only one backup configuration is supported for each primary Easy VPN configuration. Each inside interface must specify the primary and backup Easy VPN configuration. IP static route tracking must be configured for dial backup to work on an Easy VPN remote device. The object tracking configuration is independent of the Easy VPN remote dial backup configuration. The object tracking details are specified in the spoke’s Edit EndPoints dialog box.

For more information about dial backup, see Understanding Dial Backup, page 9-29. The procedure for configuring dial backup in an Easy VPN topology is described in Configuring Dial Backup, page 9-29.

Easy VPN with High Availability

You can also configure High Availability (HA) on devices in an Easy VPN topology. High Availability (HA) provides automatic device backup when configured on Cisco IOS routers or Catalyst 6500/7600 devices, running IP over LANs. Using Security Manager, you can create an HA group made up of two or more hub devices in your Easy VPN that use Hot Standby Routing Protocol (HSRP) to provide transparent, automatic device failover. For more information, see Understanding High Availability, page 9-39.

Easy VPN with Dynamic Virtual Tunnel Interfaces


OL-19983-01


The IPsec virtual tunnel interface (VTI) feature simplifies the configuration of GRE tunnels that need to be protected by IPsec for remote access links. A VTI is an interface that supports IPsec tunneling, and allows you to apply interface commands directly to the IPsec tunnels. The configuration of a virtual tunnel interface reduces overhead as it does not require a static mapping of IPsec sessions to a particular physical interface, where the crypto map is applied.

IPsec VTIs support both unicast and multicast encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is encrypted or decrypted when it is forwarded from or to the tunnel interface and is managed by the IP routing table. Dynamic or static IP routing can be used to route the traffic to the virtual interface. Using IP routing to forward traffic to the tunnel interface simplifies IPsec VPN configuration compared to the more complex process of using access control lists (ACLs) with a crypto map. Dynamic VTIs function like any other real interface so that you can apply quality of service (QoS), firewall, and other security services as soon as the tunnel is active.

Dynamic VTIs use a virtual template infrastructure for dynamic instantiation and management of IPsec interfaces. In an Easy VPN topology, Security Manager implicitly creates the virtual template interface for the device. If the device is a hub, the user must provide the IP address on the hub that will be used as the virtual template interface—this can be a subnet (pool of addresses) or an existing loopback or physical interface. On a spoke, the virtual template interface is created without an IP address.

Notes

• Dynamic VTI can be configured only in a hub-and-spoke Easy VPN topology on routers running IOS version 12.4(2)T and later, except 7600 devices. It is not supported on PIX Firewalls, ASA devices, or Catalyst 6000 series switches.

• Not all the hubs/spokes require Dynamic VTI configuration during discovery or provision. You can extend the existing EzVPN topology (including routers not supporting DVTI) to add routers which support DVTI.

• Dynamic VTI is supported on only servers, only clients (if server does not support DVTI), or both clients and servers.

• Dynamic VTI can be configured with or without VRF-Aware IPsec.

• You cannot configure High Availability on hubs/servers that have been configured with DVTI.

• You can also configure Dynamic VTI in remote access VPNs. For more information, see PVC Dialog Box—QoS Tab, page J-46.

In Security Manager, you configure Dynamic VTI in the Easy VPN IPsec Proposal page. See Configuring an IPsec Proposal for Easy VPN, page 9-75.

Overview of Configuring Easy VPN

When a remote client initiates a connection to a VPN server, device authentication between the peers occurs using IKE, followed by user authentication using IKE Extended Authentication (Xauth), VPN policy push (in Client, Network Extension, or Network Extension Plus 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 PKI Enrollment Dialog Box—Certificate Subject Name Tab, page F-150.


OL-19983-01


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), if configured, ensures that a static route is created on the device for each client internal IP address.

7. IKE quick mode is initiated to negotiate and create IPsec SAs.

The connection is complete.

Important Notes About Site-to-Site Easy VPN Configuration

Before you configure an Easy VPN policy in your topology, you should know 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, Cisco 800-3800 Series routers, and ASA 5505 devices running OS version 7.2 or later.


OL-19983-01


• 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, page 9-57.

• 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, on a Cisco 1700 series router the VPN interface must be the device’s FastEthernet0 interface. On a Cisco 800 series router the VPN interface could be either the device’s Ethernet0 or Dialer1 interface, depending on the configuration. On a Cisco uBR905/uBR925 cable access router, the VPN interface must be the Ethernet0 interface.

These procedures describe how to configure Easy VPN policies in your VPN topology:

• Configuring an IPsec Proposal for Easy VPN, page 9-75

• Configuring a User Group Policy for Easy VPN, page 9-77

• Configuring a Tunnel Group Policy for Easy VPN, page 9-78

• Configuring Client Connection Characteristics for Easy VPN, page 9-79

Related Topics

• Easy VPN IPsec Proposal Page, page G-38

• User Group Policy Page, page G-64

• Tunnel Group Policy (PIX 7.0/ASA) Page, page G-33

• Client Connection Characteristics Page, page G-30

Configuring an IPsec Proposal for Easy VPNConfiguring 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, page 9-49.

• Configure a dynamic virtual interface on a device in your Easy VPN topology. For more information, see Understanding Easy VPN, page 9-71.

• Configure Reverse Route Injection (RRI) on the crypto map (on a PIX 7.0, ASA, or IOS router except 7600 device). For more information, see About Reverse Route Injection, page 9-50.

• 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.


OL-19983-01


This procedure describes how to edit these IPsec policy definitions, if required.

Before You Begin

• Please read important notes about site-to-site Easy VPN configuration.


• Make sure that the selected IPsec technology is Easy VPN. For more information, see Understanding IPsec Technologies and Policies, page 9-5.

Related Topics



• Easy VPN IPsec Proposal Page, page G-38



Step 3 Select Easy VPN IPsec Proposal in the Policies selector.

The Easy VPN IPsec Proposal page appears, displaying the IPsec Proposal tab with the defined parameters for configuring an IPsec proposal on an Easy VPN server device. For a description of the elements on this tab, see Table G-22 on page G-40.

Step 4 Specify the transform sets 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 Creating IPSec Transform Set Objects, page 8-36.

Step 5 Select an option to configure a Reverse Route on the crypto map (on a PIX 7.0, ASA, or IOS router except 7600 device).

Step 6 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 7 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.

Step 8 Specify the AAA or Xauth user authentication method used to define the order in which user accounts are searched.

Step 9 If you are configuring Dynamic VTI on a hub in the topology, specify either the subnet address or interface role:

• Subnet—To use the IP address taken from a pool of addresses. Then, in the Subnet field, enter the private IP address including the unique subnet mask, for example 10.1.1.0/24.

• Interface Role—If required, click Select to open the Interface selector in which you can select or add an interface.

If you are configuring Dynamic VTI on a spoke in the topology, select None.

For a description of the elements on this tab, see Table G-23 on page G-42.


OL-19983-01


Configuring a User Group Policy for Easy VPNWhen 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.

Note An Easy VPN user group policy can be configured on a Cisco IOS security router, PIX 6.3 Firewall, or Catalyst 6500 /7600 device.

This procedure describes how to specify the user group you want to assign to your Easy VPN server.

Before You Begin


• Make sure that the selected device is an IOS router or PIX 6.3 device.



Related Topics


• Creating User Group Objects, page 8-93


• User Group Policy Page, page G-64



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 G-36 on page G-65.

Step 4 If you want to select a different user group, select it in the Available User Groups list. 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 Creating User Group Objects, page 8-93.

Note After creating a user group, you can modify its properties by selecting it, and clicking Edit.


OL-19983-01


Configuring a Tunnel Group Policy for Easy VPNA 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.

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.

RADIUS SDI Authentication

When you configure a tunnel group policy, if the authentication server group that you select uses SDI as the protocol, Radius SDI authentication is enabled. RADIUS SDI refers to the process of the secure gateway performing SDI authentication using a RADIUS SDI proxy, which communicates with the SDI server.

When this feature is enabled, you are prompted for the username and password from the RADIUS server for the Easy VPN and remote access VPN clients in response to an IKE Xauth challenge from the RADIUS authentication server or headend. Xauth lets you deploy IPSec on VPNs using RADIUS as your user authentication method within the IKE protocol.

A VPN client handles Radius SDI authentication the same as native SDI authentication, which makes authentication easier for VPN Client users to authenticate using SDI. This feature provides authentication to a user, who has the VPN client installed on their system, by prompting for a username and a password, and then verifies them with the information stored in the RADIUS database.

This procedure describes how to configure a tunnel group policy on your Easy VPN server.

Before You Begin





OL-19983-01


Related Topics



• Tunnel Group Policy (PIX 7.0/ASA) Page, page G-33



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 G-18 on page G-34.

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 G-19 on page G-35.

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 G-20 on page G-37.

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 G-21 on page G-38.

Configuring Client Connection Characteristics for Easy VPNEasy VPN connection characteristics specify how traffic will be routed in the VPN and how the VPN tunnel will be established, as described in these sections:




Easy VPN Configuration Modes

Easy VPN can be configured in three modes—Client, Network Extension, and Network Extension Plus.

• Client mode—The default configuration that allows devices at the client site to access resources at the central site, but disallows access to the central site for resources at the client site. In client mode, a single IP address is pushed to the remote client from the server when the VPN connection is established. This address is typically a routable address in the private address space of the customer network. All traffic passing across the Easy VPN tunnel undergoes Port Address Translation (PAT) to that single pushed IP address.

• Network Extension mode—Allows users at the central site to access the network resources at the client site, and allows the client PCs and hosts direct access to the PCs and hosts 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. The devices at both ends of the connection will form one logical network. PAT is not used, so the hosts at the client end


OL-19983-01


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 PAT.

• Network Extension Plus mode—An enhancement to Network Extension mode, which can be configured only on IOS routers. It enables an IP address that is received via mode configuration to be automatically assigned to an available loopback interface. This IP address can be used for connecting to your router for remote management and troubleshooting (ping, Telnet, and Secure Shell).

Note All 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).

Easy VPN and IKE Extended Authentication (Xauth)

When negotiating tunnel parameters for establishing IPsec tunnels in an Easy VPN configuration, IKE Extended Authentication (Xauth) adds another level of authentication that identifies the user who requests the IPsec connection. If the VPN server is configured for Xauth, the client waits for a "username/password" challenge after the IKE SA has been established. When the end user responds to the challenge, the response is forwarded to the IPsec peers for an additional level of authentication.

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.

Security Manager allows you to save the Xauth username and password on the device itself so you do not need to enter these credentials manually each time the Easy VPN tunnel is established. The information is saved in the device’s configuration file and used each time the tunnel is established. Saving the credentials in the device’s configuration file is typically used if the device is shared between several PCs and you want to keep the VPN tunnel up all the time, or if you want the device to automatically bring up the tunnel whenever there is traffic to be sent.

Saving the credentials in the device’s configuration file, however, could create a security risk, because anyone who has access to the device configuration can obtain this information. An alternative method for Xauth authentication is to manually enter the username and password each time Xauth is requested. Security Manager enables you to do this interactively in a web browser window or from the command line interface. Using web-based interaction, a login page is returned, in which you can enter the credentials to authenticate the VPN tunnel. After the VPN tunnel comes up, all users behind this remote site can access the corporate LAN without being prompted again for the username and password. Alternatively, you can choose to bypass the VPN tunnel and connect only to the Internet, in which case a password is not required.

Easy VPN Tunnel Activation

If the device credentials (Xauth username and password) are stored on the device itself, you must select a tunnel activation method. Two options are available:

• Auto—The Easy VPN tunnel is established automatically when the Easy VPN configuration is delivered to the device configuration file. If the tunnel times out or fails, the tunnel automatically reconnects and retries indefinitely. This is the default option.


OL-19983-01


• Traffic Triggered Activation—The Easy VPN tunnel is established whenever outbound local (LAN side) traffic is detected. Traffic Triggered Activation is recommended for use with the Easy VPN dial backup configuration so that backup is activated only when there is traffic to send across the tunnel. When using this option, you must specify the Access Control List (ACL) that defines the “interesting” traffic.

Note Manual tunnel activation is configured implicitly if you select to configure the Xauth password interactively. In this case, the device waits for a command before attempting to establish the Easy VPN remote connection. When the tunnel times out or fails, subsequent connections will also have to wait for the command.

This procedure describes how to configure the client connection characteristics for Easy VPN.

Before You Begin



• Please read Important Notes About Site-to-Site Easy VPN Configuration.

Related Topics



• Client Connection Characteristics Page, page G-30


Step 2 In the VPNs selector, select the required Easy 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 G-17 on page G-31.

Step 4 Select Client, Network Extension, or Network Extension Plus from the Mode list.

Note Network Extension Plus mode can be configured only on IOS routers.

Step 5 Select Device Stored Credentials or Interactive Entered Credentials depending on how you want to enter the Xauth credentials for user authentication when you establish a VPN connection with the server.

Step 6 If you selected Device Stored Credentials, select the Xauth credentials.

Step 7 If the device is an IOS router, and if you selected Interactive Entered Credentials for the Xauth credentials source, select Web Browser or Router Console depending on how you want to enter the Xauth credentials interactively.

Step 8 If the device is an IOS router, and if you selected Device Stored Credentials for the Xauth password source, select the Auto or Traffic Triggered Activation tunnel activation method.

Step 9 If you selected the Traffic Triggered Activation option for Tunnel Activation, specify the Access Control List (ACL) that defines the “interesting” traffic.


OL-19983-01


Understanding Group Encrypted Transport (GET) VPNsCisco’s Group Encrypted Transport VPN (GET VPN) introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members share a common security association (SA), also known as a group SA. This enables group members to decrypt traffic that was encrypted by any other group member. In GET VPN networks, there is no need to negotiate point-to-point IPsec tunnels between the members of a group, because GET VPN is “tunnelless.”

By removing the need for point-to-point tunnels, meshed networks can scale higher while maintaining network-intelligence features critical to voice and video quality. GET offers a new standards-based security model that is based on the concept of "trusted" group members. Trusted member routers use a common security methodology that is independent of any point-to-point IPsec tunnel relationship. By using trusted groups instead of point-to-point tunnels, "any-any" networks can scale higher while maintaining network-intelligence features (such as QoS, routing, and multicast), which are critical to voice and video quality.

GET-based networks can be used in a variety of WAN environments, including IP and Multiprotocol Label Switching (MPLS). MPLS VPNs that use this encryption technology are highly scalable, manageable, and cost-effective, and they meet government-mandated encryption requirements. The flexible nature of GET allows security-conscious enterprises either to manage their own network security over a service provider WAN service or to offload encryption services to their providers. GET simplifies securing large Layer 2 or MPLS networks that require partial or full-mesh connectivity.

In addition to leveraging the existing IKE, IPsec and multicast technologies, GET VPN solution relies on the following core building blocks to provide the required functionality:

• Group Domain of Interpretation Protocol (GDOI), page 9-82

• Key Servers, page 9-83

• Redundancy Using Cooperative Key Servers, page 9-85

• Group Members, page 9-84

• Group Security Association, page 9-86

• Rekey Mechanism, page 9-87

• Time-Based Anti-Replay, page 9-87

GET VPN is provisioned using Security Manager with the following caveats:

• GET VPN-aware VRF is not supported.

• DMVPN with GET is not supported, because there is no way to define DMVPN without tunnel protection in Security Manager.

• Fail Open/ Fail Close interface mode and Explicit Passive Mode IPSec SA features are not supported in Security Manager.

• Manual configuration of a group member to join a multicast group (ip igmp join-group) is not supported. Security Manager only provisions static source-specific multicast (SSM)mappings.

Group Domain of Interpretation Protocol (GDOI)

The Group Domain of Interpretation (GDOI) group key management protocol is used to provide a set of cryptographic keys and policies to a group of devices. In a GET VPN network, GDOI is used to distribute common IPsec keys to a group of enterprise VPN gateways (group members) that must communicate securely. Devices designated as key servers periodically refresh and send out the updated keys to the group members using a process called “rekeying.”


OL-19983-01


Tip For more information about GDOI, refer to RFC 3547.

GDOI is defined as the Internet Security Association Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) for group key management. In a group management model, the GDOI protocol operates between a group member and a key server, which establishes security associations (SAs) among authorized group members. The ISAKMP defines two phases of negotiation. The GDOI protocol uses the Phase 1 Internet Key Exchange (IKE) SA. All participating VPN gateways authenticate themselves to the device providing keys using IKE. All IKE authentication methods, for example, pre-shared keys (PSKs) and public key infrastructure (PKI), are supported for initial authentication. After the VPN gateways are authenticated and provided with the appropriate security keys via the IKE SA, the IKE SA expires and GDOI is used to update the group members in a more scalable and efficient manner.

GDOI introduces two different encryption keys. The Traffic Encryption Key (TEK) and the Key Encryption Key (KEK). The TEK is downloaded by the key server to all the group members. The downloaded TEK is used by all group members to communicate securely among each other. This key is essentially the group key that is shared by all the group members. The group policies and IPsec SAs are refreshed by the key server using periodic rekey messages to the group members. The KEK is also downloaded by the key server and is used by the group members to decrypt the incoming rekey messages from the key server.

Key Servers

Key servers maintain the security association (SA) policy and create and maintain the keys for the group. When a group member registers, the key server downloads the policy and the keys to the group member. The key server also rekeys the group before existing keys expire.

The key server has two modes of operation: servicing registration requests and sending rekeys. A group member can register at any time and receive the most current policy and keys. When a group member registers with the key server, the key server verifies the group ID that the group member is attempting to join. If group ID is valid, the key server sends the policy to the group member. After the group member acknowledges that it can handle the downloaded policy, the key server downloads the respective keys.

There are two types of keys that the key server can download: the key encryption key (KEK) and the traffic encryption key (TEK). The KEK encrypts the rekey message. The TEK becomes the IPsec SA with which group members communicate.

The key server sends out rekey messages either because of an impending IPsec SA expiration or because the policy has changed on the key server. Rekey messages may also be retransmitted periodically to account for possible packet loss. Packet loss can occur because rekey messages are sent without the use of any reliable transport. There is no efficient feedback mechanism by which receivers can indicate that they did not receive a rekey message, so retransmission seeks to bring all receivers up to date.

Note A device acting as a key server can not be configured as a group member. However, a device can act as the key server for more than one group.

Note You need to enabling multicast on key servers manually. Security Manager does not provision multicast commands.


OL-19983-01


Group Members

A group member is an IOS router responsible for actual data encryption and decryption. A group member is only configured with IKE phase 1 parameters and key server/group information. Encryption policies are defined centrally on the key server and downloaded to the group member at the time of registration. Based on these downloaded policies, a group member decides whether traffic needs to be encrypted or decrypted and what keys to use.

If required, a group member can be configured to override some of these policies locally. Any global policy (including both permit and deny entries) defined on the key server affects all the members of the group whether it is applicable to them or not and therefore some policies make more sense when defined locally. As an example, if a handful of group members in the group are running a different routing protocol, a local entry can be added to these group members to bypass encryption of the routing protocol traffic instead of defining the policy globally at the key server level.

Note A device can be a group member of more than one group.

Communication Flow Between Key Servers and Group Members

Figure 9-6 shows the protocol flows that are necessary for group members to participate in a group, as follows:

1. Group members register with the key server. The key server authenticates and authorizes the group members and downloads the IPsec policy and keys that are necessary for them to encrypt and decrypt IP multicast packets.

2. Group members exchange IP multicast packets that are encrypted using IPsec.

3. As needed, the key server "pushes" a rekey message to the group members. The rekey message contains new IPsec policy and keys to use when old IPsec SAs expire. Rekey messages are sent in advance of the SA expiration time to ensure that valid group keys are always available.

Figure 9-6 Communication Flow Between Key Servers and Group Members

Key server

Group member

Group member

Group member

1469

97

1 3

21

1


OL-19983-01


GET VPN Features

GET VPN provides the following advanced features:

• Group Member Access Control Lists, page 9-86

• Redundancy Using Cooperative Key Servers, page 9-85

• Group Security Association, page 9-86

• Recieve-Only Security Associations, page 9-87

• Rekey Mechanism, page 9-87

• Time-Based Anti-Replay, page 9-87

Redundancy Using Cooperative Key Servers

The key server is the most important entity in the GET VPN network because the key server maintains the control plane. Therefore, a single key server is a single point of failure for an entire GET VPN network. Because redundancy is an important consideration for key servers, GET VPN supports multiple key servers, called cooperative (COOP) key servers, to ensure seamless fault recovery if a key server fails or becomes unreachable.

A group member can be configured to register to any available key server from a list of all COOP key servers. Group member configuration determines the registration order. The key server defined first is contacted first, followed by the second defined key server, and so on.

Note The COOP protocol is configured on a per GDOI group basis. A key server that is configured with multiple GDOI groups can maintain multiple unique COOP relationships with disparate key servers.

When COOP key servers boot, all key servers assume a secondary role and begin an election process. One key server, typically the one having the highest priority, is elected as a primary KS. The other key servers remain in the secondary state. The primary key server is responsible for creating and distributing group policies to all group members, and to periodically synchronize the COOP key servers.

Note Group members can register to any available key server (primary or secondary), but only the primary key server sends rekey messages. It is a best practice to distribute group member registration to all available COOP key servers to reduce the IKE processing load on a single key server.

Cooperative key servers exchange one-way announcement messages (primary to secondary). If a secondary key server does not hear from the primary key server for a certain length of time, the secondary key server tries to contact the primary key server and requests updated information. If the primary key server does not respond, or if the secondary key server does not hear from the primary key server, a COOP key server reelection is triggered and a new primary key server is elected.

Up to eight key servers can be defined as COOP key servers, but more than four COOP key servers are seldom required. Since rekey information is generated and distributed from a single primary key server, the advantage of deploying more than two key servers is the ability to handle registration load in case of a network failure and reregistration taking place at the same time. This is especially important when using Public Key Infrastructure (PKI) because IKE negotiation using PKI requires a lot more CPU power compared to IKE negotiation using pre-shared keys (PSKs).


OL-19983-01


Tip It is a best practice to enable periodic ISAKMP keepalives between key servers so that the primary key server can track and display the state of the other secondary key servers. IKE Keepalives between group members and the key server is not required and is not supported.

Note Security Manager does not support automatic key synchronization between cooperative key servers. RSA keys need to be exported from the primary key server and imported on other key servers manually.

Group Member Access Control Lists

For GET VPN, the traffic that has to be protected is defined statically on the key server using the access control list (ACL). The group member gets information about what has to be protected from the key server. This structure allows the key server to choose and change the policy dynamically as needed. In Secure Multicast, the key server ACL is defined inclusively. The ACL includes only the exact traffic that should be encrypted, with an implicit deny causing all other traffic to be allowed in the clear (that is, if there is no permit, all other traffic is allowed).

GET VPN employs a different philosophy: the definition of which packets should be encrypted is delivered independently. GET VPN supports only statically defined traffic selectors. Policy can be defined by using both deny and permit ACLs on the key server. Only the deny ACL is allowed to be manually configured on a group member. The policies that are downloaded from the key server and configured on the group member are merged. Any ACL that is configured on the group member has predominance over what is downloaded from the key server.

After the group member gets the ACL from the key server, the group member creates a temporary ACL and inserts it into the database. This ACL will be deleted if the group member is removed from the GDOI group for any reason. The packets that are going out of the interface are dropped by the group member if a packet matches the ACL but no IPsec SA exists for that packet.

The key server can send a set of traffic selectors, which may not exactly match the group member ACL on the group member. If such differences occur, the differences have to be merged and resolved. Because the group member is more aware of its topology than the key server, the downloaded ACLs are appended at the end of the group member ACL. The group member ACL (except the implicit deny) is inserted into the database first, followed by the downloaded key server ACL. The database is prioritized, and the database search stops whenever a matched entry is found.

For information about configuring a group member ACL, see "Setting up Group Member ACLs" section."

Group Security Association

Unlike traditional IPsec encryption solutions, GET VPN uses the concept of group SA. All members in the GET VPN group can communicate with each other using a common encryption policy and a shared SA. With a common encryption policy and a shared SA, there is no need to negotiate IPsec between group members; this reduces the resource load on the IPsec routers. Traditional group member scalability (number of tunnels and associated SA) does not apply to GET VPN group member.

Note In a GET VPN group, up to 100 ACL permit entries can be used to define interesting traffic for encryption. Each permit entry results in a pair of IPsec SAs; the maximum number of IPsec SAs in a group can not exceed 200. It is a best practice to summarize interesting traffic to as few permit entries as possible, and to build symmetric policies. Unlike traditional IPSec policies, where source and


OL-19983-01


destination address ranges must be uniquely defined, GET VPN is optimized when the source and destination address range are the same. This minimizes the number of policy permutations, making GET VPN very efficient.

Recieve-Only Security Associations

For multicast traffic using the GDOI protocol, bidirectional SAs are installed. The Receive Only feature enables an incremental deployment so that only a few sites can be verified before bringing up an entire network. To test the sites, one of the group members sends encrypted traffic to all other group members and has them decrypt and forward the traffic "in the clear." Receive Only SA mode allows encryption in only the inbound direction for a period of time.

Rekey Mechanism

In the multicast rekey process, a key server generates a rekey message and sends one copy of the message to a multicast group address that is predefined in the configuration. Each group member joins the multicast group at registration time, so each group member receives a copy of the rekey message.

Unlike unicast rekey, multicast rekey does not have an ACK mechanism. The key server does not maintain a list of active group members. Multicast rekey uses the same low CPU overhead whether there is one group member in the group or a few thousand. Just like unicast rekey, the key server can be configured to retransmit a multicast rekey packet to overcome transient network defects.

Note Multicast must be enabled in the core network for multicast rekey to work in the GET VPN.

Note Security Manager does not manage RSA keys and therefore appropriate keys need to be manually generated on the key server before deployment. FlexConfig can be used. See Creating FlexConfig Policy Objects, page 18-26.

Note Security Manager does not support automatic key synchronization between cooperative key servers. RSA keys need to be exported from the primary key server and imported on other key servers manually.

Time-Based Anti-Replay

Anti-replay is an important feature in a data encryption protocol such as IPSec (RFC 2401). Anti-replay prevents a third party from eavesdropping on an IPsec conversation, stealing packets, and injecting those packets into a session at a later time. The time-based anti-replay mechanism helps ensure that invalid packets are discarded by detecting the replayed packets that have already arrived at an earlier time.

GET VPN uses the Synchronous Anti-Replay (SAR) mechanism to provide anti-replay protection for multisender traffic. SAR is independent of real-world Network Time Protocol (NTP) clock or sequential-counter mechanisms (which guarantee packets are received and processed in order). A SAR clock advances regularly. The time tracked by this clock is called pseudotime. The pseudotime is maintained on the key server and is sent periodically to the group members within a rekey message as a timestamp field called pseudoTimeStamp. GET VPN uses a Cisco proprietary protocol called Metadata to encapsulate the psuedoTimeStamp. Group members have to be resynchronized to the pseudotime of the key server periodically. The pseudotime of the key server starts ticking from when the first group member registers. Initially, the key server sends the current pseudotime value of the key server and


OL-19983-01


window size to group members during the registration process. New attributes, such as time-based replay-enabled information, window size, and the pseudotime of the keyserver, is sent under the SA payload (TEK).

The group members use the pseudotime to prevent replay as follows: the pseudoTimeStamp contains the pseudotime value at which a sender created a packet. A receiver compares the pseudotime value of senders with its own pseudotime value to determine whether a packet is a replayed packet. The receiver uses a time-based anti-replay "window" to accept packets that contain a timestamp value within that window. The window size is configured on the key server and is sent to all group members.

The Figure 9-7 illustrates an anti-replay window in which the value PTr denotes the local pseudotime of the receiver, and W is the window size.

Figure 9-7 Anti-Replay Window

Configuring GET VPNTo configure a full mesh VPN with group encrypted transport (GET), use the Create VPN wizard. For details, see Using the Create VPN Wizard, page 9-14.

If you are using the rekeying mechanism (see Rekey Mechanism, page 9-87) and multicast, make sure that the routers used as key servers are multicast enabled.

You can change only the name and description of a GET VPN using the Edit VPN wizard. If you need to make changes to other policies and settings, open the policies from the Site-to-Site Manager page, as follows:

• For ISAKMP and IPSec settings, select Global Settings for GET VPN. See Global Settings for GET VPN Page, page G-72.

• For IKE proposal policies, select IKE Proposal Policy for GET VPN. See IKE Proposal Page for GET VPN, page G-54.

• For security (ACL) and IPSec policies, select Group Encryption Policy > Security Associations. See Group Encryption Policy Page, page G-50.

• For preshared key policies, select Preshared Key. See Preshared Key Page, page G-59.

• For public key (PKI) policies, select Public Key Infrustructure. See Public Key Infrastructure Page, page G-62.

• For rekey settings, select Group Encryption Policy > Group Settings. See Group Encryption Policy Page, page G-50.

Related Topics

• Understanding Group Encrypted Transport (GET) VPNs, page 9-82

• Create VPN Wizard, page G-2

Reject

Initialpseudotime

PTr - W PTr

Anti-replay window

PTr + W

Accept Reject

2300

78


OL-19983-01

Documents

Managing Site-to-Site VPNs€¦ · DMVPN and Easy VPN technologies can only be applied in a hub-and-spoke topology. For more information, see Understanding IPsec Technologies and