|
|
Before Cisco Secure Policy Manager can manage a Policy Enforcement Point, you must configure a Policy Distribution Point to communicate with that Policy Enforcement Point. In addition, you must provide the administrative passwords and other connection information required to actually manage that Policy Enforcement Point. This chapter focuses on the constraints that you must consider when defining the settings that enable this administrative traffic to flow across your network.
The following sections describe the device-specific settings that you must configure before you can manage a Policy Enforcement Point, as well as those settings that enable the generation and distribution of audit event messages, in the form of syslog data streams.
Within the Cisco Secure Policy Manager system, the Policy Distribution Point plays a critical role. This component performs the following tasks:
These command sets can be published securely using secure protocols, such as PIX Secure Telnet, or the Policy Distribution Point can use an IPSec tunnel to publish the command sets securely to the Policy Enforcement Points that it controls.
Because each type of Policy Enforcement Point has its own control agent within the Policy Distribution Point component, a Policy Distribution Point can control more than one Policy Enforcement Point type and multiple Policy Enforcement Points of a specific type. For example, a single Policy Distribution Point can control three IOS Routers and four PIX Firewalls if configured to do so. However, in scenarios where a Policy Distribution Point controls more than one Policy Enforcement Point, it is critical to consider the placement of the primary server or secondary server on which the Policy Distribution Point resides in relation to the Policy Enforcement Points that you want it to control. In addition, some Policy Enforcement Points have restrictions with respect to which interface(s) in the device can be used to configure them. In such cases, considering the limitations of the Policy Enforcement Point can also help you determine the correct placement of Policy Distribution Points on your network.
Because the Policy Distribution Point component is installed on all Cisco Secure Policy Manager hosts, you can always alter the way that you want to configure your distributed security system. Just as you can enable or disable a Policy Monitor Point for use as a valid option in configuring your security system, you can also enable or disable a Policy Distribution Point. Cisco Secure Policy Manager uses the selection of a Policy Distribution Point to ensure that the communication between a selected Policy Distribution Point and the Policy Enforcement Points that it controls is permitted. The security policies and IPSec Tunnel Groups that enable these communications are automatically generated and maintained by Cisco Secure Policy Manager.
You can resolve many issues that can affect your ability to deploy network security policies to Policy Enforcement Points by carefully planning the placement of Policy Distribution Points within your network. The benefits of careful planning and placement include the following:
Because you can have more than one Policy Distribution Point on your network, you must consider the selection of a Policy Distribution Point on a per-Policy Enforcement Point basis. The best way to make this selection is to understand the scenarios that can be problematic with regard to command distribution and to understand the effects of device-specific changes that you want to make after the initial deployment.
The first thing to determine when selecting a Policy Distribution Point is the traffic flows for the communications that occur between the Policy Distribution Point and all the Policy Enforcement Points that it controls. Next, you must consider the other Policy Distribution Points on your network and their required traffic flows. It is imperative that these traffic flows do not cross.
When such traffic flows cross, they can only cross at a gateway object, which is referred to as a concentrating gateway object for the remainder of this discussion. If that concentrating gateway object is a managed gateway object, it identifies a possible point of failure in the publishing of command sets, because the policies managing that gateway object can be altered as well. Because concentrating gateway objects represent points along the path between one or more Policy Enforcement Points and a Policy Distribution Point, these concentrating gateway objects can potentially be updated before the farther Policy Enforcement Points are provided with command sets that reflect the changes on the concentrating gateway object. This case is most likely to occur if you have enabled automatic publishing of the command sets by selecting Automatic under Command Approval in the Options dialog box (available on the Tools menu) or in the Command panel of a specific Policy Enforcement Point.
Figure 6-1 presents a simple topology that identifies crossing traffic flows from a single Policy Distribution Point.
In this example, the HQ Router acts as a concentrating gateway object when the Policy Distribution Point attempts to publish the generated command sets to the routers on Site A or Site B. Therefore, the only way to ensure that the traffic flows to the Site A and Site B routers are not broken is to publish to those outermost managed gateway objects before you publish to the HQ Router.
You can also have crossing traffic flows in topological scenarios that have multiple Policy Distribution Points, as illustrated in Figure 6-2.
In this case, the traffic flows that you must protect against being terminated are the traffic flows between the primary servers and the secondary servers of Cisco Secure Policy Manager. This problem only arises in scenarios where you have a distributed installation type for Cisco Secure Policy Manager.
A third, and unsupported, traffic flow crossing also involves a distributed installation scenario. In this case, two or more Policy Distribution Points publish to different Policy Enforcement Points, and one of the managed Policy Enforcement Points acts as the concentrating gateway object. Figure 6-3 illustrates this crossing traffic flow.
In such cases, Cisco Secure Policy Manager does not support the intelligent synchronization of command distribution across such concentrating gateway objects. In this configuration, PDPa is oblivious to the needs of PDPb during the time that PDPb is publishing the generated command set for Gw2. As a result, PDPa could publish command sets that disrupt or disable the ability for PDPb to publish command sets to Gw2.
You can construct network topologies for which you should not use automatic command distribution. The problem lies in the order that command sets are downloaded to various Policy Enforcement Points. The problem occurs when a Cisco Secure Policy Manager server attempts to publish command sets to an external Policy Enforcement Point from behind an internal Policy Enforcement Point that translates the server's real address. In some cases, the automatically downloaded command sets can fail and prevent the download of generated command sets to some Policy Enforcement Points in the topology.
Figure 6-4 assumes that you have a network topology in which you have defined three Cisco Secure PIX Firewalls (called Outside Gw, Middle Gw, and Inside Gw in this example) and that the Cisco Secure Policy Manager host (PDP) that distributes command sets to each of these Policy Enforcement Points resides upstream from Inside Gw. Now assume that you have defined a mapping rule on either Middle Gw or Inside Gw that performs a one-to-one static translation for the addresses of PDP.
Firewall Distribution Ordering Restriction Example
![]() |
Warning You cannot define address hiding rules that hide Cisco Secure Policy Manager hosts from the Policy Enforcement Points that they are expected to manage. Defining such rules guarantees that the device-specific command sets cannot be published to the managed gateway objects for which Cisco Secure Policy Manager is responsible. |
In this case, if you distribute the commands to Inside Gw or Middle Gw before you distribute them to Outside Gw, Outside Gw becomes unreachable by PDP. Even though the command set generated for Outside Gw understands the static translation rule, the command set to be replaced does not. Therefore, Outside Gw does not know to allow administrative updates from the translated PDP address.
![]() |
Note The automatic command distribution to Outside Gw fails only when a change to the mapping rules occurs on Inside Gw or Middle Gw. In other words, it can occur when you add, delete, or modify an existing mapping rule for the Cisco Secure Policy Manager host, PDP. Once you use the manual distribution method to change the mapping rules, you can return to the automatic distribution method until a similar change occurs. |
In this example, if the address of the PDP is not translated on any Policy Enforcement Points or it is translated only on Outside Gw, automatic updates would work fine, because in that case order does not matter.
You can enable or disable a Policy Distribution Point that resides on a primary or secondary server. If you enable a previously disabled Policy Distribution Point, you can use it to generate and publish device-specific command sets to the Policy Enforcement Points on your network. However, if you disable a Policy Distribution Point, you can no longer use it to generate and publish device-specific command sets to any Policy Enforcement Points on your network. In fact, a disabled Policy Distribution Point is not a valid option for the Policy Distribution Point box in the Enforcement panel of the Policy Enforcement Points that are managed by Cisco Secure Policy Manager.
To enable or disable the Policy Distribution Point, perform the following task:
Step 2 To view the Policy Distribution panel, point to Properties, and then click Policy Distribution on the shortcut menu.
Result: The Policy Distribution panel appears in the View pane.

Step 3 To change the availability of the Policy Distribution Point running on this host, select or clear the Disabled box under General Settings.
When this box is selected, the Policy Distribution Point is disabled. When the box is cleared, the Policy Distribution Point can be used to generate and publish command sets to the Policy Enforcement Points residing on your network.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
The first setting that you can review is the network service used for communications between the Policy Enforcement Point and a Cisco Secure Policy Manager host that is acting as the Policy Distribution Point for this Policy Enforcement Point. By default, for a PIX Firewall, this network service is PIX Secure Telnet, defined as TCP port 1467. For an IOS Router, this network service is Telnet, defined as TCP port 23. Currently, you cannot reconfigure the port settings associated with these network services. In addition, these network services are the only network services that are valid for downloading network policies to the respective Policy Enforcement Point.
As part of this general setting, you can specify which IP address, and therefore which interface, should be used to accept communication requests from Cisco Secure Policy Manager hosts.
Next you must specify which Cisco Secure Policy Manager host is responsible for generating and publishing the command sets to the Policy Enforcement Point. In addition to specifying which host will publish the generated command sets to the Policy Enforcement Point, you can specify whether you want to encrypt all communications that occur between the Policy Enforcement Point and the host acting as its Policy Distribution Point. You can define an IPSec tunnel between the Policy Distribution Point and the Policy Enforcement Point, as well as specify the IPSec Tunnel Template you want to use when defining the IPSec Tunnel Group that supports this communication.
We also recommend that you never reuse an IPSec template that is used for the Policy Distribution Point-to-Policy Enforcement Point traffic. Instead, you should make copies of the template before you modify any settings. This recommendation exists because if you change any properties of this IPSec template, it would result in the generation of a modified IPSec bootstrap command set for any Policy Enforcement Points managed by the Policy Distribution Point for which you modified the template properties.
If you do modify the template used to manage a Policy Enforcement Point, all attempts to publish the generated command sets to the Policy Enforcement Points will fail and the following warning message will appear for each affected Policy Enforcement Point in the System Inconsistencies panel when you perform a Save and Update operation:
To resolve this warning message, you must manually update the IPSec bootstrap settings for each affected Policy Enforcement Point (using a non-Cisco Secure Policy Manager administrative interface). After these settings are updated for each affected Policy Enforcement Point, these warning messages will be resolved when the command sets are published to each managed Policy Enforcement Point.
If you accidentally modify this IPSec template, you can perform a Reset operation. You will still receive the warning message identified above; however, this message will be resolved when you publish the generated command set to the affected Policy Enforcement Point, because the IPSec bootstrap settings have already been defined to resolve this issue.
As a general rule, any modifications to either tunnel peer affects the IPSec bootstrap settings, and, therefore, requires that you manually update the IPSec bootstrap settings for the Policy Enforcement Point acting as a peer in the generated IPSec Tunnel Group definition under the Cisco Systems Folder of the IPSec Tunnel Groups branch. Examples of such changes include the following:
![]() |
Caution If you modify the IP address that Cisco Secure Policy Manager uses to publish the commands to a Policy Enforcement Point (the address in the Enforcement panel), you must define an intermediate security policy that allows the network service selected in the Enforcement panel to enable both the old and the new IP addresses. Otherwise, the connection to the Policy Enforcement Point is broken while the Policy Distribution Point is publishing the command set that changes from the old address to the new address. |
![]() |
Caution If you define a static translation rule for a Policy Distribution Point, you can cause a temporary command set publishing problem. The problem results because the connection to the Policy Enforcement Point is broken once the new command set is published to the Policy Enforcement Point because it effectively changes the address of the Cisco Secure Policy Manager host by which the current command set is being published. |
In this case, you have two possible solutions to resolve this temporary problem:
1. Define a temporary policy that allows the administrative network service from the old Policy Distribution Point address to the administrative network interface in the Policy Enforcement Points that use that Policy Distribution Point. You only need to define the policy to allow the old IP address because the policy that allows the new IP address is automatically generated and applied in the Cisco System Folder. After you publish the command sets, remove the temporary policy and regenerate/publish the command sets.
2. Another approach is to use the Prologue option in the Command panel for the affected Policy Enforcement Points to specify that you want to accept administrative connections manually from the old IP address. After you publish the command sets, you can remove the line and republish.
By default, all communications between the Policy Distribution Point and a PIX Firewall are encrypted using the PIX Secure Telnet network service. However, you can use an IPSec tunnel to encrypt all communications between a Policy Distribution Point and any Policy Enforcement Point, assuming that the Policy Enforcement Point supports IPSec tunnels and that the Cisco Secure Policy Manager host acting as the Policy Distribution Point has the Cisco Secure VPN Client software installed and operational. However, if you chose to enable IPSec tunnels for these communications, all administrative clients that you use to connect to the Policy Enforcement Point must also support IPSec. In addition, you will have to define an IPSec Tunnel Group for those communications and define security policies that permit IPSec-based communications between each administrative client and the Policy Enforcement Point.
The Policy Enforcement Point panel also enables you to specify those passwords that are required to administer the Policy Enforcement Point. For each PIX Firewall, you must specify the enable password. For an IOS Router, you must specify both the Telnet and enable passwords. The Policy Distribution Point uses these passwords to authenticate to the Policy Enforcement Points before it downloads the derived network policies.
![]() |
Note You cannot change these passwords in the Enforcement panel. Instead, you must use the Pending Commands option in the Command panel to change these passwords. |
While each Policy Enforcement Point has only a single Policy Distribution Point, you can specify that you want one or more remote hosts to receive the syslog data streams generated by the Policy Enforcement Point. These hosts can either be a Cisco Secure Policy Manager host that is acting as a Policy Monitor Point or another host that runs a syslog server. You can select only one Policy Monitor Point, and as many syslog servers as you want.
![]() |
Note The current release of Cisco Secure Policy Manager does not automatically generate the security policies required to permit this syslog traffic to traverse Policy Enforcement Points. You must manually define and apply any security policies required to enable the traversal of such traffic across a Policy Enforcement Point. If the target syslog server resides on a network that is directly connected to an interface in the Policy Enforcement Points, Cisco Secure Policy Manager does generate the command set that is required to ensure that the syslog data streams are sent to that syslog server. |
![]() |
Tips If you chose to send the syslog data streams to a host that runs a third-party syslog server, you must also define that host in the Network Topology tree and add the Syslog client/server product type to that host. |
By studying and recording audit records based on syslog data streams, the Policy Monitor Point enables you to generate and view reports about network and device activity, as well as generate e-mail and pager-based notifications about specific activities. However, you are not required to specify that you want a Cisco Secure Policy Manager host to monitor these data streams. You can also specify that you want to distribute these data streams to other hosts that run syslog servers. Many administrators use such syslog servers to study audit records for particular usage patterns, and they often run additional scripts to study network activity and generate usage and departmental billing statistics.
![]() |
Tips Because syslog data streams use UDP and because of the high volume of data that a Policy Enforcement Point can generate, we strongly recommend that you locate your Policy Monitor Point on the network directly attached to an inside interface of the Policy Enforcement Point. For very high volume Policy Enforcement Points, we recommend that you dedicate a small DMZ network for monitoring purposes. You can do this using an internal router or switch or by installing an additional interface in the Policy Enforcement Point and attaching the DMZ network directly to the Policy Enforcement Point. This configuration prevents you from flooding your networks with UDP packets and offers a more reliable connection for syslog data. |
You can perform the following tasks from the Policy Enforcement Point panel. For step-by-step procedures on performing a specific task, click the corresponding link.
You can specify the IP address that a Cisco Secure Policy Manager host acting as a Policy Distribution Point uses to contact the Policy Enforcement Point for the purpose of publishing the derived network policies and to obtain status about the Policy Enforcement Point. This IP address must be an IP address assigned to an interface of the Policy Enforcement Point. This IP address can also be the IP address used by any other administrative tools that you use to review the status of this Policy Enforcement Point.
![]() |
Note For Policy Enforcement Points based on 4.x and earlier versions of PIX Firewall software, you cannot assign an IP address that is assigned to the outside interface of a PIX Firewall. The IP address must be assigned to the inside interface or one of the perimeter interfaces. |
To modify the IP address used to connect to the Policy Enforcement Point, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.

Step 3 To change the IP address on which the Policy Enforcement Point listens for requests from the Policy Distribution Point and other administrative tools, select the new IP address in the IP Address box under General Settings.
The list of IP addresses available are those IP addresses that are defined for the valid interfaces of this Policy Enforcement Point. These addresses are defined in the Interfaces panel of the selected Policy Enforcement Point node. By default, the Policy Enforcement Point panel uses the first IP address listed under the first interface attached to an upstream network.
![]() |
Caution If you modify the IP address that Cisco Secure Policy Manager uses to publish the commands to a Policy Enforcement Point (the address in the Policy Enforcement Point panel), you must define an intermediate security policy that allows the network service selected in the Enforcement panel to enable both the old and the new IP addresses. Otherwise, the connection to the Policy Enforcement Point is broken while the Policy Distribution Point is publishing the command set that changes from the old address to the new address. |
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
From the Policy Enforcement Point panel, you can specify the Policy Distribution Point that is used to publish new network policies to the Policy Enforcement Point. This Policy Distribution Point is responsible for generating and publishing network policies to Policy Enforcement Points, such as the PIX Firewall and IOS Router.
To select the Policy Distribution Point used to publish network policy to the Policy Enforcement Point, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.
Step 3 To select the host that is running the Policy Distribution Point that you want to use, click that host name in the Policy Distribution Point box under Policy Distribution.
This box displays only those primary and/or secondary servers defined under the Network Topology tree that have a Policy Distribution Point client/server product installed on them.
If you installed a standalone Cisco Secure Policy Manager, the Policy Distribution Point resides on that primary server. Otherwise, in a distributed installation, it can reside on either a primary or secondary server, depending on which feature sets you chose to install on the various hosts.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
From the Policy Enforcement Point panel, you can specify that you want the Cisco Secure Policy Manager host acting as the Policy Distribution Point to use an IPSec tunnel when communicating with the Policy Enforcement Point, such as a PIX Firewall or IOS Router. This tunnel can provide additional authentication, as well as encryption, for sessions that occur between the Policy Enforcement Point and the Policy Distribution Point, providing non-repudiation and data integrity for the network policies that are published to the Policy Enforcement Point.
To require Cisco Secure Policy Manager to use an IPSec tunnel when communicating with the Policy Enforcement Point, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.
Step 3 To select the IPSec Tunnel Template definition used to connect to the selected Policy Enforcement Point, click that template in the Use secure IPSec with template box under Policy Distribution.
This template must be defined under the IPSec Tunnel Templates branch of the Tools and Services tree. By default, the Policy Distribution Point does not use an IPSec tunnel when communicating with the Policy Enforcement Point.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
Step 6 Before publishing the command set to the Policy Enforcement Point, you must first configure the Policy Enforcement Point to accept the IPSec tunnel from the Policy Distribution Point. To configure the Policy Enforcement Point, refer to Cisco Secure Policy Manager Administrator's Guide: IPSec Tunnel Implementation.
From the Policy Enforcement Point panel, you can specify the Policy Monitor Point that is used to monitor the syslog data streams generated by the Policy Enforcement Point, such as a PIX Firewall or IOS Router. This Policy Monitor Point studies the syslog data to derive higher-level audit records, such as session records.
To select the Policy Monitor Point used to monitor Policy Enforcement Point syslog data streams, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.
Step 3 To select the host that is running the Policy Monitor Point that you want to use, click that host name in the Policy Monitor box under Logging.
This box displays only those primary and/or secondary servers defined under the Network Topology tree that have a Policy Monitor Point client/server product installed on them.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
From the Policy Enforcement Point panel, you can specify one or more syslog servers, in addition to the Cisco Secure Policy Manager host acting as Policy Monitor Point, that you can use to provide additional monitoring of the syslog data streams generated by the Policy Enforcement Point.
To select the syslog servers used to monitor Policy Enforcement Point syslog data streams, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.
Step 3 To select one or more hosts on which syslog servers are running, click those host names in the Syslog Monitors box under Logging.
This box displays only those hosts defined under the Network Topology tree that have a syslog client/server product installed on them. The host or hosts that you select must have a syslog application capable of processing the data streams. For instructions on installing and configuring these applications, refer to the documentation that came with those products.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
From the Policy Enforcement Point panel, you can specify the enable password for the selected Policy Enforcement Point. The Policy Distribution Point uses this password to authenticate to the Policy Enforcement Point before it can publish new network policies to that Policy Enforcement Point.
![]() |
Note All managed gateway objects require that you specify the enable password. |
To specify the enable password used to publish network policies to the Policy Enforcement Point, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.
Step 3 To specify the enable password, type that password in the Enable password box under Authentication.
The enable password can be up to 16 alphanumeric characters. Also, you can use both uppercase and lowercase characters. This password is case sensitive.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
From the Policy Enforcement Point panel, you can specify the Telnet password for the selected Policy Enforcement Point. Any administrators who connect to the Policy Enforcement Point to perform any diagnostic tests must first use this password to authenticate to the Policy Enforcement Point.
![]() |
Note Currently, only the IOS Router uses (and requires) the Telnet password. However, both the PIX Firewall and the IOS Router require that you specify the enable password. |
To specify the Telnet password used to authenticate to the Policy Enforcement Point, perform the following task:
Step 2 To view the Policy Enforcement Point panel, point to Properties and click Enforcement on the shortcut menu.
Result: The Policy Enforcement Point panel appears in the View pane.
Step 3 To specify the Telnet password, type that password in the Telnet password box under Authentication.
The Telnet password can be up to 16 alphanumeric and special characters; however, you cannot use the question mark, space, or colon in the password. You can use both uppercase and lowercase characters, because this password is case sensitive.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
Modifying the network service associated with a Policy Enforcement Point has no effect on the system or the configuration of that Policy Enforcement Point. For an IOS Router, this network service is Telnet (TCP port 23). For a PIX Firewall, this network service is PIX Secure Telnet (TCP port 1467).
When you want to define a control channel tunnel group, which uses IPSec tunnels to communicate between the Policy Distribution Point and a specific managed Policy Enforcement Point that supports IPSec, you must bootstrap each IPSec-enabled Policy Enforcement Point to ensure that it can act as a peer in that IPSec Tunnel Group definition. While you have to bootstrap the Policy Enforcement Points, you do not have to bootstrap the Cisco Secure Policy Manager hosts.
When a Cisco Secure Policy Manager host participates in an IPSec tunnel group, it is used to securely publish the generated commands sets to a managed Policy Enforcement Point, such as a PIX Firewall or IOS Router. However, for a Cisco Secure Policy Manager host to act as an IPSec peer, you must have the Cisco Secure VPN Client software installed and operational on the host that is acting as the Policy Distribution Point that will be participating in the IPSec tunnel.
If this node is not a Cisco Secure Policy Manager host, it must be a gateway object that is capable of participating in an IPSec tunnel. As an IPSec-capable gateway object, the node can participate in two types of tunnels:
From the IPSec panel on a node, you can specify three types of settings related to the use of IPSec by this node:
In addition, you can discover the properties of the certificate currently installed on this node, if you have chosen to use certificates and have previously loaded the certificate on this node during the bootstrap process.
The following sections describe each of these settings.
When you specify triple DES as the strongest cipher, this value does not mean that triple DES will be used by all IPSec Tunnel Groups in which this node is defined as a peer. If the other peers do not support triple DES, this node can still be used with IPSec Tunnel Templates that specify standard DES as the cipher. Cisco Secure Policy Manager uses this DES cipher setting to perform a consistency check to verify that your IPSec Tunnel Group definitions are based on IPSec Tunnel Templates that the peers in the group can support.
For additional information on encryption, ciphers, and how encryption works, refer to Cisco Secure Policy Manager Administrator's Guide: IPSec Tunnel Implementation.
Certificate authority servers use HTTP as the protocol for renewing and validating certificates. They manage data about when the certificates managed by the server expire and the rules for automatically refreshing or issuing new certificates to the network objects that are subscribers to that certificate authority. In addition, certificate authority servers provide support for certificate revocation lists (CRLs), which enable you to specify that certain certificates should not be trusted.
If at some point the selected network object no longer requires access to this certificate authority server, you must clear the selection in the Trusted Certificate Authority box in the IPSec panel.
Pre-shared keys offer a simple, yet secure, solution for smaller networks because they do not require the support of a public key infrastructure (PKI). Pre-shared keys enable you to define a common shared secret to be used by two peers that are capable of using IKE to negotiate the settings for a specific IPSec session. Because IKE periodically negotiates new session keys for use when encrypting the network packets of an IPSec session during that session, pre-shared secrets offer a more secure IPSec solution than manual keys, which generate only one pair of session keys. In addition, because pre-shared keys enable you to specify a single secret that is shared between each peer pair, the key administration is also simpler than that of IPSec solutions based on manual keys.
To overcome the day-to-day key administration issues involved in changing pre-shared keys in accordance with a strong organizational security policy, you can also specify that you want an IPSec-enabled network object to use a digital certificate (sometimes referred to as RSA certificate signatures) as the shared secret that peers use to authenticate that network object. In this configuration, the IPSec-enabled network object publishes its public key to its peers, which use that certificate to authenticate that network object.
Unlike pre-shared keys, certificates enable IPSec peers to authenticate using a trusted certificate authority. Because they do not require an IPSec-enabled network object to know a pre-shared secret for each of its peers, digital certificates are more scalable, which means they can support larger enterprise networks. While digital certificates are more technologically complex than pre-shared keys and they require the support of a PKI within your organization (including the purchase of a certificate from a trusted certification authority), they also offer a more secure method of authentication because the certificates can be configured to expire at which time new certificates can be issued automatically by a certificate authority server.
If you have previously configured this node to use a certificate when performing IKE negotiations, you can discover the properties of that certificate by clicking Discover in the IPSec panel.
This discovery process queries the node about that certificate and retrieves information, such as who issued the certificate, the serial number of the certificate, and the dates for which the certificate is valid.
You can use this information to ensure that you have the proper certificate loaded and to stay abreast of possible problems, such as expiration.
From the IPSec panel, you can identify the strongest DES cipher that the selected node supports. Cisco Secure Policy Manager uses this information to perform consistency checks that validate that all peers in IPSec Tunnel Group definitions based on IPSec Tunnel Templates that require specific ciphers can support those ciphers.
To specify the strongest DES cipher that this node can support, perform the following task:
Result: The IPsec panel appears in the View pane.

Step 2 To specify which DES cipher is supported by this node, click that cipher in the list of ciphers in the DES Cipher Support box.
Two types of DES ciphers are available, depending on the type of software that is running on the selected node:
Step 3 To accept your changes and close the selected panel, click OK.
Step 4 To save any changes that you have made, click Save on the File menu.
From the IPSec panel, you can specify a pre-shared secret that is used to perform IKE negotiations between the selected node and its IPSec Tunnel Group peers. Cisco Secure Policy Manager uses this secret to generate the device-specific commands that enable these pre-shared secrets on this node and its peers. You only need to specify this secret in this panel, because it is propagated to the IPSec panels for the specified peers. In other words, you only have to specify a shared secret on one of the two peer nodes.
To specify the secrets to share between this node and its peers, perform the following task:
Result: The IPsec panel appears in the View pane.
Step 2 To specify the peer for which you want to define a pre-shared secret between the selected node and that peer, click that peer in the list of available peers in the Tunnel Peers box.
Result: The Secret shared with peer label displays the name of the selected peer.
This list contains only those gateway objects and Cisco Secure Policy Manager hosts defined under the Network Topology tree that have the IPSec Support option selected in the General panel.
Step 3 To specify the secret to share between this node and the peer selected in the Tunnel Peers box, type that secret in the Secret shared with peer box.
This secret identifies a valid secret that can be used by IKE to set up an IPSec tunnel between this node and the selected peer. The minimum length for this secret value is 8 characters and the maximum length is 128 alphanumeric characters. You cannot use Tab, Enter, spaces, question marks, or double quotes when defining this shared secret.
Step 4 For each peer that you want to define a pre-shared secret, repeat Steps 2 and 3.
Step 5 To accept your changes and close the selected panel, click OK.
Step 6 To save any changes that you have made, click Save on the File menu.
To generate a new command set that includes the pre-shared secrets required by each peer, you must perform a Save and Update operation.
From the IPSec panel, you can identify that you want the selected node to be able to communicate with a certificate authority server that is defined under the Network Topology tree. Certificate authority servers use HTTP as the protocol for renewing and validating certificates. They manage data about when the certificates managed by the server expire and the rules for automatically refreshing or issuing new certificates to the network objects that are subscribers to that certificate authority. In addition, certificate authority servers provide support for CRLs, which enable you to specify that certain certificates should not be trusted.
![]() |
Tips Cisco Secure Policy Manager automatically creates and applies a security policy that permits HTTP traffic to pass between this node and the specified certificate authority server. |
To specify the certificate authority server to use for this node, perform the following task:
Result: The IPsec panel appears in the View pane.
Step 2 To specify which certificate authority server to use with this node, click that server in the list of certificate authority servers in the Trusted Certificate Authority Server box.
This value identifies a host defined in the Network Topology tree that has been configured to identify a certificate authority server by adding the Certificate Authority client-server product type to that host.
Step 3 To accept your changes and close the selected panel, click OK.
Step 4 To save any changes that you have made, click Save on the File menu.
From the IPSec panel, you can discover specific information about any certificates that are installed on a managed Policy Enforcement Point that has the IPSec Support option selected in the General panel for that Policy Enforcement Point node.
To discover the certificate information, perform the following task:
Result: The IPsec panel appears in the View pane.
Step 2 To specify that you want to discover the information about the certificates used by this node, click Discover.
Result: The Discovery dialog box appears with the IPSec box selected under the Discovery Selections box.

Step 3 To discover the certificate information and other IPSec settings for this node, click Discover.
Result: The Discovery Status box displays the status of the device discovery, including the time remaining before the discovery process aborts its discover attempt. When this process is complete, a message stating "Configuration completed. The configuration attempt was successful" appears. In addition, the Results button appears, which when clicked provides information about the discovery in the Discovery Results dialog box. Specifically, the Discovery Results dialog box should display the following messages:
Step 4 To close the Discovery dialog box, click OK.
Result: The IPSec panel now displays information about each certificate that was discovered. This information is organized on separate subtabs (below the Trusted Certificate Authority box) for each certificate that is discovered.
Step 5 To accept your changes and close the selected panel, click OK.
Step 6 To save any changes that you have made, click Save on the File menu.
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Sun Jun 4 16:59:00 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.