Table Of Contents

Release Notes for Management Center for Firewalls 1.3.4 on Windows 2000 and Solaris 2.8

Changed Features

Firewall MC Documentation

Documentation for Related Products

Documentation Updates and Errata

Installing Management Center for Firewalls 1.3.2 on Windows 2000 and Solaris 2.8

Using Management Center for Firewalls 1.3.2

Advanced Features and Command-Line Issues in Management Center for Firewalls 1.0 and Later

Resolved Issues

Known Issues

Obtaining Documentation

Documentation DVD

Ordering Documentation

Documentation Feedback

Cisco Product Security Overview

Reporting Security Problems in Cisco Products

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information

Release Notes for Management Center for Firewalls 1.3.4 on Windows 2000 and Solaris 2.8

September 20, 2005

These release notes are for use with CiscoWorks Management Center for Firewalls (Firewall MC) 1.3.4, which is a component in CiscoWorks VPN/Security Management Solution 2.3 (VMS).

Note You can also use Firewall MC 1.3.4 with VMS 2.2.

The web-based interface for Firewall MC enables you to configure new PIX Firewalls and Firewall Services Modules (FWSMs) and to import configurations from existing firewalls. You can configure firewall device settings, access rules, and translation rules, then deploy these configurations to your network. Firewall MC is also a powerful tool for controlling changes made to your network, showing configuration and status changes.

Release 1.3.4 recognizes the existence of FWSM release 2.3(2) and resolves customer-identified bugs in earlier Firewall MC releases.

Note Because FWSM release 2.3(2) includes no changes or additions to the FWSM command-line interface, no new commands are supported in Firewall MC 1.3.4.

This document might be updated at any time; the most recent revision is always available on

These release notes provide:

Changed Features

Firewall MC Documentation

Documentation for Related Products

Documentation Updates and Errata

Resolved Issues

Known Issues

Obtaining Documentation

Documentation Feedback

Cisco Product Security Overview

Obtaining Technical Assistance

Obtaining Additional Publications and Information

Changed Features

If you upgraded to Firewall MC 1.3.4, you might notice subtle differences in the behavior of certain product features. Any such differences are the result of improvements in Firewall MC 1.3.4 that resolve problems and other issues known to have existed in prior releases. See Resolved Issues.

Firewall MC Documentation

Note We sometimes update the printed and electronic documentation after original publication. Therefore, you should also review the documentation on for any updates.

Table 1 describes the Firewall MC documentation that is available.

Table 1 Firewall MC Documentation 

Document Title
Available Formats

Release Notes for Management Center for Firewalls 1.3.4 on Windows 2000

(this document)

Log in to and go to:

Installing Management Center for Firewalls 1.3.2 on Windows 2000 and Solaris 2.8

Log in to and go to:

Printed document available by order (part number DOC-7816517=).1

Using Management Center for Firewalls 1.3.2

Log in to and go to:

Printed document available by order (part number DOC-7816035=). 1

Supported Devices, OS Versions and Commands for Management Center for Firewalls 1.3.4.

Log in to and go to:

Advanced Features and Command-Line Issues in Management Center for Firewalls 1.0 and Later.

Log in to and go to:

Context-sensitive online help

Select an option from the CiscoWorks navigation tree, then click Help.

Click Help in the Firewall MC GUI.

1 See Obtaining Documentation.

Documentation for Related Products

Note We sometimes update the printed and electronic documentation after original publication. Therefore, you should also review the documentation on for any updates.

Table 2 identifies the documentation for VMS 2.3, in which Firewall MC is one component.

Table 2 Documentation for Related Products 

Document Title
Available Formats

Documentation Guide for the VPN/Security Management Solution 2.3

Log in to and go to:

Installing the VPN/Security Management Solution (VMS) 2.3 on Windows

Log in to and go to:

Installing the VPN/Security Management Solution (VMS) 2.3 on Solaris

Log in to and go to:

Documentation Updates and Errata

Please make note of the following updates and changes to the user documentation for Firewall MC as it pertains to release 1.3.4.

Note In cases where a published document has not changed since the release of an earlier Firewall MC version, its title might specify the release number for that earlier version even though the document applies equally to the 1.3.4 release.

Installing Management Center for Firewalls 1.3.2 on Windows 2000 and Solaris 2.8

Please make note of the following updates and addenda for Installing Management Center for Firewalls 1.3.2 on Windows 2000 and Solaris 2.8.

References to VMS 2.2

Firewall MC 1.3.2 was a component of VMS 2.2.

Firewall MC 1.3.4 can run on a VMS 2.2 server but is more correctly considered a component of VMS 2.3.

Where Installing Management Center for Firewalls 1.3.2 on Windows 2000 and Solaris 2.8 recommends that you read product documentation for the VMS 2.2 release, it is best to rely instead on the documentation for the VMS release that you actually use.

Installation Requirements

You must install the OpenSSL-d patch and SP3 for CiscoWorks Common Services prior to the installation of Firewall MC 1.3.4 on a Windows or Solaris server. To learn about this requirement (CSCsa13748), log in to the Cisco Software Bug Toolkit at

Install components in this order:

1. (Solaris-only) Sun Solaris patch 112438-01.

2. CiscoWorks Common Services 2.2.

3. CiscoWorks VMS 2.2 update 1.

4. SP3 for CiscoWorks Common Services .

5. The OpenSSL-d patch.

6. Firewall MC 1.3.4.

Client System Requirements

In some cases, the minimum client system requirements that are specified in Quick Start Guide for VPN/Security Management Solution 2.2 might be insufficient for Firewall MC 1.3.4. Client system memory requirements are related directly to the size and complexity of the device configurations that you manage. If any of your access control lists (ACLs) contain 5,000 or more rules, we recommend a minimum of 512KB of RAM for your client system and 1024KB of virtual memory.

Release Numbers in Procedures and Requirements

The installation procedures and requirements for release 1.3.4 are identical to the equivalent procedures and requirements for release 1.3.2, except for the release numbers. Therefore, when you install or upgrade to release 1.3.4, we recommend that you pay close attention to the release number references and substitute the string "1.3.4" for "1.3.2" wherever it is significant (such as in the filename of the installer package).

Firewall MC 1.3.4 Installation Binary Filenames

The filenames for the 1.3.4 installation binaries are as follows:



Applying CiscoWorks and VMS Patches

We recommend that you apply the latest patches for CiscoWorks Servers and VMS applications.

Security-related patches:

Other patches:

Applying Windows Service Packs

We recommend that all users of Microsoft Windows 2000 apply all suitable Windows service packs in their networks. Service packs resolve or reduce the degree of risk from many known security vulnerabilities in Windows. For more information about Windows 2000 service packs, see

Upgrading from an Earlier Release

You can upgrade to the Windows version of Firewall MC 1.3.4 from these previous releases:

Firewall MC 1.2.x.

Firewall MC 1.3.x.

Note Before you upgrade to the 1.3.4 release for Windows, you must confirm that you have installed the OpenSSL-d patch as well as SP3 for CiscoWorks Common Services.

You can upgrade to the Solaris version of Firewall MC 1.3.4 from these previous releases:

Firewall MC 1.2.2.

Firewall MC 1.3.3.

Note Before you upgrade to the 1.3.4 release for Solaris, you must confirm that you have installed the OpenSSL-d patch as well as SP3 for CiscoWorks Common Services.

Using Management Center for Firewalls 1.3.2

Please make note of the following updates and addenda for Using Management Center for Firewalls 1.3.2.

Accepted Syntax for Netmask Declarations

To provide a netmask (subnet mask) declaration in Firewall MC, you can use either of the standard formats for notation.

Bitcount format:

Dotted decimal format:

If you do not specify a netmask declaration, Firewall MC assumes a bitcount of /32. In dotted decimal format, that assumed netmask is

Note Firewall MC does not support hexadecimal notation of subnet masks.

Troubleshooting Deployment Failures with View Transcript

If an error occurs when you try to deploy a device configuration, the Deployment Status page displays a brief description of the error. For more detailed information, you can click View Transcript to see exactly which commands were exchanged between Firewall MC and the device.

One such deployment error that you might see is Failed to contact host: <contact IP address>, for which the possible causes include:

An incorrect contact IP address.

Improperly defined device bootstrapping settings (for example, if you fail to provide such settings for a device that you configure manually).

An interrupted connection to the device during deployment.

The deploy transcript for the first two of these causes would contain no entries, because a connection to the device would not have been established.

In a case of interrupted connectivity, the deploy transcript will show that some commands were sent to the device — in which case you can make note of the last successful exchange to determine whether it involved a command that can affect connectivity to the device, such as:

HTTP server

Route (including the default gateway)

Enable password

AAA Configuration

If these values are missing, the incomplete configuration will leave the device unreachable by its users, including Firewall MC.

Note Firewall MC uses a bulk deploy mode for PIX OS 6.3 and later, and for FWSM OS 2.1 and later. In these cases, a deployment might appear to be entirely successful, but then a subsequent deploy to the same device can fail with the message Failed to contact host: <contact IP address>.

In these cases, it is useful to consult the transcript from the previous deployment to see if any connectivity commands were present and if their misconfiguration caused the deployment failure.

Using Cisco Secure ACS with Firewall MC

A minor but possibly useful piece of guidance is missing from the "Adding Users" topic that starts on page B-31 in the Employing the Cisco Secure Access Control Server with Firewall MC appendix to Using Management Center for Firewalls 1.3.2.

Where the topic says, "For details on adding users to your Cisco Secure ACS, see your Cisco Secure ACS user guide," you can add the following simplified procedure.

Note This simplified procedure is not meant to replace the detailed instructions you find in the user guide for your Cisco Secure Access Control Server product, whether it is server-based or appliance-based. Many options are available for the configuration of user accounts.

To locate the user guide that applies to your ACS product, go to and click the name of the ACS version that you use:

Cisco Secure ACS for Windows.

Cisco Secure ACS Appliance.

Cisco Secure ACS for UNIX.

Then, find and click the title of the user guide for your product.

Caution Cisco Secure Access Control Server is a complex tool. If your organization configures it or uses it in any way that is inconsistent with the recommendations and instructions in the ACS user documentation, unpredictable results might allow Firewall MC users to perform actions that exceed their role or might prevent Firewall MC users from performing actions that are required by their role.

Step 1 Log in to your Cisco Secure ACS server and, on the ACS navigation bar, click User Setup.

Step 2 On the User Setup page, specify a username for the new account, then click Add/Edit.

Step 3 From the Password Authentication list in the User Setup area, select CiscoSecure Database.

Step 4 Use the Password field and the Confirm Password field respectively to provide and verify the user password.

Step 5 From the Group to which the user is assigned list, select the group to which the user will belong. (For example, you might select Default Group.)

The group assignment limits to a large extent which services, systems, and other resources the user is authorized to access. Verify that you are assigning the user to a group with adequate privileges for the functions that he or she will perform.

Step 6 Click Submit.

The user account is created. You can use this account to access Firewall MC, provided that the Group to which the user is assigned has appropriate privileges.

Step 7 (Optional) To verify or modify the user information:

a. On the ACS navigation bar, click User Setup.

b. On the User Setup page, enter the username for the newly created account, then click Add/Edit.

Note You can use the find feature to find a user without entering the entire username. To find a user, enter the first few letters of the username followed by an asterisk (*), for example jdo*, then click Find. Users whose username starts with the specified letters are listed in the User List pane. To view a page on which you can verify or modify the settings for a user account, click the associated username in the User List pane.

c. Use the provided fields to add or change information that defines the user account, then click Submit.

Advanced Features and Command-Line Issues in Management Center for Firewalls 1.0 and Later

This guide is available online for users of Firewall MC. See Firewall MC Documentation, for additional information.

Resolved Issues

Table 3 lists problems that have been resolved since the last release of Firewall MC.

NoteTo obtain more information about known problems, access the Cisco Software Bug Toolkit at (You will be prompted to log into

Bug headlines in Table 3 are printed word-for-word as they appear in the Software Bug Toolkit.

Table 3 Resolved Issues in Firewall MC 1.3.4 

Bug ID


FW MC should report end time and date for depoy jobs.


AAA rule:copy/cut and paste throws NullPointerException.


Deploy fails when cut&paste tunnel rules up/down group hierachy.


Firewall MC deletescrypto map dynamic when deploying config.


Not able to stop fwmc inst even the required patch is not applied.


Table disappears on pressing togle button in Access-list.


Even disabled interface need an IP addrress.


Not able to edit access rules contains port no.


ACS + FWMC Changing the contact address of a device.


Policy query returns null-pointer exception if scope is empty.


FE permits FQDN/IP Exceptions enabled XAuth & Mode-Config simultaneosly.


Service description add window empty when apostrophe in category names

Known Issues

This section contains the following problems and other issues known to exist in this release:

Activity Management Known Issues, Table 4

AAA Known Issues, Table 5

Browser Known Issues, Table 6

Configuration Known Issues, Table 7

Database Known Issues, Table 8

Deployment Known Issues, Table 9

GUI Known Issues, Table 10

Import Known Issues, Table 11

Installation and Upgrade Known Issues, Table 12

Reporting Known Issues, Table 13

Firewall MC Server Known Issue, Table 14

Known Issues with VMS that Affect Firewall MC, Table 15

NoteThe problems and other issues in the following tables are known to affect Firewall MC 1.3.4. However, some of the issues were found in earlier releases of the product, so their descriptions or headlines might contain references to PIX MC and CiscoWorks2000. Any such references apply to Firewall MC and CiscoWorks as well.

To obtain more information about known problems, use the Cisco Software Bug Toolkit at (You will be prompted to log into

Table 4 Activity Management Known Issues 

Bug ID
Additional Information


Duplicate device in the Activity Approval page.

If your server is configured to require the approval of activities, you might sometimes see a device twice in the Activity Approval page (Workflow > Activity Management > Approve). This behavior is not associated with any particular user role or activity type and occurs unpredictably.

No workaround available.


Simultaneous changes to the state of an open activity cause errors to occur.

An error message might be displayed if two users try simultaneously to change the state of an open activity. For example, you might see an error if one user tries to undo an activity at the same time another user tries to approve the activity.

To work around this problem, log out of your server, then log in again.


If there is an apostrophe in a device or group name, then can't see activity in Take Over Changes.

If an activity locks a device or a group that has an apostrophe in the name, Firewall MC will not recognize the activity in the Take Over Changes feature and you will not find the activity listed.

To work around this problem, remove the apostrophe from the device or group name.


No Workflow: Clicking two buttons in a table creates two activities.

If you are not using workflow and your first action is to navigate to a rule table and click several GUI buttons in rapid succession, Firewall MC might erroneously create two activities. You will not have this problem if you performed any other action for which Firewall MC would have already created an activity.

If Firewall MC does create two activities in such a situation, you can be locked out of the particular device or group that you were working in.

To work around this problem, enable workflow and undo the activity that caused the lock. You can then turn off workflow and proceed with your activities.

Table 5 AAA Known Issues 

Bug ID
Additional Information


When using Firewall MC with ACS, you must add any new devices to ACS first.

Cisco Secure Access Control Server supports TACACS+ authentication. If your CiscoWorks VPN/Security Management Solution (VMS) server relies on ACS/TACACS+ for device authentication, you can create or import a firewall device in Firewall MC even if you have not first defined that device in ACS/TACACS+ and added that device to an ACS network device group. No error message is displayed in Firewall MC.

No workaround is available. You cannot manage or deploy the device until it has ACS credentials.


Partial support for changing AAA authentication server for HTTP.

You see the following message if you try to change AAA authentication server settings for HTTP:

Directly changing AAA authentication settings for HTTP is currently not supported! It's recommended to disable AAA authentication first and deploy the change, then turn it on and deploy again with the new settings.

To work around this problem, do the following:

1. Select Configuration > Device Settings > AAA Admin Authentication, then disable AAA authentication for HTTP and save your changes.

2. Select Configuration > Device Settings > Firewall Device Contact Info.

3. Enter the enable password as the future contact.

4. Deploy the changes.

5. Select Configuration > Device Settings > AAA Admin Authentication, then reenable AAA authentication for HTTP.

6. (Optional) Make other planned server changes, at your discretion.

7. Enter the AAA username and password as the future contact, then deploy your changes.


If rules exist, rule tables permit Edit, Copy, Cut, and Delete for view-only users.

In no-workflow mode, a user with view-only privileges, such as the Help Desk role, can modify the rule table. The user cannot, however, perform the Save, Generate, and Deploy option.

To work around this problem, take over the changes of the Help Desk user from a privileged account, and then undo the changes.


Users with Help Desk role cannot view activity report.

If you have view-only permissions, you cannot view the activity report. This is because all radio buttons and check boxes are disabled for users who have view-only permission.

To work around this problem, log in under a different role with more privileges, or give additional permissions to users who require activity report access.

Table 6 Browser Known Issues 

Bug ID
Additional Information


Main browser window does not refresh after Import popup window is closed.

When you import a device into Firewall MC with a Netscape browser for either Windows or Solaris, then close the Import Status popup window, information in the main browser window does not refresh.

To work around this problem, you must refresh the browser manually.


Firewall OS field is blank when accessing Firewall MC in Solaris Netscape 7.0 browser.

Some lists in the Firewall OS Version page (Configuration > Device Settings > Firewall OS Version) display no information until you click them.

This problem affects Firewall MC releases 1.3.2 and later for Solaris, with Netscape 7.0 as the client.

To work around this problem, click a list and select an option from it.


Modal dialog boxes intermittently stay open when using Netscape.

When using Netscape, form items in modal dialog boxes have focus problems if you attempt to select the parent window. (A modal dialog box is one in which you must make a selection or click a button before you can continue.) After you click the parent window, you cannot use your mouse or press Tab to select an item from the form in the modal dialog box. Text fields are particularly susceptible to this issue.

To work around this issue, do one of the following:

Close or cancel out of the modal dialog box. Reopen the modal dialog box, and do not try to select the parent window.

Click the help link in the modal dialog, then close the help window. The items in the form should then behave properly. Do not try to gain focus on the parent window.


Internet Explorer hangs when you click away from page with applet before certificate dialog.

The Firewall MC window and CiscoWorks Desktop window might become unresponsive if you access the Configuration tab, then click the Firewall MC window again before the certificate dialog appears.

To work around this problem:

1. Open Windows Task Manager.

2. Click the Applications tab.

3. Select the Internet Explorer tasks that are not responding.

4. Click End Task.

5. Open a new browser, log in to CiscoWorks again, and then launch Firewall MC.

6. Click the Configuration tab, and then wait for the Certificate popup window to appear.

7. Accept the certificate.


User encounters blank or badly formatted page.

There are certain areas in Firewall MC where Javascript is used to refresh or reload the main page or a status window. Occasionally, Internet Explorer gets stuck when executing this Javascript code. When this happens, one of the following symptoms might appear:

The browser goes to a white screen and sits there for minutes, and when it eventually loads the page, the formatting of the fonts and a lot of the layout is distorted, but the browser itself is still active.

The browser goes to a white screen and never recovers. In this case, Internet Explorer can be either active or inactive (locked up).

To work around this problem, press F5 to reload the page. If the browser does not recover, then close all Internet Explorer windows, make sure the process itself is shut down (IEXPLORE.exe in the Task Manager), and then launch a fresh Internet Explorer and restart Firewall MC.


View config page fails to show all the rules on Solaris.

Configuration data in the View Configuration page is truncated for configurations that contain more than 56 Kb of data.

This is only a display problem, and it affects Firewall MC versions 1.3.2 and later for Solaris only.

To work around this problem, deploy to a file and verify that configuration data is intact.


Browser occasionally crashes when changing scope.

A Windows performance setting enables you to optimize performance for either applications or background services. If you have background services selected, then the browser might return exceptions or crash when you access the Object Selector. This behavior is very likely to happen if the client and server are on the same system.

To work around this problem, make sure that the operating system response is optimized for applications and not for background services:

1. Select Start > Settings > Control Panel > System.

2. Click the Advanced tab.

3. Click Performance Options.

4. In the Application response box, make sure that the Applications radio button is selected.

5. Click OK.


Using browser Refresh might cause unexpected results.

If you use your browser Refresh button (or press F5) instead of using the Refresh button that is available on some Firewall MC pages, you might see error messages repeated or see prompts to resend data.

To work around this problem, use the Refresh button on the GUI, when available, instead of pressing F5 or using your browser Refresh button.


If a JRE is not installed, Internet Explorer might take 5 minutes to prompt to install.

Internet Explorer sometimes takes an inordinate amount of time to determine the plug-in necessary to launch a Java applet, determine if it needs to obtain the plug-in, and finally actually initialize the download of the plug-in.

To work around this problem, wait for Internet Explorer to install the JRE.

Note Advanced Features and Command-line Issues in Management Center for Firewalls 1.0 and Later, available on, describes the policy effects that Firewall MC has on device configurations. The insights that you gain from reading the advanced features guide might be useful to you if you encounter any of the known issues that are described in the Configuration Known Issues table.

Table 7 Configuration Known Issues 

Bug ID
Additional Information


Cannot remove IDS settings from one PIX Firewall.

When you select Configuration > Device Settings > Advanced Security > IDS Policy, you might expect that you can make selections that enable you to remove IDS commands from the configuration for one PIX Firewall. However, the attempt to do so has no effect when you deploy/generate the configuration. Any IDS settings remain in the firewall configuration.

To work around this problem, you must select the Inherit Settings from Global check box and generate the configuration, then deselect the check box and generate the configuration a second time.


ACL rule expansion might occur with service groups and object groups.

You might notice ACL rule expansion when service and objects groups are defined, even when the optimization preference at Configuration > MC Settings > Management is set to "None in." Object groups are flattened as a result of group usage and Firewall MC settings.

No workaround is available because the described behavior is based on current design constraints.


Firewall MC translation effect on NAT'd addresses.

Firewall MC translation logic generates one rule apiece for the translated (internal) and globally routable (external) addresses on a PIX Firewall.

Example of an internal rule: access-list acl_mdc_1_authentication_TACACS+ deny tcp object-group Group_FTP host eq ftp

Example of an external rule: access-list acl_mdc_1_authentication_TACACS+ deny tcp object-group Group_FTP host eq ftpan access-list

No workaround is available. The described behavior provides the greatest possible security.


Conflict Detection error not shown in multiple level hierarchy.

When you define and select a network object, then search for conflicts with the definitions of other network objects, Firewall MC searches up the hierarchy and examines only those network objects that are parents of your selection. Thus, it is possible for conflicts to persist in the siblings or children of your selection.

No workaround is available.


VPN > IKE Options > FQDN/IP Exceptions — cannot edit created setting.

Firewall MC allows you to enable XAuth and Mode Config simultaneously. No error message is displayed in the GUI. These commands are mutually exclusive and errors occur when you try to deploy the flawed configuration to the device.

The only workaround is to select either XAuth or Mode Config, but not both, then regenerate the configuration and redeploy it.


AAA rules generate identity address translation rules.

If you set Identity Address Translation Rules to "Only" or "On" (Configuration > MC Settings > Management), Firewall MC generates NAT or static commands that correspond to addresses in both AAA rules and firewall rules.

To work around this problem, turn off Identity Address Translation Rules, which will also disable address translation for firewall rules.


Firewall MC allows invalid PIX failover configuration generation.

When failover is configured for a PIX Firewall, all enabled interfaces must be configured for failover with an IP address. If an enabled interface is not configured with an IP address, then the generation fails the first time you generate and Firewall MC will substitute for the IP address. This substituted IP address is not caught during later generations and the configuration reflects the address, which causes an error on the device.

To work around this problem, ensure that the failover IP addresses for all enabled interfaces are properly defined.


Failover enabled without correct IPs on each interface errors.

When the failover IP address is not on the same subnet as the interface IP address, a generate error occurs. When you click the View Errors link, you do not see any error messages in the generated configuration.

To work around this problem, specify a failover IP address that is on the same subnet as the interface.


Different pre-shared key policies with same key not permitted/generated.

In some cases, it is possible to get errors while generating ISAKMP preshared keys in a configuration even though the Tunnel Consistency panel in the GUI says the keys match on both ends of the tunnel.

Assume there is a tunnel between peers A and B, and A has a default preshared-key policy and B has a user-defined key for A's IP address. When you generate commands for A and B, Firewall MC will incorrectly generate errors saying no valid key is present for the respective peer even if A's default keystring is identical to B's user-defined keystring for A. However, the Tunnel Consistency check panel for this tunnel shows there is no key mismatch.

To work around this problem, set the same pre-shared key policy on both A and B. Either have user-defined keys on both ends, or have default keys on both ends.


There is no warning that vpnclient won't work when vpngroup missing.

Deploying partially configured Easy VPN Remote settings to a device does not issue a warning and the Easy VPN Remote is disabled on the device. The deployment transcript shows a message from the device that reads: Warning: No router certificate for key exchange. PIX Easy VPN
Remote disabled.

To work around this problem, make sure that the Group Name is entered on the Configuration > VPN > Remote Access > Easy VPN Remote.


Object groups still refer to deleted objects.

When you delete an object (service, service group, or network object), references to that object are not automatically removed from other object group definitions. If an object group with reference to a deleted object is used in a rule, generating a configuration that uses the rule results in a generation error.

To work around this problem, manually remove all references to deleted objects.


Cannot turn off failover on interface.

If you define a failover IP address for an interface, but failover is not enabled, the generated commands include the failover IP address. Some failover commands always show up in the generated configuration, because the Failover page does not have a means to delete these failover IP addresses from the generated configuration.

These commands do not affect the device's behavior when failover is disabled. On a device without a failover license, deploying failover commands does not cause a deployment error. The device ignores the commands.

There is no workaround.


AAA Rules permits LOCAL authorization/accounting for invalid services.

AAA authorization and accounting using the LOCAL protocol is permitted only for console, cut-through authentication, and command authorization services. The LOCAL AAA protocol is supported only in PIX Firewall OS 6.3 and later.

Services such as HTTP, FTP, and Telnet (cut-through proxy) can be enabled only for LOCAL AAA authentication and not for authorization and accounting and should not be enabled within Configuration > Access Rules > AAA Rules.


Fixup protocol esp-ike & isakmp enable <interface_name> cannot co-exist.

The following commands cannot coexist on a firewall device:

fixup protocol esp-ike

isakmp enable <interface_name>

However, Firewall MC enables you to configure both commands without generating an error.

The error is caught at the device and the deployment fails with an error saying:

PAT for ESP cannot be enabled since ISAKMP is enabled.

To work around this problem, do not place these two commands in the same configuration.


Spoke-grp two S2S tunnels to Hub-dvc same intf unsupported auto-gen key.

When you have multiple tunnels between a pair of devices where the same interface is used as the endpoint on one of the two devices, Firewall MC does not accurately create pre-shared keys for automatically generated and default key policies.

For example, consider two devices (A and B) with two tunnels (Tunnel-1 and Tunnel-2) between them:

Tunnel-1: A:inside <------> B:outside

Tunnel-2: A:outside <-----> B:outside

In this example, both tunnels end on the same interface of device B, while ending on different interfaces on device A. In such cases, Firewall MC automatically generates keys for one of the two tunnels, but not for both.

To work around this problem, specify user-defined keys on both devices (A and B). On device A, specify a single key for B:outside. On device B, specify two keys, one for A:inside and one A:outside. These key values should be identical.


Auto NAT settings can impact dual dynamic NAT.

PIX Firewall and FWSM implemented dual-NAT differently. Firewall MC follows the FWSM semantics.

On the PIX Firewall, if a dynamic NAT rule is applied to an interface with a lower security level, then you must define static translation rules to enable outgoing traffic from all other networks attached to that interface.

On FWSM, adding a dynamic translation rule does not require static translation rules to be defined for all other outgoing traffic (high to low security level interface traffic).

Firewall MC does not allow you to use the Identity Address Translation feature to auto-generate statics for outbound traffic when a dynamic translation rule exits on a lower security interface in a PIX Firewall configuration. You must manually define any such identity statics.


For FWSM, all policy statics are higher priority than all old statics.

The evaluation order of the static address translation rules differs between PIX OS 6.3.x and FWSM 2.x.

PIX OS 6.3.x evaluates in the following order:

1. Port-based statics (policy statics and original style statics intermixed)

2. Host-based statics (policy statics and original style statics intermixed)

FWSM 2.x evaluates in the following order:

1. Port-based policy statics

2. Host-based policy statics

3. Port-based original style statics

4. Host-based original style statics

Firewall MC models the PIX implementation. During import, Firewall MC assumes the PIX OS evaluation order. In most cases, this does not cause problems for FWSM. If you view the existing configuration on an FWSM, all policy statics appear before the original style statics. In this case, as long as the port or host-based statics are not split between the two styles, Firewall MC accurately imports the static address translation rules.

On generate, this presents no problem. Firewall MC generates only original-style statics or policy statics followed by original-style statics (if the Identity Address Translation feature is enabled).


Failover settings cannot be inherited.

The Inheritance settings for the Failover Interfaces configuration table fails to display any inherited interfaces defined at the parent scope.

No workaround is available.


Policy NAT ACL on PIX Firewall contains alias addresses.

When you import a PIX Firewall configuration that uses policy NAT rules that are not generated by Firewall MC, the rules that are retained in the GUI might not match the intended rules. Firewall MC uses real addresses to generate translated addresses. A real address is the address that a device actually uses, and can be either internally- or externally-routable.

To work around this problem, edit rules manually so that they contain real addresses.


Special characters are allowed in the IPSec Transform Set Name on the PIX Firewall, but Firewall MC returns an error when they are used.

If you are adding an IPSec transform set from Configuration > Building Blocks > IPSec Transform Sets and you use certain special characters (&,<,>,",~,^,|) in the transform set name, Firewall MC returns an error saying that these characters are not allowed, even though they are valid on a PIX Firewall.

To work around this problem, do not use these special characters in IPSec transform set names.


Static port address translation (interface) not supported.

Firewall MC does not support the interface keyword in the static command.

To work around this problem, avoid using the interface keyword in the static command. Use the actual address instead of the interface keyword. In a situation where the address is not known because DHCP is providing the address, no workaround exists.


PIX Interface command accepts VLAN as hardware ID.

When importing from file, Firewall MC allows the command interface vlan<n> [[<hw_speed> [shutdown]] to be issued or imported for PIX Firewall versions earlier than version 6.3 even though the VLAN is valid only for FWSMs and PIX Firewalls version 6.3 and later.

To work around this problem, make sure the VLAN hardware identifier is used only for FWSMs and PIX Firewalls version 6.3 and later.


Diff results are sometimes false for new and missing commands.

Firewall MC might falsely report that it has found differences where no differences exist when you compare these two files:

The configuration file that Firewall MC maintains for a device.

The configuration that is running on the actual device.

Errors of this kind can occur because Firewall MC organizes a configuration file into sections so that its commands are grouped according to their purpose. However, this grouping behavior is not always correct. Sometimes Firewall MC regards sections as different even if they are identical.

In certain other cases, Firewall MC detects some organizational differences, but not others.

No workaround is available.


Firewall MC does not support interface renaming on FWSM.

Renaming an interface on an FWSM blade fails. This failure occurs because no command exists for an FWSM that is equivalent to this PIX OS command: interface hardware_id change-vlan old_vlan_id new_vlan_id.

To work around this problem, do the following:

Caution When you use the following procedure, your FWSM will delete all settings and rules that are relevant to the specified interface. However, Firewall MC will retain its record of those settings and rules and will redeploy them to the FWSM when you finish the procedure. Thus, your FWSM will experience a service outage that is equal in its length to the required time for applying the FWSM configuration.

1. From the FWSM CLI, remove the interface to be renamed, by issuing the command no nameif <interface> [if_name] [security_lvl].

2. Rename the interface in the Firewall MC GUI.

Firewall MC will automatically update the policies associated with the renamed interface.

3. Generate and Deploy the configuration.

Table 8 Database Known Issues 

Bug ID
Additional Information


May lose object/protocol groups when compacting DB or upgrading.

The Firewall MC database sometimes loses groups, devices, or configuration settings. This problem occurs when you compact the database or upgrade to a newer Firewall MC release, but does not occur in every such case.

To work around this problem if you encounter it, do the following:

1. Contact Cisco TAC and request a copy of the corrective script.

2. On your server, either:

If you compacted the database, revert to the database as it existed before you compacted it.

If you upgraded to a newer release, downgrade to the Firewall MC version that you used previously.

3. Run the corrective script.


Firewall MC database fails when disk space or virtual memory is low.

On Windows 2000-based servers, when the Firewall MC database (fms.exe process) runs out of virtual memory or disk space, it shuts down and logs an error message in the Windows Event Viewer. The browser displays nothing (is blank) on any client system that attempts to access the Firewall MC application after the application has shut down. This client-side problem is not specific to any operating system or any brand of browser.

To detect this problem, check the Windows Event Viewer on the server to learn whether the fms.exe process has shut down as a result of low disk space or low virtual memory.

To work around this problem, shut down the CW2000 Daemon Manager while you allocate the appropriate resources, then restart the CW2000 Daemon Manager.


No Workflow mode hangs database in GENERATE_OPEN state.

If you install and run every component application in the CiscoWorks VPN/Security Management Solution 2.2 on Solaris, your server might not have enough SQL database "handles" available to satisfy the requirements of Firewall MC when it operates in "no workflow" mode.

To work around this problem, use "workflow" mode:

1. Restart the server on which you installed CiscoWorks VMS.

Note To learn more, read about CSCsa39341 at (You will be prompted to log into

2. On your client workstation, enable the address bar or location bar for your browser application, then open https://<ServerName_or_IP_address>/pixmdc/pixmdcServlet?locId=1.

3. Click Admin > Workflow Setup.

4. Select Use Workflow, then click Apply.

5. Select Workflow > Activity Management, then select whichever activity has the Generate_open entry in the State column.

6. Click Cancel.

Your browser refreshes and your selection reverts to the Edit state.

7. Reselect the activity whose state you changed, then click Reject.

8. (Optional) To use "no workflow" mode, return to Admin > Workflow Setup, then deselect Use Workflow and click Apply.


Group is locked by a discarded activity.

After you upgrade or restore a database that you saved from a pre-1.3 release of Firewall MC, an activity that you discard might leave a device group locked if the activity moved a device to or from that group.

To work around this problem, you must prune the discarded activity:

1. Select Admin > Maintenance.

2. In the Purge Approved/Discarded Activities Older Than field, enter the numeral 0.

3. Click Purge Now.


Benign database errors appear in log files.

The following message, seen in various log files, is innocuous: Persistence Error - slot read failed for non-determinable reason, 308, Persistence, Unknown, DEBUG.

This message might appear in the install log, operation log, or Tomcat stdout.log files. This message might appear at the time of installation or in the course of ordinary system operation.

No workaround is required.

Table 9 Deployment Known Issues 

Bug ID
Additional Information


Firewall MC does not detect FTP strict fixup if set via CLI.

Firewall MC does not detect the strict option for FTP fixups if you configure that option from the FWSM command line.This problem results in an inconsistency between the configuration on a blade and the configuration that Firewall MC associates with that blade.

To work around this problem, use Firewall MC to select the strict option.


Changes to tunnel config do not Save and Generate or Deploy.

If you change an imported PIX tunnel configuration in the IPSec Tunnel Templates configuration wizard (Configuration > Building Blocks > IPSec Tunnel Tempates), the changes are sometimes lost when you Save and Generate. In such cases, the changes cannot be deployed.

No workaround is available.


Deployment fails for a Network Object with a description.

In the Creating Network Object popup window, if you enter information in the Description field, deployment fails.

To work around this problem, do not enter any information in the Description field when you create a network object.


Deploy fails if number of interfaces in GUI and device differ.

When working in the Firewall MC GUI, sometimes the number of interfaces or their respective hardware IDs do not match those on the physical device. An example of this is if you were to define only ethernet0 and ethernet1 in the GUI when the device also has ethernet2. During deployment, Firewall MC tries to remove all configuration settings for the undefined interface, such as its IP address, which causes deployment errors and possibly traffic flow failure on that interface, depending on the settings you established for error handling.

To work around this problem, make sure the interface configuration in the GUI matches the configuration on the device. This includes the number of interfaces and their hardware IDs.


FWSM no longer supports periods in the hostname.

Firewall MC follows the PIX 6.x format for hostnames; however, FWSM 2.x no longer supports periods in the hostname (for example, "my.pix.1"). Therefore, you will be able to define an erroneous hostname for FWSM 2.x in Firewall MC. The FWSM 2.x device will catch this error as a deployment error.

To work around this problem, do not add a period to the hostname of an FWSM 2.x device.


Firewall OS version mismatch causes deployment failure.

When you upgrade the PIX Firewall OS version on a device and Firewall MC is set to Last Detected Firewall OS Version (Configuration > Device Settings > Firewall OS Version), deployment fails and you receive an error message about version mismatch.

To work around this problem, set the Firewall OS version manually, then redeploy with this change.


Firewall MC creates extra rules based on NAT 0 ACL.

When you import the configuration from a PIX Firewall that runs PIX OS 6.3 and uses NAT 0 ACLs, Firewall MC adds new rules to the ACLs. These new rules are an effect of the Firewall MC address translation logic, which creates rules for both the translated and the untranslated destination address.

To work around this problem, edit or delete whichever rules (translated or untranslated) you prefer not to keep.


Firewall MC generates a false warning for IP verify reverse-path command.

If you enable anti-spoofing at either the global or group level, Firewall MC might generate this false warning: The inherited feature Anti Spoofing is not supported in this firewall OS version.

You can safely ignore this false warning.


PIX OS 6.3(3)112 command access-list object-group-search not fully supported.

Firewall MC does not fully support the PIX OS command access-list name object-group-search.

You can use this command in the ending commands if you know the name of the access list.

When you deploy to a file or to AUS, the generated name is the name of the access list.

When you deploy to the device, if the access list must be modified, then Firewall MC uses the generated name or a variant that is the generated name with a suffix in the form _#.


Deploy failure could leave unbound ACLs on the device.

Deployment fails and the transcript shows that failure occurred at an arbitrary point, possibly while deploying ACL entry commands.

When several deployments fail, unbound ACLs might remain on the target device. These access lists are ignored during future deployments but might affect memory usage and lead to an out-of-memory condition for a future deployment.

To work around this problem, inspect the configuration on the device to see which access lists are in use and which access lists are defined. Remove the unused access lists with the command no access-list unused_name.


Deploying no isakmp client configuration address-pool local reboots PIX.

Deploying no isakmp client configuration address-pool local <poolname> <pifname> causes a PIX Firewall running 6.3(x) to crash and reboot.

This is a problem with the PIX hardware. To obtain more information about this problem, go to the Cisco Software Bug Toolkit at and refer to bug ID CSCed57964. (You will be prompted to log into

The effect on Firewall MC is that the deployment is not completed.

There is no workaround other than to do a clear isakmp on the device before deploying, and to configure Firewall MC to overwrite external changes by setting the Action on External Change to Device Config setting to Overwrite (Configuration > MC Settings > Management). However, this removes all isakmp commands—both isakmp and isakmp policy—which causes a temporary network outage. Firewall MC then reapplies these commands.


Part of the deploy transcript is out of order.

The deploy transcript is out of order with version and checksum information. This might cause confusion when you view the transcript. The checksum is actually obtained when you retrieve the configuration from the device before deployment.

No workaround is available.

Table 10 GUI Known Issues 

Bug ID
Additional Information


Solaris FWMC does not support editing of FQDN/IP options.

Firewall MC on a Solaris server does not allow you to change FQDN/IP options from VPN > Settings > FQDN/IP Xauth and mode config.

To work around this problem, do the following:

1. Select VPN > Settings > FQDN/IP Xauth and mode config.

2. Select and delete the entry you want to change.

3. Create a new entry that uses the necessary parameters.


Static route: No shortcut menu when you right-click.

You might expect to see a contextual menu (also known as a shortcut menu) when you right-click an element in the Static Route page (Configuration > Device Settings > Routing > Static Route), but no such menu appears.

There is no workaround.


Filtering on the Permit column is confusing.

In any access-rule table, the Permit column has icons to represent permit and deny. When you filter on this column, you can also use the words true or yes to permit an action, and false or no to deny an action. If you enter only the letter "y" as an abbreviation for the word "yes," the filter will match on "deny."

To work around this problem, spell out "true" or "yes" and "false" or "no" for filtering on this field.


Must close a Policy Query result window to submit another query.

When you submit a query from Report > Policy Query, if a popup window is already open as the result of an earlier policy query, the returned results of your second query do not replace the results of your first query in the open popup window. Thus, your second query returns no results.

To work around this problem, close the open Policy Query popup window before you submit a new query.


Job status determines the behavior of the Open button in Job Management.

When you select Workflow > Job Management, add a job, and leave the job in either the Edit state or the Submit state, the behavior of the Open button might not be as expected.

You might expect that a job in the Edit state would go to the Edit Open page or that a job in the Submit state would go to the Submitted Open state, but that is not what happens. Instead, when you click Open, you open the specified job in its wizard, where you can review settings and, in some cases, change settings. Permitted options will vary according to the job state.

No workaround is required.


Interfaces > PPPoE wizard fails to detect missing password.

When you enable PPPoE for an outside interface, the GUI fails to recognize whether you provided a password. Upon generation, the command is generated as vpdn username username password invalid-password.

To work around this problem, edit the settings for the interface to include a user password.


Firewall MC and CiscoWorks handle login name case sensitivity differently.

A Firewall MC message might tell you that the Global object is locked by a user with your current username, capitalized differently. This occurs when you log out without closing your activity, then log back in and capitalize your CiscoWorks username in a different way.

A CiscoWorks Server does not differentiate between uppercase and lowercase characters in usernames. It enforces case sensitivity for passwords only. Firewall MC distinguishes between differently-capitalized usernames so that, for example, ADMIN, Admin, and admin are considered different user accounts.

To work around this problem, never capitalize any letter in your CiscoWorks username when you log in.


Service Groups table is hidden after a failed paste.

If the GUI displays an error message after you try to paste a copied service group into the building blocks Service Groups page, and you dismiss the error message, the service groups table is no longer visible.

To work around this problem, click Service Groups in the TOC.


Can't change FWSM version and use Failover.

If you change the OS version of an FWSM device from 1.x to 2.x, or from 2.x to 1.x, an error message is displayed when you try to access the Failover page for that device.

To work around this problem:

1. Select Devices > Managing Groups.

2. Select the group that contains the FWSM device for which you changed the OS version, then click Edit.

3. Click Next on each page without changing any attributes, then click Finish on the final wizard page.


Help Desk GUI view privilege concerns.

A user with view-only privileges, such as the Help Desk role, can see some sensitive information, such as:

AAA server groups shared secret.

Any passwords/keys that are placed in the ending commands at import time, for example OSPF or NTP authentication keys.

LAN failover shared key.

IKE shared secret.

SNMP community string.

These items are displayed on pages in the clear, so access to the page allows their direct viewing.

There is no workaround.


Firewall MC does not generate failover bootstrap link or asterisk next to failover device.

There are two problems (labeled Problem A and Problem B) in the way that Firewall MC handles failover settings.

Problem A

If any LAN-based failover setting is changed, Firewall MC indicates that bootstrapping is needed by putting an asterisk after the name in the generation summary page and providing a link to the bootstrap commands. However, Firewall MC does not check whether failover is enabled during this process. Consequently, after Firewall MC imports a device that has LAN-based failover enabled but failover disabled, bootstrap information is provided, but is not necessary and mistakenly turns failover on if pasted to the device.

To work around the problem, ignore the LAN-based failover bootstrapping information provided by Firewall MC if you do not have failover enabled on a device.

Problem B

If a FWSM 2.x device has the failover lan interface command configured but failover disabled, Firewall MC turns its failover setting on and generates the failover command after importing this device.

To work around the problem, either remove the failover lan interface command from the device before importing, or disable the Enable Failover check box before generating a new configuration.


Select All in rule table doesn't always select all.

If you try to select all rules in the access rules table while the table is still loading, not all rules will be selected.

To work around this problem, wait until the rule table is fully loaded before you select all.


Edit Rule during Rule Table load slow.

If you try to edit a rule while the table is loading a large rule set, it takes a long time to return to the rule table after you click OK.

To work around this problem, wait for the rules to load completely in the table before you try to edit a rule.


Cut, copy and paste of IPSec tunnel templates removes transform sets.

When you paste an IPSec Tunnel Template on the IPSec Tunnel Templates page (Configuration > Building Blocks > IPSec Tunnel Templates), the Transform Set used by the template is lost and its value is set to None.

To work around this problem, you must edit the IPSec Tunnel Template, and then reselect the IPSec Transform Set for the template after pasting.

Note This information applies also to CSCeg00285 and CSCeg00267


Site-to-site VPN tunnels do not specify Global scope value.

When you work in the Global scope, if you add a tunnel at Configuration > VPN > Tunnel > Site-to-Site, the displayed value in the Defined At field should be "Global." Instead, no value is displayed.

There is no workaround.


With workflow, pressing Approve right after Reject throws null pointer.

In workflow mode, after an activity is submitted, the activity can be either approved or rejected. If you click Reject, then enter an activity transition comment, you see that the Approve button is still active. If you click Approve while the rejection is in progress, a null pointer exception occurs.

To work around this problem, do not click Approve when an activity rejection is being processed.


MAC Address table setting doesn't override when timeout is blank.

On the MAC Address Table page (Configuration > Device Settings > Transparent Firewall > MAC Address Table) and DHCP Relay Server page (Configuration > Device Settings > Servers and Services > DHCP Relay Server), you cannot clear the timeout setting when both of the following are true:

The table of interfaces for the feature is empty.

The timeout value is specified at the parent scope.

When you clear the timeout setting and click Apply, the Inherit settings check box is automatically selected and the parent value is inherited.

To work around this problem, add a row to the table, then delete the row before you clear the timeout field. You can then clear the timeout field and click Apply without the parent value being inherited.


GUI accepts illegal IDs for VLANs.

Firewall MC allows a user to enter a VLAN ID greater than 4095 without generating an error. However, subsequent deployment of the generated configuration might fail because of this illegal VLAN ID.

To work around this problem, do not enter a VLAN ID greater than 4095.


GUI should warn about duplicate IKE policies.

If a configuration has two IKE policies with different priority numbers but the same parameters, these two IKE policies can nonetheless be generated and deployed without warning, and the firewall device simply removes the duplicate policies when it receives deployment.

To work around this problem, do not define two or more IKE policies with different priority numbers and identical parameters.


Incorrect GUI restriction for user-key for managed objects.

If you select a hub's outside interface and create a user-defined preshared key, you are not able to create a second user-defined preshared key for the same hub's inside interface. An error results stating: User key with the same peer or with the same peer IP address already exists.

To work around this problem, create a key based on an IP address instead of a managed device interface.


Cannot add a rule using tear-off view if no rules exist.

The access rule table does not provide a popup menu unless there are rows in the table. If you expand a table that does not have rules, you cannot insert a rule because the popup menu cannot appear and there are no buttons at the bottom of the expanded table.

To work around this problem, do not expand an empty table.


Wrong group name shown in "Inherit settings from" when not inheriting.

If you deselect the Inherit settings check box, the text reads Inherit setting from: Global, instead of specifying the group from which the information would be inherited were this item selected. This is only a display problem. If you select the Inherit settings from check box, Firewall MC inherits correctly and the updated page shows the group from which you inherit.

To work around this problem, use the object selector or the links next to Scope to advance through the hierarchy toward Global and learn from where the settings are inherited. The closest ancestor that has its own settings (not inherited) is the one from which settings are inherited.


View all hex value ethertype option shows blank value.

If you try to view or edit an Ethertype rule that has a hexadecimal Ether value, the Ether value on the Ethertype Rule window will be blank.

To work around this problem, note the hexadecimal Ether value on the main Ethertype Rules table before viewing or editing the Ethertype rule. If you are editing the rule, you must enter this value before you click OK.


Second level Group doesn't allow both to Inherit and to Enforce/Mandate.

On any Configuration > Device Settings page, the Inherit Settings and Enforce/Mandate check boxes cannot be selected at the same time. When one check box is selected, the other one is disabled. Because of this limitation, you cannot inherit settings on a group while mandating that all children of that group use the same settings.

There is no workaround.

Table 11 Import Known Issues 

Bug ID
Additional Information


Mode-config field for FQDN/IP is blank after import.

When you import a configuration file or device that includes the "isakmp peer ip no-xauth" command, you might expect that the Mode-config field in the FQDN/IP table would display a value of "true." Instead, the field is sometimes blank.

To work around this problem, do the following:

1. Select VPN > Settings > FQDN/IP.

2. Delete the entry that has the blank field.

3. Create a new entry that uses the necessary parameters.


Multiuser import from file or directory fails.

If multiple users use the "Import configuration files for multiple devices" option (from Devices > Importing Devices > Select Import Type) to import one or more CFG files from a directory at the same time, the import fails.

To work around this problem, avoid having multiple users import from a directory at the same time.


Directory import with special chars displays a blank field.

After you import a directory of configuration files, if the directory name contains such special characters as an ampersand (&), the Importing Devices page in Firewall MC does not display device status or import directory information correctly. Instead, one or more of the displayed lines are blank.

To work around this problem, do not use any special characters in a directory name when you import a directory that contains configuration files.


No difference between ignored and unsupported commands in View Config.

When you import a PIX Firewall configuration into Firewall MC, if you click View Config from the Import Status page in the Importing Devices wizard, there is no way in the GUI for you to distinguish between ignored commands and unsupported commands. When you select the View Config option, both kinds of commands are listed in the Unsupported Commands section.

No workaround is available.

For definitions of the terms ignored commands and unsupported commands, see the "Support for PIX Firewall and Firewall Services Module CLI Commands" section in Supported Devices, OS Versions and Commands for Management Center for Firewalls 1.3.4.

To deepen your understanding of the effects that Firewall MC has on device configurations, see Advanced Features and Command-line Issues in Management Center for Firewalls 1.0 and Later.


Object group names accumulate suffixes.

The name of a network object group might change during import and generate in cases where both of the following are true:

You import and generate a PIX Firewall configuration that contains network object groups.

Those network object groups are translated by static translation rules.

You know that this kind of change has occurred if Firewall MC creates "shadow" object groups or building blocks with names that have suffixes appended to the original group name.

Furthermore, if you repeatedly import and generate in Firewall MC, these names might grow longer each time, from the addition of a new suffix at each repetition.

When your network object-groups are translated by static rules and an ACE refers to any of those groups as a destination, because the contents of the group change during import and generate, Firewall MC adds a suffix to the original group name. While Firewall MC logic tries to avoid making any redundant copies of an extant object group during import and generate, it does not consider whether a group has changed across multiple cycles of import and generate. Hence it does not guarantee that groups remain unique through multiple cycles of import and generate.

The only workaround is to manually rename a building block after import, so that network object group names remain short and manageable.


The Diff With Running Config option does not work in some cases.

In the Import Summary window (at the end of the device import process), the Diff With Running Config option sometimes does not show the differences between the configuration imported into Firewall MC and the configuration on the device. The Diff result window is blank. This occurs when the configuration on the device contains commands that are unsupported in Firewall MC.

To work around this problem, remove any unsupported commands from your configuration prior to importing. For more information, see Supported Devices, OS Versions, and Commands for Management Center for Firewalls 1.3.4.


Generate and import hang if config contains a high number of statics.

If you import or generate a device configuration with thousands of static translations, Firewall MC requires an extended amount of time to check if statics overlap and complete the operation.

This situation occurs when you import a configuration that contains a large number of identity statics that were created to permit traffic going from low to high security interfaces.

To work around this problem, remove the identity statics from the file that you used for import and then reimport the file. Or, you can remove these translations from the Firewall MC GUI. Firewall MC can recreate them as needed, if auto-identity NAT is enabled.


Firewall MC generates false warning messages for static translation padding.

The generation of valid PIX configurations might trigger false warning messages about overlapping global addresses.

If you import a PIX configuration that contains end-point padding for identity statics, then generate it, Firewall MC might generate warning messages for the padded endpoint statics, even though they are not incorrect.

To work around this problem, you can either ignore such warning messages or you can remove identity statics from the GUI after import, then enable the Firewall MC Auto-NAT feature.


Multiple users cannot import configs from distinct locations simultaneously.

If multiple Firewall MC users begin to import configuration files from separate directories at the same time, the import might fail.

To work around this problem, avoid having multiple users import configuration files from a directory at the same time.

Table 12 Installation and Upgrade Known Issues 

Bug ID
Additional Information


Back up database before Solaris upgrade.

When you upgrade from Firewall MC 1.2.2 on Solaris, the following message should appear, but does not:

Install will upgrade the database to the new version. You should perform a backup prior to upgrading. For detailed database backup instructions, see /cscoworks/ps3996/product_user_guide.
Are you ready to continue with the upgrade?

To work around this problem, you must perform a backup before you upgrade because the upgrade will always reinitialize (erase) the database.


During install, alphabetic characters are accepted in port number fields.

Port numbers are represented using numbers, not characters and symbols. If you define an invalid port number, the Firewall MC services will fail to start.

To work around this problem, accept the default value or use numbers when defining your port. To correct an invalid port number, reinstall Firewall MC.


McAfee VirusScan Enterprise adds to client RAM requirements.

When you work with many devices or with large devices, your Windows-based Firewall MC client system might display a warning message that says it is low on virtual memory. This memory problem occurs when both of the following are true:

Your client system meets only the minimum system requirements for a VMS client.

Your client system is running McAfee (Network Associates) VirusScan Enterprise 8.0.

In such cases, the minimum system requirements for VMS are sometimes not sufficient. Client systems with less than 512 MB of RAM might experience low virtual memory conditions.

If you want to work around this problem, we recommend that affected client systems in large network environments use more than 512 MB of RAM.

Table 13 Reporting Known Issues 

Bug ID
Additional Information


Disabled fixups are not shown in activity reports.

After you import a PIX Firewall configuration and approve it in Workflow mode, only the enabled basic and multimedia fixup applications (fixups) are shown in activity reports.

When all fixups are disabled, activity reports show no fixups. If a previously enabled fixup is disabled, that fixup is not shown.

There is no workaround.


Activity report lists all fixup ports when only one was changed.

If you change any fixup settings, all fixups that are displayed on the Basic or Multimedia Fixup page and checked as active appear on the Activity report even though they were not changed.

There is no workaround.


Activity report does not list deleted devices.

The Activity report does not include deleted devices if the parent group was also deleted in the same activity.

There is no workaround.


Activity Reports fails to display Add PPPoE Information parameters.

The activity report does not show detailed setting changes for an interface if the interface type is PPPoE.

There is no workaround.


Activity Report shows no change-data for pre-upgrade activity.

When you upgrade Firewall MC, any activity reports for prior changes are lost.

To work around this problem, save the activity reports to an XML file before you upgrade.


Activity and Device Setting Report shows current AAA Server Group name.

If you change a AAA Server group within an activity, this change is captured in the activity report. One of the entries in the report is the AAA Server Group name. Currently, even after the activity has been approved, the AAA Server group name in the report always reflects the name in the live system, not the one created in the activity. Thus, the new server group name is applied to all reports.

To work around this problem, save the activity report to a file after the activity has been approved.


Configuration difference report fails to work in some cases.

When comparing a configuration in Firewall MC to one on a device, if there are ACLs in the device configuration that are not bound to an interface, then Firewall MC cannot match them with the ACLs in the Firewall MC configuration.

To work around this problem, bind any unbound ACLs to an interface or remove them.


Ending commands are not retained in activity reports.

When you select the Inherit Settings check box on the Configuration > Device Settings > Config Additions > Ending Commands page, any information in Ending Commands at the current scope is removed. The information that was in Ending Commands is not retained in the activity report, and you will not be able to get this information back without undoing the activity.

No workaround is currently available.

Table 14 Firewall MC Server Known Issue 

Bug ID
Additional Information


FWSM generates benign SSL_SYSCALL_ERRORs when busy processing traffic.

Firewall MC sometimes displays SSL_SYSCALL_ERRORs for an FWSM during a Firewall MC deployment when the FWSM is busy processing traffic.

These errors were determined to be benign during testing. However, if Firewall MC reaches 500 such errors, the deployment fails.

To work around this problem, deploy when the FWSM is less busy.

Table 15 Known Issues with VMS that Affect Firewall MC 

Bug ID

The following VMS issues might affect users of Firewall MC. More information is available in the Release Notes for CiscoWorks Common Services at Specific details are available from the Cisco Software Bug Toolkit at (You will be prompted to log into


CSA Agent queries upgrade of FWMC from 1.2.2 to 1.3


Scheduling future Backups and Compacts requires two steps.


Services do not start after reboot during installation.


Difficulty browsing CiscoWorks2000 desktop from server machine.


Restore requires reboot.


MDCSupport utility does not erase its temporary directory.


Cannot launch CW2K desktop after Common Services installed on system with netForensics.


Licensing error when SQL service is not started


Hour and minute are not working for repeat backup database


Changing the Windows password causes service startup to fail.


CiscoWorks links do not work due to change in server IP address.

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

You can access the most current Cisco documentation at this URL:

You can access the Cisco website at this URL:

You can access international Cisco websites at this URL:

Documentation DVD

Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.

Registered users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.

Cisco Ordering tool:

Cisco Marketplace:

Ordering Documentation

You can find instructions for ordering documentation at this URL:

You can order Cisco documentation in these ways:

Registered users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:

Nonregistered users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 1 800 553-NETS (6387).

Documentation Feedback

You can send comments about technical documentation to

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL:

From this site, you can perform these tasks:

Report security vulnerabilities in Cisco products.

Obtain assistance with security incidents that involve Cisco products.

Register to receive security information from Cisco.

A current list of security advisories and notices for Cisco products is available at this URL:

If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:

Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:

Emergencies —

Nonemergencies —

Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:

In an emergency, you can also reach PSIRT by telephone:

1 877 228-7302

1 408 525-6532

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:

Access to all tools on the Cisco Technical Support Website requires a user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

For a complete list of Cisco TAC contacts, go to this URL:

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

World-class networking training is available from Cisco. You can view current offerings at this URL:


Posted: Tue Sep 20 16:30:33 PDT 2005
All contents are Copyright © 1992--2005 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.