Filter
Top Products
9-12
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 9 Troubleshooting Device Communication and Deployment
Troubleshooting Deployment
Error While Attempting to Remove Unreferenced Object
If you enable the Remove Unreferenced Object Groups from Device option on the Tools > Security
Manager Administration > Deployment page, Security Manager will remove objects during
deployment that are not used in any policies managed or discovered by Security Manager. If any policy
that is NOT discovered or managed by Security Manager is using such an object, Security Manager will
still attempt to delete that object during deployment. In such cases, deployment will fail with a transcript
error indicating that it was unable to delete the object as the object is being used. To successfully deploy,
disable the Remove Unreferenced Object Groups from Device option.
Security Manager Unable to Communicate With Device After Deployment
There are a number of policies that you can configure in Security Manager that prevent access to a
device. That is the point of security, ensuring that unwanted hosts cannot enter your network or network
devices.
However, you can inadvertently lock the Security Manager server out of a device, making it impossible
for Security Manager to deploy configurations to it or manage it. If you find that after a deployment,
Security Manager can no longer contact a device, and you have already checked that the device is up and
running and otherwise functioning normally, look into the following policies to see if they are causing
the lock-out:
• Firewall > Access Rules, or Firewall > Zone Based Firewall Rules —If you use these policies,
the rules must allow management traffic from the Security Manager server. Consider allowing at
least HTTP, HTTPS, SSH, and Telnet. Consider creating a shared policy that defines the required
access for Security Manager and applying it to all devices. Keep in mind that if you create any rules
in these policies, an implicit rule is added to the end of the policy that denies any traffic that is not
explicitly allowed.
• NAT policies—Make sure that you are not using a local address on the device as the original address
to be translated. Translating this address might result in translating the management traffic sent
between Security Manager and the device, causing the interruption.
• Device Access policies on routers—Security Manager might loose contact with a device after you
unassign a device access policy from the device and redeploy it. Device access policies can be used
to define the enable password for accessing the device. If you unassign this policy and redeploy, the
password is removed from the device. In such cases, the device typically reverts to the default
password. However, in some cases, the device might contain an additional password that is unknown
to Security Manager, such as a line console password. If this additional password exists, the device
reverts to that password instead of the default password. If that happens, Security Manager cannot
configure this device. Therefore, if you use a device access policy to configure the enable password
or enable secret password on a device, make sure that you do not unassign the policy without
assigning a new policy before the next deployment.
• Site-to-Site VPNs—If you lose communication with a spoke in a VPN, the problem can occur when
the Security Manager server communicates with an external interface on the spoke from within the
hub’s protected network. We recommend that when you add the hub device to Security Manager that
you define a management IP address that is located outside of the hub’s protected network.
• Platform > Device Admin > Device Access > Allowed Hosts—For IPS devices, the Allowed Hosts
policy identifies the hosts that can connect to the sensor. The Security Manager server must be
included in this policy.