User Guide for Cisco Security Manager 4.0.1
Configuring Common Site-to-Site VPN Policies
Downloads: This chapterpdf (PDF - 363.0KB) The complete bookPDF (PDF - 24.15MB) | Feedback

Configuring Common Site-to-Site VPN Policies

Table Of Contents

Configuring Common Site-to-Site VPN Policies

Understanding IKE

Deciding Which Encryption Algorithm to Use

Deciding Which Hash Algorithm to Use

Deciding Which Diffie-Hellman Group to Use

Deciding Which Authentication Method to Use

Configuring an IKE Proposal

IKE Proposal Page

Understanding IPsec Tunnel Policies

About Crypto Maps

About Transform Sets

About Reverse Route Injection

Configuring IPsec Proposals

IPsec Proposal Page

Understanding VPN Global Settings

Understanding ISAKMP/IPsec Settings

Understanding NAT

Understanding Fragmentation

Configuring VPN Global Settings

VPN Global Settings Page

ISAKMP/IPsec Settings Tab

NAT Settings Tab

General Settings Tab

Understanding Preshared Key Policies

Configuring Preshared Key Policies

Preshared Key Page

Understanding Public Key Infrastructure Policies

Prerequisites for Successful PKI Enrollment

Defining Multiple CA Servers for Site-to-Site VPNs

Configuring Public Key Infrastructure Policies

Public Key Infrastructure Page


Configuring Common Site-to-Site VPN Policies


Some site-to-site VPN policies are used in many different VPN technologies, and even in remote-access VPN configurations. The following topics explain these common policies and how to configure them.

Understanding IKE

Understanding IPsec Tunnel Policies

Understanding VPN Global Settings

Understanding Preshared Key Policies

Understanding Public Key Infrastructure Policies

Understanding IKE

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

Which hash algorithm to use for integrity checking. See Deciding Which Hash Algorithm to Use.

Which Diffie-Hellman group to use to operate the encryption algorithm. See Deciding Which Diffie-Hellman Group to Use.

Which device authentication method to use. See Deciding Which Authentication Method to Use.

For how long the IKE SA will be valid.

Related Topics

Configuring an IKE Proposal

IKE Proposal Page

Deciding Which Encryption Algorithm to Use

When deciding which encryption and hash algorithms to use for the IKE proposal, your choice is limited to algorithms that are supported by the devices in the VPN.

You can choose from the following encryption algorithms:

DES (Data Encryption Standard) is a symmetric secret-key block algorithm. It is faster than 3DES and uses less system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, you should choose DES.

3DES (Triple DES) is more secure because it processes each block of data three times, each time with a different key. However, it uses more system resources and is slower than DES. 3DES is the recommended encryption algorithm, assuming that the devices support it.

AES (Advanced Encryption Standard) provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192- and 256-bit keys. A longer key provides higher security but a reduction in performance. AES is supported only on routers running IOS version 12.3T and later.


Note AES cannot be used in conjunction with a hardware encryption card.


Related Topics

Understanding IKE

Configuring an IKE Proposal

Deciding Which Hash Algorithm to Use

You can choose from the following hash algorithms:

SHA produces a 160-bit digest, and is more resistant to brute-force attacks than MD5. However, it is also more resource intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.

MD5 produces a 128-bit digest, and uses less processing time for an overall faster performance than SHA, but it is considered to be weaker than SHA.

Related Topics

Understanding IKE

Configuring an IKE Proposal

Deciding Which Diffie-Hellman Group to Use

Security Manager supports Diffie-Hellman group 1, group 2, group 5, and group 7 key derivation algorithms to generate IPsec SA keys. Each group has a different size modulus. A larger modulus provides higher security, but requires more processing time. You must have a matching modulus group on both peers.

Diffie-Hellman Group 1: 768-bit modulus. Use to generate IPsec SA keys, where the prime and generator numbers are 768 bits.

Diffie-Hellman Group 2: 1024-bit modulus. Use to generate IPsec SA keys, where the prime and generator numbers are 1024 bits.

Diffie-Hellman Group 5: 1536-bit modulus. Use to generate IPsec SA keys, where the prime and generator numbers are 2048 bits. 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.

Diffie-Hellman Group 15: 3072-bit modulus, considered good protection for 192-bit keys.

Diffie-Hellman Group 16: 4096-bit modulus, considered good protection for 256-bit keys.

Related Topics

Understanding IKE

Configuring an IKE Proposal

Deciding Which Authentication Method to Use

Security Manager supports two methods for peer device authentication in a VPN communication:

Preshared Key—Preshared keys allow for a secret key to be shared between two peers and used by IKE during the authentication phase. The same shared key must be configured at each peer or the IKE SA cannot be established.

To use IKE successfully with this device authentication method, you must define various preshared key parameters. For more information, see Understanding Preshared Key Policies.

RSA Signature—An authentication method in which RSA key pairs are used to sign and encrypt IKE key management messages. RSA Signature provides non-repudiation of communication between two peers, meaning that it can be proved that the communication actually took place. When using this authentication method, peers are configured to obtain digital certificates from a Certification Authority (CA). CAs manage certificate requests and issue certificates to participating IPsec network devices. These services provide centralized key management for the participating devices.

While the use of preshared keys does not scale well, using a CA does improve the manageability and scalability of your IPsec network. With a CA, you do not need to configure keys between all encrypting devices. Instead, each participating device is registered with the CA, and requests a certificate from the CA. Each device that has its own certificate and the public key of the CA can authenticate every other device within a given CA's domain.

To use IKE successfully with the RSA Signature device authentication method, you must define parameters for CA authentication and enrollment. For more information, see Understanding Public Key Infrastructure Policies.

Related Topics

Understanding IKE

Configuring an IKE Proposal

Configuring an IKE Proposal

In Security Manager, an IKE proposal is a mandatory policy, with predefined security parameters, that is automatically assigned to a VPN topology. On the IKE Proposal page, you can view the parameters of the selected IKE proposal, select a different one from a list of predefined IKE proposals, or create one.


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


This procedure describes how to view the parameters of the selected IKE proposal, select a different one from a list of predefined IKE proposals, or create one.

Related Topics

Understanding IKE

Understanding Preshared Key Policies


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

Step 2 In the VPNs selector, select the 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 IKE Proposal Page.

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 28-26.


IKE Proposal Page

Use the IKE Proposal page to select the IKE proposal that will be used to secure the IKE negotiation between two peers. An IKE proposal is a mandatory policy that is already configured in your VPN topology with predefined default values. On the IKE Proposal page, you can view the parameters of the selected IKE proposal, select a different one from a list of predefined IKE proposals, or create a new one.

Navigation Path

(Site-to-Site VPN Manager Window, page 21-17) Select a topology in the VPNs selector, then select IKE Proposal in the Policies selector.

(Policy view) Select Site-to-Site VPN > IKE Proposal from the Policy Types selector. Select an existing shared policy or create a new one.

Related Topics

Understanding IKE

Configuring an IKE Proposal

Understanding Preshared Key Policies

Preshared Key Page

Configuring VPN Topologies in Device View, page 21-18

Field Reference

Table 22-1 IKE Proposal Page 

Element
Description

Available IKE Proposals

Lists the predefined IKE proposals available for selection.

Select the required IKE proposal in the list. The IKE proposal replaces the one in the Selected IKE Proposal field.

IKE proposals are predefined objects. If the required IKE proposal is not included in the list, click Add to open the IKE Editor dialog box that enables you to create or edit an IKE proposal object. For more information, see Add or Edit IKE Proposal Dialog Box, page 28-26.

Selected

The selected IKE proposal with its predefined default values. The default is preshared_sha_3des_dh5_5.

Note You cannot edit the selected IKE proposal because it is a predefined object. You can only edit the properties of an IKE proposal object you create.

To remove the IKE proposal from this field, select a different one.

Create button

Opens the IKE Editor dialog box for creating an IKE proposal object. For more information, see Add or Edit IKE Proposal Dialog Box, page 28-26.

Edit button

Opens the IKE Editor dialog box for editing the selected IKE proposal. For more information, see Add or Edit IKE Proposal Dialog Box, page 28-26.


Understanding IPsec Tunnel Policies

IPsec is one of the most secure methods for setting up a VPN. IPsec provides data encryption at the IP packet level, offering a robust security solution that is standards-based. Pure IPsec configurations cannot use routing protocols—the policy created is used for pure IPsec provisioning. You can configure pure IPsec on Cisco IOS routers, PIX Firewalls, Catalyst VPN Service Modules, and Adaptive Security Appliance (ASA) devices.

With IPsec, data is transmitted over a public network through tunnels. A tunnel is a secure, logical communication path between two peers. Traffic that enters an IPsec tunnel is secured by a combination of security protocols and algorithms, called a transform set.

In Security Manager, you configure IPsec proposals on devices in your VPN topology. An IPsec proposal is a collection of one or more crypto maps that are applied to the VPN interfaces on the devices. 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

About Transform Sets

About Reverse Route Injection

Related Topics

Configuring IPsec Proposals

About Crypto Maps

A crypto map combines all components required to set up IPsec security associations, including IPsec rules, transform sets, remote peer(s), and other parameters that might be necessary to define an IPsec SA. A crypto map entry is a named series of CLI commands. Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set, which is applied to the VPN interfaces on relevant devices. All IP traffic passing through the interface is evaluated against the applied crypto map set.

When two peers try to establish an SA, they must each have at least one compatible crypto map entry. The transform set defined in the crypto map entry is used in the IPsec security negotiation to protect the data flows specified by that crypto map's IPsec rules.

Dynamic crypto map policies are used when an unknown remote peer tries to initiate an IPsec security association with the local hub. The hub cannot be the initiator of the security association negotiation. Dynamic crypto policies allow remote peers to exchange IPsec traffic with a local hub, even if the hub does not know the remote peer's identity. You can create a dynamic crypto policy on individual hubs or on a device group that contains hubs. The policy is written only to the hubs, not to any spokes that might be contained in the group. A dynamic crypto map policy essentially creates a crypto map entry without all the parameters configured. The missing parameters are later dynamically configured (as the result of an IPsec negotiation) to match a remote peer's requirements. The peer addresses for dynamic or static crypto maps are deduced from the VPN topology.

Dynamic crypto map policies apply only in a hub-and-spoke VPN configuration—in a point-to-point or full mesh VPN topology, you can apply only static crypto map policies.


Note Security Manager can manage an existing VPN tunnel, only if the tunnel's peers are managed by Security Manager. In such a case, Security Manager uses the same crypto map name for the tunnel on the peers. On subsequent deployments, only Security Manager tunnels are managed (Security Manager maintains a log of all tunnels that were configured).


Related Topics

Understanding IPsec Tunnel Policies

About Transform Sets

Configuring IPsec Proposals

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.

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 Add or Edit IPSec Transform Set Dialog Box, page 28-28.

Related Topics

Understanding IPsec Tunnel Policies

About Crypto Maps

Configuring IPsec Proposals

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 also 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 26-39.


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 (available for IOS devices only) 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 (available for IOS devices only), 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

Understanding IPsec Tunnel Policies

About Crypto Maps

Configuring IPsec Proposals

Configuring an IPsec Proposal on a Remote Access VPN Server, page 26-39

Configuring IPsec Proposals

In Security Manager, an IPsec proposal is a policy that you can assign to a VPN topology. In the Site-to-Site VPN Manager window, you can view the predefined IPsec proposal that you can assign to a selected VPN topology. From this page, you can edit the IPsec proposal, if required.

This procedure describes how to edit the parameters of an IPsec proposal.

Related Topics

Understanding IPsec Tunnel Policies

About Reverse Route Injection

IPsec Proposal Page


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

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

Step 3 Select IPsec Proposal in the Policies selector.

The IPsec Proposal page appears, displaying the defined parameters for the selected IPsec proposal. For a description of the elements on this page, see Table 22-2.

Step 4 Click the Static or Dynamic radio button, depending on the crypto map type.

Step 5 Select the required transform sets 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).


IPsec Proposal Page

Use the IPsec Proposal page to edit the IPsec policy definitions for your VPN topology.


Note When configuring IPsec policy definitions on an Easy VPN server, the IPsec Proposal page contains different elements. See Easy VPN IPsec Proposal Page, page 24-6.


Navigation Path

(Site-to-Site VPN Manager Window, page 21-17) Select a topology in the VPNs selector, then select IPsec Proposal in the Policies selector.

(Policy view) Select Site-to-Site VPN > IPsec Proposal from the Policy Types selector. Select an existing shared policy or create a new one.

Related Topics

Understanding IPsec Tunnel Policies

Configuring IPsec Proposals

Field Reference

Table 22-2 IPsec Proposal Page 

Element
Description

Crypto Map Type

A crypto map combines all the components required to set up IPsec security associations. When two peers try to establish an SA, they must each have at least one compatible crypto map entry.

Select the type of crypto map you want to generate:

Static—Use a static crypto map in a point-to-point or full mesh VPN topology.

Dynamic—Dynamic crypto maps can only be used in a hub-and-spoke VPN topology. Dynamic crypto map policies allow remote peers to exchange IPsec traffic with a local hub, even if the hub does not know the remote peer's identity.

For more information, see About Crypto Maps.

Transform Sets

The transform sets to use for your tunnel policy. Transform sets specify which authentication and encryption algorithms will be used to secure the traffic in the tunnel. You can select up to six transform sets.

Note Transform sets may use tunnel mode or transport mode of IPsec operation. When IPsec or Easy VPN is the assigned technology, you cannot use transport mode.

A default transform set is displayed (tunnel_3des_sha). If you want to use a different transform set, or select additional transform sets, click Select to open a dialog box that lists all available transform sets, and in which you can create transform set objects. For more information, see Add or Edit IPSec Transform Set Dialog Box, page 28-28.

If more than one of your selected transform sets is supported by both peers, the transform set that provides the highest security will be used.

For more information, see About Transform Sets.

Enable Perfect Forward Secrecy

When selected, enables the use of Perfect Forward Secrecy (PFS) to generate and use a unique session key for each encrypted exchange.

The unique session key protects the exchange from subsequent decryption, even if the entire exchange was recorded and the attacker has obtained the preshared and/or private keys used by the endpoint devices.

Note To enable PFS, you must also select a Diffie-Hellman group for generating the PFS session key.

Modulus Group

Available if Enable Perfect Forward Secrecy is selected.

Select the required Diffie-Hellman key derivation algorithm from the Modulus Group list box.

Security Manager supports Diffie-Hellman group 1, group 2, group 5, and group 7 key derivation algorithms. Each group has a different size modulus:

Group 1 (the default): 768-bit modulus.

Group 2: 1024-bit modulus.

Group 5: 1536-bit modulus.

Group 7: Use when the elliptical curve field size is 163 characters.

For more information, see Deciding Which Diffie-Hellman Group to Use.

Lifetime (sec)

The number of seconds an SA will exist before expiring. The default is 3600 seconds (one hour).

Lifetime refers to the global lifetime settings for the crypto IPsec security association (SA). The IPsec lifetime can be specified in seconds, in kilobytes, or both.

Lifetime (kbytes)

The volume of traffic (in kilobytes) that can pass between IPsec peers using a given SA before it expires.

Valid values depend on the device type. Enter a value within the range 10-2147483647 for an IOS router, and 2560-536870912 for a PIX7.0/ASA device.

The default value is 4,608,000 kilobytes.

QoS Preclassify

Supported on Cisco IOS routers, except 7600 devices.

When selected, enables the classification of packets before tunneling and encryption occur.

The Quality of Service (QoS) for VPNs feature enables Cisco IOS QoS services to operate with tunneling and encryption on an interface.

The QoS features on the output interface classify packets and apply the appropriate QoS service before the data is encrypted and tunneled, enabling traffic flows to be adjusted in congested environments, and resulting in more effective packet tunneling.

Reverse Route

Supported on ASA devices, PIX 7.0+ devices, and Cisco IOS routers except 7600 devices.

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. For more information, see About Reverse Route Injection.

Select one of the following options to configure RRI on the crypto map:

None—Disables the configuration of RRI on the crypto map.

Standard—(ASA, PIX 7.0+, IOS devices) Creates routes based on the destination information defined in the crypto map access control list (ACL). This is the default option.

Remote Peer—(IOS devices only) Creates two routes, one for the remote endpoint and one for route recursion to the remote endpoint via the interface to which the crypto map is applied.

Remote Peer IP—(IOS devices only) Specifies an address as the explicit next hop to the remote VPN device. Enter the IP address or a network/host object that specifies the address, or click Select to select the network/host object from a list or to create a new object.

Note If you use network/host objects, you can select the Allow Value Override per Device check box to override the IP address, if required, for specific devices that use this object.


Understanding VPN Global Settings

In Security Manager, you can define VPN global settings that apply to all devices in your VPN topology. These settings include Internet Key Exchange (IKE), IPsec, NAT, and fragmentation definitions.

The following topics describe these global VPN settings:

Understanding ISAKMP/IPsec Settings

Understanding NAT

Understanding Fragmentation

Related Topics

Configuring VPN Global Settings

Understanding ISAKMP/IPsec Settings

The Internet Key Exchange (IKE) protocol, also called the Internet Security Association and Key Management Protocol (ISAKMP) is the negotiation protocol that lets two hosts agree on how to build an IPsec security association. Each ISAKMP negotiation is divided into a Phase 1 and Phase 2. Phase 1 creates the first tunnel, 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.

About IKE Keepalive

With IKE keepalive, tunnel peers exchange messages that demonstrate they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals, and any disruption in that interval results in the creation of a new tunnel, using a backup device.

Devices that rely on IKE keepalive for resiliency transmit their keepalive messages regardless of whether they are exchanging other information. These keepalive messages can therefore create a small but additional demand on your network.

A variation on IKE keepalive called keepalive dead-peer detection (DPD) sends keepalive messages between peer devices only when no incoming traffic is received and outbound traffic needs to be sent. If you want to send DPD keepalive messages when no incoming traffic is received regardless of whether there is any outbound traffic, you can specify this using the Periodic option. See ISAKMP/IPsec Settings Tab.

Related Topics

Configuring VPN Global Settings

ISAKMP/IPsec Settings Tab

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 NAT Page: Dynamic Rules, page 20-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 20-11). 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 20-16).


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.

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 7, "Managing FlexConfigs").


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

Related Topics

Configuring VPN Global Settings

NAT Settings Tab

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

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 22-5.

Related Topics

Configuring VPN Global Settings

General Settings Tab

Configuring VPN Global Settings

On the VPN Global Settings page, you can define global settings for IKE, IPsec, NAT, and fragmentation, to apply to devices in your VPN topology. A VPN Global Settings policy applies to any IPsec technology assigned to your VPN topology.

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.


Related Topics

Understanding ISAKMP/IPsec Settings

Understanding NAT

Understanding Fragmentation


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

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

Step 3 Select VPN Global Settings in the Policies selector. The VPN Global Settings dialog box opens, displaying the ISAKMP/IPsec Settings tab.

Step 4 In the ISAKMP/IPsec Settings tab, specify global settings for IKE and IPsec. For a description of the elements on this tab, see ISAKMP/IPsec Settings Tab.

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 NAT Settings Tab.

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 General Settings Tab.


VPN Global Settings Page

Use the VPN Global Settings page to define global settings for IKE, IPsec, NAT, and fragmentation, that apply to devices in your VPN topology.

The following tabs are available on the VPN Global Settings page:

ISAKMP/IPsec Settings Tab

NAT Settings Tab

General Settings Tab

Navigation Path

Open the Site-to-Site VPN Manager Window, page 21-17, select a topology in the VPNs selector, then select VPN Global Settings in the Policies selector.

(Policy view) Select Site-to-Site VPN > VPN Global Settings from the Policy Types selector. Select an existing shared policy or create a new one.

ISAKMP/IPsec Settings Tab

Use the ISAKMP/IPsec Settings tab of the VPN Global Settings page to specify global settings for Internet Key Exchange (IKE) and IPsec.

Internet Key Exchange (IKE), also called 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.

Navigation Path

The ISAKMP/IPsec Settings tab appears when you open the VPN Global Settings Page. You can also open it by clicking the ISAKMP/IPsec Settings tab from any other tab in the VPN Global Settings page.

Related Topics

VPN Global Settings Page

Understanding IKE

Understanding IPsec Tunnel Policies

Understanding ISAKMP/IPsec Settings

Configuring VPN Global Settings

Field Reference

Table 22-3 VPN Global Settings Page > ISAKMP/IPsec Settings Tab 

Element
Description

ISAKMP Settings

Enable Keepalive

When selected, enables you to configure IKE keepalive as the default failover and routing mechanism.

IKE keepalive is defined on the spokes in a hub-and-spoke VPN topology, or on both devices in a point-to-point VPN topology.

Interval

The number of seconds that a device waits between sending IKE keepalive packets. The default is 10 seconds.

Retry

The number of seconds a device waits between attempts to establish an IKE connection with the remote peer. The default is 2 seconds.

Periodic

Available only if Enable Keepalive is selected, and supported on routers running IOS version 12.3(7)T and later, except 7600 devices.

When selected, enables you to send dead-peer detection (DPD) keepalive messages even if there is no outbound traffic to be sent. Usually, DPD keepalive messages are sent between peer devices only when no incoming traffic is received but outbound traffic needs to be sent.

For more information, see Understanding ISAKMP/IPsec Settings.

Identity

During Phase I IKE negotiations, peers must identify themselves to each other.

When selected, enables you to use the (IP) address or the hostname of the device that it will use to identify itself in IKE negotiations. You can also select to use a Distinguished Name (DN) to identify a user group name. The default is Address.

SA Requests System Limit

Supported on routers running IOS version 12.3(8)T and later, except 7600 routers.

The maximum number of SA requests allowed before IKE starts rejecting them. The specified value must equal or exceed the number of peers, or the VPN tunnels may be disconnected.

You can enter a value in the range of 0-99999.

SA Requests System Threshold

Supported on Cisco IOS routers and Catalyst 6500 /7600 devices.

The percentage of system resources that can be used before IKE starts rejecting new SA requests. The default is 75 percent.

Enable Aggressive Mode

Supported on ASA devices and PIX 7.0 devices.

When selected, enables you to use aggressive mode in ISAKMP negotiations, for an ASA device. Aggressive mode is enabled by default.

Deselect this check box to disable the use of aggressive mode in ISAKMP negotiations, for an ASA device.

See Understanding IKE.

IPsec Settings

Enable Lifetime

When selected, enables you to configure the global lifetime settings for the crypto IPsec security associations (SAs) on the devices in your VPN topology.

Lifetime (secs)

The number of seconds a security association will exist before expiring. The default is 3,600 seconds (one hour).

Lifetime (kbytes)

The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association before it expires. The default is 4,608,000 kilobytes.

Xauth Timeout

Available when Easy VPN is the selected technology, and the selected device is a Cisco IOS router or Catalyst 6500 /7600 device.

The number of seconds the device waits for a response from the end user after an IKE SA has been established.

When negotiating tunnel parameters for establishing IPsec tunnels in an Easy VPN configuration, Xauth adds another level of authentication that identifies the user who requests the IPsec connection. Using the Xauth feature, 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.

Max Sessions

Supported on ASA devices and PIX 7.0 devices.

The maximum number of SAs that can be enabled simultaneously on the device.

Enable IPsec via Sysopt

Supported on ASA devices and PIX Firewalls versions 6.3 or 7.0.

When selected (the default), specifies that any packet that comes from an IPsec tunnel is implicitly trusted (permitted).

Enable SPI Recovery

Supported on routers running IOS version 12.3(2)T and later, in addition to Catalyst 6500/7600 devices running version 12.2(18)SXE and later.

When selected, enables the SPI recovery feature to configure your device so that if an invalid SPI (Security Parameter Index) occurs, an IKE SA will be initiated.

SPI (Security Parameter Index) is a number which, together with a destination IP address and security protocol, uniquely identifies a particular security association. When using IKE to establish security associations, the SPI for each security association is a pseudo-randomly derived number. Without IKE, the SPI is manually specified for each security association. When an invalid SPI occurs during IPsec packet processing, the SPI recovery feature enables an IKE SA to be established.


NAT Settings Tab

Use the NAT Settings tab of the VPN Global Settings page to define the NAT settings that will be configured on the devices in your VPN topology.


Note If you want to bypass NAT configuration on IOS routers, make sure the Do Not Translate VPN Traffic check box is selected in the NAT Dynamic Rule platform policy (see NAT Dynamic Rule Dialog Box, page 20-11). 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 20-16).


Navigation Path

Open the VPN Global Settings Page, then click the NAT Settings tab.

Related Topics

Understanding NAT

VPN Global Settings Page

Field Reference

Table 22-4 VPN Global Settings Page > NAT Settings Tab 

Element
Description

Enable Traversal Keepalive

When selected, enables you to configure NAT traversal keepalive on a device.

NAT traversal keepalive 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.

Note On Cisco IOS routers, NAT traversal is enabled by default. If you want to disable the NAT traversal feature, you must do this manually on the device or using a FlexConfig (see Chapter 7, "Managing FlexConfigs").

For more information, see Understanding NAT.

Interval

Available when NAT Traversal Keepalive is enabled.

The interval, in seconds, between the keepalive signals sent between the spoke and the middle device to indicate that the session is active. The NAT keepalive value can be from 5 to 3600 seconds. The default is 10 seconds.

Enable PAT (Port Address Translation) on Split Tunneling for Spokes

Supported on Cisco IOS routers and Catalyst 6500 /7600 devices.

When selected, enables Port Address Translation (PAT) to be used for split-tunneled traffic on spokes in your VPN topology.

PAT can associate thousands of private NAT addresses with a small group of public IP address, through the use of port addressing. PAT is used if the addressing requirements of your network exceed the available addresses in your dynamic NAT pool. See Understanding NAT.

Note When this check box is enabled, Security Manager implicitly creates an additional NAT rule 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.

For information on creating or editing a dynamic NAT rule as a router platform policy, see NAT Page: Dynamic Rules, page 20-10.


General Settings Tab

Use the General Settings tab of the VPN Global Settings page to define fragmentation settings including maximum transmission unit (MTU) handling parameters.

Navigation Path

Open the VPN Global Settings Page, then click the General Settings tab.

Related Topics

VPN Global Settings Page

Understanding Fragmentation

Field Reference

Table 22-5 VPN Global Settings Page > General Settings Tab 

Element
Description

Fragmentation Settings

Fragmentation Mode

Supported on Cisco IOS routers and Catalyst 6500 /7600 devices.

Fragmentation minimizes packet loss in a VPN tunnel when transmitted over a physical interface that cannot support the original size of the packet.

Select the required fragmentation mode option from the list:

No Fragmentation—Select if you do not want to fragment before IPsec encapsulation. After encapsulation, the device fragments packets that exceed the MTU setting before transmitting them through the public interface.

End to End MTU Discovery—Select to use ICMP messages for the discovery of MTU. Use this option when the selected technology is IPsec.

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.

Note For Catalyst 6500 /7600 devices, end-to-end path MTU discovery is supported only on images 12.2(33)SRA, 12.2(33)SRB, 12.2(33)SXH, 12.2(33)SXI or above.

Local MTU Handling—Select to set the MTU locally on the devices. This option is typically used when ICMP is blocked, and when the selected technology is IPsec/GRE.

Local MTU Size

Supported on Cisco IOS routers and Catalyst 6500 /7600 devices, when Local MTU Handling is the selected fragmentation mode option.

Note The permitted MTU size is between 68 and 65535 bytes depending on the VPN interface.

DF Bit

Supported on Cisco IOS routers, Catalyst 6500 /7600 devices, PIX 7.0 and ASA devices.

A Don't Fragment (DF) bit within an IP header determines whether a device is allowed to fragment a packet.

Select the required setting for the DF bit:

Copy—Copies the DF bit from the encapsulated header in the current packet to all the device's packets. If the packet's DF bit is set to fragment, all future packets are fragmented. This is the default option.

Set—Sets the DF bit in the packet you are sending. A large packet that exceeds the MTU is dropped and an ICMP message is sent to the packet's initiator.

Clear—Fragments packets regardless of the original DF bit setting. If ICMP is blocked, MTU discovery fails and packets are fragmented after encryption.

Enable Fragmentation Before Encryption

Supported on Cisco IOS routers, Catalyst 6500 /7600 devices, PIX 7.0 and ASA devices.

When selected, enables fragmentation to occur before encryption, if the expected packet size exceeds the MTU.

Lookahead Fragmentation (LAF) is used before encryption takes place to calculate the packet size that would result after encryption, depending on the transform sets configured on the IPsec SA. If the packet size exceeds the specified MTU, the packet will be fragmented before encryption.

Enable Notification on Disconnection

Supported on PIX 7.0 and ASA devices.

When selected, enables the device to notify qualified peers of sessions that are about to be disconnected. The peer receiving the alert decodes the reason and displays it in the event log or in a pop-up panel. This feature is disabled by default.

Enable Split Tunneling

When selected (the default), enables you to configure split tunneling in your VPN topology.

Split tunneling enables you to transmit both secured and unsecured traffic on the same interface. Split tunneling requires that you specify exactly which traffic will be secured and what the destination of that traffic is, so that only the specified traffic enters the IPsec tunnel, while the rest is transmitted unencrypted across the public network.

Enable Spoke-to-Spoke Connectivity through the Hub

Supported on PIX 7.0 and ASA devices.

When selected, enables direct communication between spokes in a hub-and-spoke VPN topology, in which the hub is an ASA/PIX 7.0 device.

Enable Default Route

Supported on Cisco IOS routers and Catalyst 6500 /7600 devices.

When selected, the device uses the configured external interface as the default outbound route for all incoming traffic.


Understanding Preshared Key Policies

If 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 in each communication session. Using automatically generated keys (the default method) is preferred, because security can be compromised if all connections in a VPN use the same preshared key.

There are three methods for negotiating key information and setting up IKE SAs:

Main mode address—Negotiation is based on IP address. Main mode provides the highest security because it has three two-way exchanges between the initiator and receiver. This is the default negotiation method.

This method has three options for creating keys:

You can create a key for each peer, based on the unique IP address of each peer, providing high security.

You can create a group preshared key on a hub in a hub-and-spoke VPN topology, to be used for communication with any device in a specified subnet. Each peer is identified by its subnet, even if the IP address of the device is unknown. In a point-to-point or full mesh VPN topology, a group preshared key is created on the peers.

You can create a wildcard key on a hub in a hub-and-spoke VPN topology, or on a group containing hubs, to be used for dynamic crypto where a spoke does not have a fixed IP address or belong to a specific subnet. All spokes connecting to the hub have the same preshared key, which could compromise security. In a point-to-point or full mesh VPN topology, a wildcard key is created on the peers.


Note If you are configuring DMVPN with direct spoke-to-spoke connectivity, you create a wildcard key on the spokes.


Main mode fully qualified domain name (FQDN)—Negotiation is based on DNS resolution, with no reliance on IP address. This option can only be used if the DNS resolution service is available for the host. It is useful when managing devices with dynamic IP addresses that have DNS resolution capabilities.

Aggressive mode—Negotiation is based on hostname (without DNS resolution) and domain name. Aggressive mode is less secure than main mode. However, it provides more security than using group preshared keys if the IP address of the VPN interface on the host is unknown, and the FQDN of the dynamic IP peer is not DNS resolvable. This negotiation method is recommended for use with a GRE Dynamic IP or DMVPN failover and routing policy.

Related Topics

Deciding Which Authentication Method to Use

Configuring Preshared Key Policies

Preshared Key Page

Configuring Preshared Key Policies

The following procedure describes how to edit the parameters of a preshared key policy defined for a VPN topology.

Related Topics

Understanding Preshared Key Policies


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

Step 2 In the VPNs selector, select the 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 Preshared Key Page.

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.


Preshared Key Page

Use the Preshared Key page to view or edit the parameters for a preshared key policy.


Note The preshared key policy does not apply to Easy VPN topologies.


Navigation Path

(Site-to-Site VPN Manager Window, page 21-17) Select a topology in the VPNs selector, then select Preshared Key in the Policies selector.

(Policy view) Select Site-to-Site VPN > Preshared Key from the Policy Types selector. Select an existing shared policy or create a new one.

Related Topics

Understanding Preshared Key Policies

Configuring Preshared Key Policies

Field Reference

Table 22-6 Preshared Key Page 

Element
Description
Key Specification

User Defined

When selected, enables you to use a manually defined preshared key.

Enter the required preshared key in the Key field, then enter it again in the Confirm field.

Auto Generated

When selected, allocates a random key to the participating peers. This ensures security because a different key is generated for every hub-spoke connection. Auto Generated is the default selection.

Note The key is allocated during the first deployment to the devices and is used in all subsequent deployments to the same devices, until you select the Regenerate Key (Only in Next Deployment) check box.

Key Length

The required length of the preshared key to be automatically generated (maximum 127 characters). The default is 24.

Same Key for All Tunnels

Unavailable in a point-to-point VPN topology.

When selected, enables you to use the same auto-generated key for all tunnels.

Note If you do not select this check box, different keys are used for the tunnels, except in cases, such as DMVPN configuration, when different multipoint GRE interfaces in the same network must use the same preshared key.

Regenerate Key (Only in Next Deployment)

Only available if Auto Generate is selected.

When selected, enables Security Manager to generate a new key for the next deployment to the devices. This is useful if it is possible that the secrecy of the keys might be compromised.

Note When you submit the job for deployment, this check box is cleared. It does not remain selected because the new key will only be generated for the upcoming deployment, and not for subsequent deployments (unless you select it again).

Negotiation Method

Main Mode Address

This is the default negotiation method.

Use this negotiation method for exchanging key information, if the IP address of the devices is known. Negotiation is based on IP address. Main mode provides the highest security because it has three two-way exchanges between the initiator and receiver. Main mode address is the default negotiation method.

Then click one of the following three radio buttons to define the negotiation address type:

Peer Address—Negotiation is based on the unique IP address of each peer. A key is created for each peer, providing high security. This is the default.

Subnet—Creates a group preshared key on a hub in a hub-and-spoke topology to use for communication with any device in a specified subnet, even if the IP address of the device is unknown. Each peer is identified by its subnet. After selecting this option, enter the subnet in the field provided.

In a point-to-point or full mesh VPN topology, a group preshared key is created on the peers.

(continued)

Main Mode Address (continued)

Wildcard—Creates a wildcard key on a hub or on a group of hubs in a hub-and-spoke topology to use when a spoke does not have a fixed IP address or belong to a specific subnet. In this case, all spokes connecting to the hub have the same preshared key, which could compromise security. Use this option if a spoke in your hub-and-spoke VPN topology has a dynamic IP address.

In a point-to-point or full mesh VPN topology, a wildcard key is created on the peers.

Note When configuring DMVPN with direct spoke-to-spoke connectivity, you create a wildcard key on the spokes.

Main Mode FQDN

Select this negotiation method for exchanging key information, if the IP address is not known and DNS resolution is available for the device(s). Negotiation is based on DNS resolution, with no reliance on IP address.

Aggressive Mode

Available only in a hub-and-spoke VPN topology.

Select this negotiation method for exchanging key information, if the IP address is not known and DNS resolution might not be available on the devices. Negotiation is based on hostname and domain name.

Note If direct spoke to spoke tunneling is enabled, you cannot use aggressive mode.


Understanding Public Key Infrastructure Policies

Security Manager supports IPsec configuration with Certification Authority (CA) servers that manage certificate requests and issue certificates to devices in your VPN topology. You can create a Public Key Infrastructure (PKI) policy to generate enrollment requests for CA certificates and RSA keys, and manage keys and certificates, providing centralized key management for the participating devices.

CA servers, also known as trustpoints, manage public CA certificate requests and issue certificates to participating IPsec network devices. When you use RSA Signature as the device authentication method for IKE and IPsec proposal policies, peers are configured to obtain digital certificates from a CA server. With a CA server, you do not have to configure keys between all the encrypting devices. Instead, you individually enroll each participating device with the CA server, which is explicitly trusted to validate identities and create a digital certificate for the device. When this has been accomplished, each participating peer can validate the identities of the other participating peers and establish encrypted sessions with the public keys contained in the certificates.

CAs can also revoke certificates for peers that no longer participate in an IPsec VPN topology. Revoked certificates are either managed by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation list (CRL) stored on an LDAP server, which each peer can check before accepting a certificate from another peer.

PKI enrollment can be set up in a hierarchical framework consisting of multiple CAs. At the top of the hierarchy is a root CA, which holds a self-signed certificate. The trust within the entire hierarchy is derived from the RSA key pair of the root CA. Subordinate CAs within the hierarchy can enroll with either the root CA or with another subordinate CA. Within a hierarchical PKI, all enrolled peers can validate each other's certificate if the peers share a trusted root CA certificate or a common subordinate CA.

Keep the following in mind:

PKI policies can be configured on Cisco IOS routers running version 12.3(7)T and later, PIX Firewalls, and Adaptive Security Appliance (ASA) devices.

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 7, "Managing FlexConfigs").

PKI policies can also be configured on devices in a IPSec 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 28-21 on page 28-34.


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 53-82.


Related Topics

Prerequisites for Successful PKI Enrollment

Configuring Public Key Infrastructure Policies

Defining Multiple CA Servers for Site-to-Site VPNs

Public Key Infrastructure Page

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 28-35.

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 28-39.

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 28-40.

To deploy PKI policies to files (not to live devices), the following prerequisites must be met:

Devices must have IOS 12.3(7)T or later (trustpoint PKI devices).

CA authentication certificates must be cut and pasted into the Security Manager user interface (so that CA authentication is not interactive and does not require communication with the live device).

If you are deploying to live devices, the PKI server must be online.

Security Manager supports the Microsoft, Verisign, and Entrust PKIs.

Security Manager supports Cisco IOS Certificate Servers. The Cisco IOS Certificate Server feature embeds a simple certificate server, with limited CA functionality, into the Cisco IOS software. An IOS Certificate Server can be configured as a FlexConfig policy. For more information, see Chapter 7, "Managing FlexConfigs".

To configure PKI with AAA authorization that uses the entire subject name on an IOS router, use the predefined FlexConfig object named IOS_PKI_WITH_AAA.

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

PKI Enrollment Dialog Box, page 28-33

Public Key Infrastructure Page

Configuring a User Group Policy for Easy VPN, page 24-10

Defining Multiple CA Servers for Site-to-Site VPNs

You can select only one CA server when defining a Public Key Infrastructure (PKI) policy on a site-to-site VPN. This creates a problem when the devices in the VPN enroll with different CA servers. For example, the spoke devices might enroll with a different CA server than the hub, or the spokes in one part of the VPN might enroll with a different CA server than the spokes in another part of the VPN.

To define a PKI policy, you select a PKI enrollment object that specifies the CA server to which the devices should enroll. Although by default the policy object refers globally to a single CA server, you can use device-level overrides to have the object refer to a different CA server on selected devices.

For example, if PKI enrollment object PKI_1 refers to a CA server named CA_1, you can create a device-level override for selected devices that has PKI_1 refer to a different CA server, for example, CA_2. Theoretically, you can use overrides to define a different CA server for each device in the VPN.

This procedure describes the basic steps for creating overrides for PKI enrollment objects.


Note You can also use device-level overrides when the CA servers are arranged in a PKI hierarchy beneath a common, trusted CA server. To do this, you must ensure that both the global definition of the object and the device-level override specify the trusted CA server in the Trusted CA Hierarchy tab of the PKI Enrollment dialog box. See PKI Enrollment Dialog Box—Trusted CA Hierarchy Tab, page 28-42.


Related Topics

Understanding Public Key Infrastructure Policies

Understanding Public Key Infrastructure Policies

Deciding Which Authentication Method to Use


Step 1 To create the PKI enrollment object, open the PKI Enrollment dialog box. You can access this dialog box in two ways:

From the Public Key Infrastructure policy—Click the Add button beneath the Selected field. See Configuring Public Key Infrastructure Policies.

From the Policy Object Manager (select Tools > Policy Object Manager)—Select PKI Enrollments from the Object Type selector, then click the New Object button.

Step 2 Define the global definition of the PKI enrollment object, including the CA server to which the object refers. Be sure to select Allow Value Override per Device. This option makes the object overridable on individual devices. See PKI Enrollment Dialog Box, page 28-33.

Base the global definition of the object on the CA server that is used by the most devices in the VPN. Doing this reduces the number of device-level overrides that are required.

Step 3 When you finish defining the PKI enrollment object, click OK. As a result:

If you accessed the dialog box via the PKI policy, the new object appears in the Selected field of the policy page.

If you accessed the dialog box using the Policy Object Manager, the new object appears in the work area of the Policy Object Manager window. A green check mark in the Overridable column indicates that device-level overrides can be created for this object. (The check mark does not indicate whether any overrides actually exist.)

Step 4 Create the device-level overrides for the PKI enrollment object. You can do this in one of two ways:

From Device Properties (with the device selected in Device view, select Tools > Device Properties)—This option is recommended when you want to create a device-level override for a single device. In the device properties, select Policy Object Overrides > PKI Enrollments, select the PKI enrollment object that you want to override, then click the Create Override button. You can then define the content of the override, including the CA server defined by the object.

For more information, see Creating or Editing Object Overrides for a Single Device, page 6-14.

From the Policy Object Manager—This option is recommended when you want to create a device-level override for multiple devices at the same time. Double-click the green check mark in the Overridable column, select the devices to which the override should apply, then define the content of the override, including the CA server defined by the object.

For more information, see Creating or Editing Object Overrides for Multiple Devices At A Time, page 6-15.


Configuring Public Key Infrastructure Policies

You can create a Public Key Infrastructure (PKI) policy to generate enrollment requests for CA certificates and RSA keys, and to manage keys and certificates. Certification Authority (CA) servers are used to manage these certificate requests and issue certificates to the participating devices in your VPN topology.

In Security Manager, CA servers are predefined as PKI enrollment objects that you can use in your PKI policies. A PKI enrollment object contains the server information and enrollment parameters that are required for creating enrollment requests for CA certificates.

For more information about Public Key Infrastructure policies, see Understanding Public Key Infrastructure Policies.

This procedure describes how to specify the CA server that will be used to create a Public Key Infrastructure (PKI) policy, in your VPN topology.


Note To save the RSA key pairs and the CA certificates permanently to flash memory on a PIX Firewall version 6.3 between reloads, you must configure the ca save all command. You can do this manually on the device or using a FlexConfig (see Chapter 7, "Managing FlexConfigs").


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.

Related Topics

Defining Multiple CA Servers for Site-to-Site VPNs

Deciding Which Authentication Method to Use


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

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

Step 3 Select Public Key Infrastructure in the Policies selector. The Public Key Infrastructure page opens, displaying the currently selected CA server. For a description of the elements on this page, see Public Key Infrastructure Page.

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 28-33.


Public Key Infrastructure Page

Use the Public Key Infrastructure page to select the CA server that will be used to create a Public Key Infrastructure (PKI) policy, for generating enrollment requests for CA certificates.


Note To save the RSA key pairs and the CA certificates permanently to flash memory on a PIX Firewall version 6.3 between reloads, you must configure the ca save all command. You can do this manually on the device or using a FlexConfig (see Chapter 7, "Managing FlexConfigs").


Navigation Path

(Site-to-Site VPN Manager Window, page 21-17) Select a topology in the VPNs selector, then select Public Key Infrastructure in the Policies selector.

(Policy view) Select Site-to-Site VPN > Public Key Infrastructure from the Policy Types selector. Select an existing shared policy or create a new one.

Related Topics

Understanding Public Key Infrastructure Policies

Configuring Public Key Infrastructure Policies

Field Reference

Table 22-7 Public Key Infrastructure (PKI) Page 

Element
Description

Available CA Servers

Lists the predefined CA servers available for selection.

CA servers are predefined PKI enrollment objects that contain server information and enrollment parameters that are required for creating enrollment requests for CA certificates.

Select the required CA server if you want to replace the default one in the Selected field.

If the required CA server is not included in the list, click Create to open a dialog box that enables you to create or edit a PKI enrollment object. For more information, see PKI Enrollment Dialog Box, page 28-33.

Note If you are making a PKI enrollment request on an Easy VPN 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 dialog box. 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 28-40.

Selected

The selected CA server.

To remove the selected CA server, select a different one.