Table Of Contents

Preparing the Firewall MC Environment

Selecting the Administrative Model and Authentication Mode

CiscoWorks Server Roles and Firewall MC Privileges

Cisco Secure ACS Roles and Privileges

Selecting the Workflow Mode

Understanding Workflow

Using Firewall MC with Workflow Disabled

Using Firewall MC with Workflow Enabled

Requiring Formal Approval

Setting Workflow Options

Configuring Global Firewall MC Controls

Configuring Management Controls

Configuring Deployment Controls

Configuring Import Controls

Configuring Feature Tracking Controls

Configuring Object Grouping

Configuring VPN Controls

Preparing the Firewall MC Environment

---

Firewall MC is flexible so as to support varied user environments. Before using Firewall MC, you should configure the system based on how you intend to use it. This section describes various settings that you can configure to control the way Firewall MC works.

Topics to be discussed are:

• Selecting the Administrative Model and Authentication Mode

• Selecting the Workflow Mode

• Configuring Global Firewall MC Controls

Selecting the Administrative Model and Authentication Mode

Use of Firewall MC requires that your username and password be authenticated. After authentication, your authorization is based on the privileges that you have. Your role is a collection of privileges that dictate the type of system access you have. If you are not authorized for certain Firewall MC tasks or for certain devices, the related Firewall MC controls are hidden or disabled.

---

Note When you use workflow with formal approval disabled, the button for completing (submitting) an activity or job is labeled Approve and there is no Submit button. However, you must have submittal privileges, not approval privileges, to click the Approve button in this case.

To work around this problem, make sure submittal privileges are assigned to users who must use the Approve button.

---

Your username and password are compared with the account information stored in the CiscoWorks or Cisco Secure Access Control Server (ACS) database, depending on which method you established as your AAA provider during installation. When you install CiscoWorks Common Services, the CiscoWorks Server provides administrative account services. By default, CiscoWorks manages authentication and authorization. You can change your AAA provider to Cisco Secure ACS before or after you install Firewall MC. See User Guide for CiscoWorks Common Services 2.2 for details.

When you change between CiscoWorks and Cisco Secure ACS authentication, you might not be able to manage the same activities and jobs. This is because you could have different privileges in the two authorization systems. As a result, you should always approve or undo remaining activities, and deploy or undo remaining jobs before changing the authentication scheme.

CiscoWorks Server Roles and Firewall MC Privileges

CiscoWorks has default roles that correspond to likely functions within your organization. Any username assigned to one or more roles has access to the privileges enabled by the role in Firewall MC. Roles are not set up hierarchically; each role does not include all privileges of the role below it. Instead, the roles are based on user needs.

Cisco Secure ACS Roles and Privileges

Cisco Secure ACS 3.1 and later supports roles that are specific to Firewall MC. User authentication with Cisco Secure ACS is more sophisticated than CiscoWorks authentication because Cisco Secure ACS provides for a variety of privilege combinations that you can control, such as definition of user permission sets and user group permission sets, as well as the application of such permissions to devices and device sets.

Because Cisco Secure ACS applies user and administrative privileges in relation to AAA clients, you must represent the CiscoWorks Server on which Firewall MC is running—and each firewall device—as AAA clients. For details, see Configuring Authentication and Authorization in User Guide for CiscoWorks Common Services 2.2.

To use Cisco Secure ACS, ensure the following:

•You have a command authorization set that includes those commands that are required to perform a function in Firewall MC.

•You have a user role with a corresponding command authorization set applied for Firewall MC.

•If a Network Access Restriction (NAR) is applied to the profile, it must include the device group (or the device) to administer.

•In adding the Firewall MC as an AAA client, you can use the keyword "dynamic" in place of an IP address if the firewall devices managed by Firewall MC never directly request AAA services from Cisco Secure ACS.

•If the firewall devices managed by Firewall MC use Cisco Secure ACS for command authorization, make sure you configured a shell command authorization set.

•Managed device names are spelled and capitalized identically in Cisco Secure ACS and in Firewall MC.

To import a PIX Firewall, ensure that the shared profile includes the show config command in the authorized command set, the device definition under Network Access Restrictions, and the user role that includes administrative privileges.

If, for example, you have the privilege for importing firewall devices, you must have device-level permission to administer each firewall. In the same way, if you have the privilege for deploying on Firewall MC, you must have Firewall MC permission to deploy a configuration file to a PIX Firewall. If you do not have the needed permission on the device, the deployment fails.

For an understanding of TACACS+ security advantages, see User Guide for Cisco Secure ACS.

Figure 3-1 shows how the Cisco Secure ACS user-interface page defines Firewall MC roles and permissions.

Figure 3-1 Cisco Secure ACS Page for Defining Firewall MC Roles and Permissions

Cisco Secure ACS assigns eight default roles to Firewall MC, but you can add or delete user-defined roles when you customize your role and permission settings. Also, if you select options under Approve, Edit, Deploy, or Control, the related view privilege is selected implicitly.

Selecting the Workflow Mode

Firewall MC provides workflow support that allows you to assign different roles and responsibilities to different users. You can configure workflow to provide the most simple and streamlined user experience, or you can configure advanced workflow options to differentiate user responsibilities and enhance auditability.

If you are using the Workflow Setup option (Admin > Workflow Setup), you can specify whether to use jobs and activities to track changes made in Firewall MC. You can also specify whether those jobs or activities should be approved formally before you can perform the next phase of the workflow. Before you select workflow options, you must understand how the different options affect the operation of Firewall MC.

Understanding Workflow

Many organizations benefit from separating responsibility for defining, approving, and deploying corporate firewall policies. For example, a security administrator might be responsible for defining a device configuration file, another administrator for approving the configuration file, and a network operator for deploying the resulting configuration to a device. This separation of responsibility helps maintain the integrity of deployed configurations.

Firewall MC supports this separation of responsibility by using activities and jobs, also referred to as workflow. Activities control policy changes, and jobs define deployment of configuration files. For more information, see Using Firewall MC with Workflow Enabled. You can set up Firewall MC to require formal approval for activities, jobs, or both. For more information, see Requiring Formal Approval. Workflow and formal approval are disabled by default, but you can enable either by selecting Admin > Workflow Setup.

Other organizations might prefer a more streamlined approach to administering their corporate firewall policies. For these organizations, the workflow feature can be turned off, eliminating the need for you to define activities and jobs; activities are defined automatically by Firewall MC and no jobs are required to deploy configurations. For more information, see Using Firewall MC with Workflow Disabled.

Using Firewall MC with Workflow Disabled

When workflow is disabled (default), you do not need to define activities for tracking changes in Firewall MC; instead, Firewall MC defines activities automatically when you modify a device's configuration. You also do not need to define jobs to deploy configurations. After you make configuration changes, you can deploy those changes by clicking the Save and Deploy icon in the activity bar of the Devices and Configuration tabs, or you can discard the changes by clicking the Undo icon. When you click the Save and Deploy icon, new configurations are generated for any modified devices. You can then deploy the new configurations, or you can save them and deploy them later. For more information, see Managing Deployment with Workflow Disabled.

---

Note The Deployment tab is visible only when workflow is disabled. When you enable workflow, the Deployment tab is replaced by the Workflow tab, and you manage deployments using jobs. For more information on using jobs for deployment, see Using Job Management.

---

Important Notes about Using Firewall MC when Workflow is Disabled

•You can enable workflow at any time, but to disable workflow, you must first approve or discard any open activities and deploy, cancel, or verify that all jobs are being deployed.

•You do not need to define an activity when workflow is disabled; an activity is assigned to you automatically. To view activity report information, click the View Details icon in the activity bar, or select Reports > Activity.

•Locks are assigned to users, not activities.

•Users acquire locks as needed.

•After you save and deploy or save a configuration for deployment later, the lock on a device is released.

•When workflow is disabled, you must specify the deployment type before deploying. To specify the deployment type for a device or group, select Configuration > MC Settings > Deployment, then click the Deployment Type radio button that corresponds with the method to use for deployment.

Using Firewall MC with Workflow Enabled

When workflow is enabled, you use activities to track changes to configurations and use jobs to track the deployment of these configurations to the firewall devices that you manage.

Understanding Activities

An activity is a collection of policy changes typically made for a single purpose. For example, you might create an activity to collect the changes needed to address a problem identified in a trouble ticket filed with your help desk. Alternatively, you might create an activity to implement a new policy.

Before you can begin importing devices and adding configuration settings and rules, you must define an activity. An activity is accomplished by one or more people in succession. To access this feature, select Workflow > Activity Management.

After an activity is completed, you can submit it for approval (if approval is enabled). If the activity is approved, it is committed and ready to be deployed through the use of a job. If the activity is rejected, you can modify the activity and again submit it for approval, or delete the activity and begin again.

---

Note If approval is disabled (the default), the activity submit and approve process is a single step.

---

Figure 3-2 shows activity workflow with the approval process enabled. If the approval process is disabled, the submit action is not used.

Figure 3-2 Activity Workflow

For more information on activities, see Managing Activities with Workflow Enabled.

Understanding Jobs

A job represents a set of configuration files to be deployed to devices, configuration files, or an AUS. After you define a job, you can submit it for approval (if the approval process is enabled).

If the job is approved, it is ready for deployment. If the job is rejected, you can modify the job and submit it again for approval, or delete the job and begin again. To access this feature, select Workflow > Job Management.

Figure 3-3 shows job workflow with approval enabled. The approved job is then deployed to the network. If approval is disabled, the submit and approve actions are not used.

Figure 3-3 Job Workflow Diagram

After a job is approved, the final stage is deployment. This downloads configuration files to specified devices on your network, saves them as files, or sends them to an AUS.

A rollback feature is also available when workflow is enabled. The rollback feature allows you to revert to the previous configuration files. To access these features (Deploy and Rollback), select Workflow > Job Management.

For more information on jobs, see Managing Deployment With Workflow Enabled.

Requiring Formal Approval

Many organizations benefit from a separation of responsibility for defining, approving, and deploying corporate firewall policies. This separation helps maintain the integrity of deployed device configurations and defines a clear audit trail. If your organization requires that policy changes must be defined by one person and approved by another, then you should enable the formal approval phase in Firewall MC.

Firewall MC supports this separation of responsibility by using activities and jobs, which define tasks that are accomplished by one or more people in succession. (See Managing Activities with Workflow Enabled and Managing Deployment With Workflow Enabled for more information about activities and jobs.)

By default, workflow and these approval options are disabled, but you can enable one or both if your organization requires a formal approval process. Firewall MC supports two different formal approval phases:

• Approving Activities

• Approving Jobs

Approving Activities

The approval phase separates the person who defines policy from the person who defines a job. An activity must receive formal approval before it can be included as part of a job.

In the following figure, A represents two additional states: Submitted and Rejected, and identifies four possible actions: Submit, Approve, Reject, and Open. By default, when you submit an activity, the state moves directly to Approved. If activity approval is enabled, when you submit an activity, it moves to the Submitted state, where it can be formally rejected or approved. The activity then moves to the Approved state after it has formally been approved.

Approving Jobs

The approval phase separates the person who defines jobs from the person who deploys a job. A job must receive formal approval before it can be deployed.

In the following figure, B represents a Submitted state and identifies three possible actions: Submit, Approve, and Reject. By default, when you submit a job, the state moves to Approved. If you enable job approval, when you submit a job, it moves to the Submitted state, where it can be formally rejected or approved. The job then moves to the Approved state after it has formally been approved.

Setting Workflow Options

The Workflow Setup feature allows you to configure the way you use Firewall MC to make changes to your configurations and deploy those configurations to the firewall devices you manage.

---

Tip You do not need to open an activity to perform tasks from the Admin tab; however, you must be logged in to Firewall MC with permission to access the options within this tab.

---

---

Step 1 Select Admin > Workflow Setup.

The Workflow Setup page appears.

Step 2 To disable workflow:

---

Note Workflow is disabled by default. You need to perform this procedure only if you previously enabled workflow and now want to turn this feature off.

---

a. Approve or discard all open activities.

b. Deploy, cancel, or verify all jobs that are being deployed.

c. Deselect the Use Workflow check box.

d. Skip to Step 6.

Step 3 To enable workflow, select the Use Workflow check box.

Step 4 To require that all activities be approved before being included in a job, select the Require Activity Approval check box. To turn this feature off, deselect the Require Activity Approval check box. Workflow must be enabled for you to use this feature.

---

Caution When you enable this option, all in-progress activities are subject to formal approval. However, if you want to disable the option, you must approve any submitted activities first. Otherwise, the following error message results: Operation Failed. Another user has already closed the activity.

---

Step 5 To require that all jobs be approved before being deployed, select the Require Job Approval check box. To turn this feature off, deselect the Require Job Approval check box. Workflow must be enabled for you to use this feature.

---

Note When you enable this option, all in-progress jobs are subject to formal approval. However, if you want to disable the option, you must approve any submitted jobs first.

---

Step 6 To save your changes, click Apply.

---

Table 3-1 describes the elements on the Workflow Setup Page page.

Table 3-1 Workflow Setup Page

Element	Description
Use Workflow check box	When selected, enables use of jobs and activities to track changes in Firewall MC.
Require Activity Approval check box	When selected, enables activity approval process.
Require Job Approval check box	When selected, enables job approval process.

Configuring Global Firewall MC Controls

The MC Settings feature controls how Firewall MC operates when it discovers commands configured outside of Firewall MC and discovers unsupported and error commands imported to Firewall MC. It identifies the directories in which imported and deployed configurations reside.

Configuring Management Controls

The Management feature allows you to control Firewall MC operation. To access this feature, select Configuration > MC Settings > Management.

When you modify a firewall device configuration outside of Firewall MC, the changes are temporary unless you save them (write memory command) in the device's nonvolatile storage (Flash memory). Each time the device is rebooted, it reads its configuration from nonvolatile storage. As a result, temporary changes are lost if they are not saved.

Firewall MC detects any permanent changes made to a device by a method other than Firewall MC. You can request that Firewall MC fail the deployment when other methods are detected. If you request that Firewall MC deploy a configuration to a device to which permanent changes have been made, a warning is generated in the deploy status window.

To retain changes made to a firewall device configuration by a means other than Firewall MC, you can delete the device, then reimport it; however, doing so results in the need to redefine device name, group, and hierarchy information. See Important Notes About Importing Devices, page 7-3, to better understand the implications of using this method.

Setting Management Controls

---

Step 1 Select Configuration > MC Settings > Management.

The Management page appears.

Step 2 Select the appropriate Identity Address Translation Rules radio button to control whether Firewall MC automatically generates an internal address translation rule that associates an address to itself if no user-specified translation rule is present.

•On—Automatically generates identity address translation rule for an address if no other translation rule is defined for that address.

•Off—Never generates identity address translation rule.

•Only—Generates identity address translation rules only if no user-defined address translation rules exist. This feature becomes disabled as soon as you manually define any translation rule.

Step 3 To enable static policy NAT and PAT, select the Enable Policy NAT Rules Definition check box.

If enabled, the Destination Address(es) field appears in the static translations table. If policy NAT is enabled, the generated rules always use the access list form of the static command. Otherwise, the non-access list form of the static command is used.

Step 4 Select how Firewall MC should respond to unknown commands.

•Error—Unknown command becomes an error command (default).

•Warning—Unknown command becomes a warning; the command is ignored.

Step 5 Select the configuration optimization level to use on file generation.

•None—Generates all rules.

•Full—Unnecessary rules and contradictory rules are eliminated.

---

Note If you indicated that you want to keep groups during generation (Configuration > MC Settings > Object Grouping), optimization on rules using groups will not take place. To allow optimization settings to take precedence over group operations, change the Group Operation setting to Defer to the optimization level settings.

---

Step 6 Select the configuration optimization level to use during import.

•None—Creates all rules.

•Full—Unnecessary rules and contradictory rules are eliminated.

---

Note If you indicated that you want to keep groups during import (Configuration > MC Settings > Object Grouping), optimization on rules using groups will not take place. To allow optimization settings to take precedence over group operations, change the Group Operation setting to Defer to the optimization level settings.

---

Step 7 Select the Clear XLATE on deployment check box (recommended).

Step 8 Verify that the Clear ACLs before deployment (FWSM only) check box is not selected.

---

Caution We recommend that you do not select this option unless instructed to do so by TAC.

---

Step 9 Select how Firewall MC should respond to an external change to a device configuration.

•Error—Generates error message: External change to config!

Configuration file is not deployed.

•Overwrite—Generates warning: External change to config!

Firewall MC deploys the configuration file if device configuration has been changed by a method other than Firewall MC.

Step 10 Select how Firewall MC should respond when an error during deployment results.

•Restore previous config—Reboots (without saving) and reverts to the previous configuration.

•Continue—Logs an error message but ignores the error and continues deploying the configuration. Use this option only when you understand that the error will occur, you have evaluated it, and have determined that it is okay.

•Stop—Stops sending the configuration when an error is found, but does not reboot. Device is left partially reconfigured (not recommended).

Step 11 Select how Firewall MC should respond if a conflict is detected when adding or editing a building block.

•None—Firewall MC does not check for conflicting building blocks (default).

•Error—Firewall MC issues an error message and does not allow you to add the building block.

•Warning—Firewall MC issues a warning, but allows you to continue adding the building block.

Step 12 To save your changes, click Apply.

---

Table 3-2 describes the elements on the Management page.

Table 3-2 Management 

Element	Description
Inherit settings check box	When selected, the subgroup or device inherits the settings of the enclosing group to the current scope. You can override a default by deselecting the check box and specifying other values. See What Is Inheritance?. Note A grayed-out check box disallows changes at the current scope.
Enforce/Mandate settings for children check box	When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?. Note A grayed-out check box disallows changes at the current scope.
Identity Address Translation Rules: radio buttons	Controls whether Firewall MC automatically generates an internal address translation rule that associates an address to itself if no user-specified translation rule is present. Feature is also referred to as auto-identity NAT. •Only—Generates an identity address translation rules only if no user-defined address translation rules exist. This setting effectively disables this feature as soon as you manually define any translation rule. •On—Automatically generates an identity address translation rule for an address if no other translation rule is defined for that address. •Off—Never generates an identity address translation rule.
Enable Policy NAT Rules Definition check box	Select the Enable Policy NAT Rules Definition check box to enable static policy NAT and PAT. If enabled, the Destination Address(es) field appears in the static translations table. If policy NAT is enabled, the generated rules always use the access list form of the static command. Otherwise, the non-access list form of the static command is used.
Action on Unknown Commands: radio buttons	•Error—Unknown becomes an error command (default). •Warning—Unknown becomes a warning; the command is ignored. Note If an unknown command is treated as a warning, it becomes an ending command for that device. Unknown commands can occur during a device import.
Configuration Optimization Level on Generation: radio button	Controls amount of optimization on enabled ACLs during generation. Optimization helps to reduce the number of commands. •Full—Unnecessary rules and contradictory rules are eliminated. •None—Generates all rules. Note If networks are merged, no separate distinctions can be identified. If you indicated that you want to keep groups during generation (Configuration > MC Settings > Object Grouping), optimization of rules using groups will not take place. To allow optimization settings to take precedence over group operations, change the Group Operation setting to Defer to the optimization level settings.
Configuration Optimization Level on Import radio button	Controls amount of optimization on enabled ACLs during import. Optimization helps to reduce the number of commands. •Full—Unnecessary rules and contradictory rules eliminated. •None—Creates all rules. Note If networks are merged, no separate distinctions can be identified. If you indicated that you want to keep groups during import (Configuration > MC Settings > Object Grouping), optimization of rules using groups will not take place. To allow optimization settings to take precedence over group operations, change the Group Operation setting to Defer to the optimization level settings.
Clear XLATE on deployment check box	When the Clear XLATE on deployment check box is selected, starts clear translation and stops existing connections. Necessary for certain commands to take effect. Note If commands are changed, you should request clear translation.
Clear ACLs before deployment (FWSM only) check box	Controls whether Firewall MC should clear existing ACLs before deploying new ones. Caution We recommend that you do not select this option unless instructed to do so by TAC.
Action on External Change to Device Config: radio buttons	•Overwrite—Generates warning, External change to config! Firewall MC deploys configuration file if device configuration has been changed by a means other than Firewall MC. •Error—Generates error, External change to config! Configuration file is not deployed. Note Temporary changes (changes that were not written to a firewall device's nonvolatile storage) are lost when a configuration file is deployed, regardless of the selection. Note To retain changes made to a firewall device configuration by a means other than Firewall MC, you can delete the device, then reimport it. Doing so results in the need to redefine device name, group, and hierarchy information. See Important Notes About Importing Devices, page 7-3 to better understand the implications of using this method.
On Deployment Error: radio buttons	Instructs Firewall MC how to proceed if an error occurs during deployment. •Restore previous config (reboot)—Reverts to previous state. •Continue—Ignores error and continues deployment. •Stop (device left partially reconfigured)—Stops deployment, but does not reboot. Note If you are using the system for a newer operating system that is not fully supported by Firewall MC, you might receive unexpected responses that are reported as errors but are harmless.
Building Block Conflict Detection: radio buttons	Instructs Firewall MC how to proceed if the building block being added or edited conflicts with an existing building block. •None—Firewall MC does not check for conflicting building blocks (default). •Error—Firewall MC issues an error message and does not allow you to add the building block. •Warning—Firewall MC issues a warning, but allows you to continue adding the building block.

Configuring Deployment Controls

The Setting Deployment feature allows you to specify how configuration information should be deployed. These settings are applied to Firewall MC. Options are:

•Save the information to a file.

•Download directly to devices.

•Select a server that acts as a repository.

To access this feature, select Configuration > MC Settings > Deployment.

The CiscoWorks Auto Update Server (AUS) provides a browser-based interface for upgrading device configuration files and software images on PIX Firewalls that use the Auto Update feature. You can install AUS on the Firewall MC server. If you decide to install AUS, you must configure it to communicate with other system devices on your network. See Representing Auto Update Servers, page 7-45.

---

Note Firewall devices that are configured for failover are not supported by the AUS.

---

Important Notes about Deploying to an AUS

•If you deploy a job to an AUS, then cancel the job midstream, Firewall MC might display the incorrect deployment status. We recommend that you check the AUS logs to determine which devices were actually deployed.

•If you deploy a PPPoE configuration to a firewall device that already has PPPoE configured on the outside interface (ip address outside pppoe), any existing PPPoE connection to an access concentrator is reset and cleared. The firewall device must then reauthenticate and reconnect to the access concentrator.

•Firewall devices that are configured for failover are not supported by the AUS. You should deploy devices configured for failover to a device or to a file.

•The AUS supports only PIX Firewall OS Version 6.2 or later. If you will be deploying configuration files using other versions or the operating system or other firewall devices, you must deploy to a file or directly to a device.

---

Caution To prevent unauthorized access to configuration files, make sure the deployment directory is a secured directory.

---

Setting a Deployment Type

---

Step 1 Select Configuration > MC Settings > Deployment.

The Deployment page appears.

Step 2 To select the method for deployment, click the appropriate radio button:

•File—Saves configuration information to a file.

---

Caution To prevent unauthorized access to configuration files, make sure the deployment directory is a secured directory.

---

•Direct to device (Default)—Downloads configuration files directly to devices.

---

Note If you deploy a PPPoE configuration to a firewall device that already has PPPoE configured on the outside interface, any existing PPPoE connection to an access concentrator is reset and cleared. The firewall device must then reconnect to the access concentrator and be reauthenticated.

---

•Auto Update Server—Downloads configuration files to an AUS for later deployment to firewalls operating in auto update mode. See Important Notes about Deploying to an AUS.

Step 3 If you are deploying to a file, enter the directory path.You can click Browse to navigate to the file location.

Step 4 To save your changes, click Apply.

---

Table 3-3 describes the elements on the Deployment page.

Table 3-3 Deployment 

Element	Description
Inherit settings check box	When selected, the subgroup or device inherits the settings of the enclosing group to the current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Enforce/Mandate settings for children check box	When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Deployment type radio buttons	Options are: •File—Saves configuration information to a file. •Direct to device (Default)—Downloads configuration files directly to devices. •Auto Update Server—Downloads configuration files to AUS for later deployment to firewalls operating in auto update mode. Note The AUS supports only firewall device operating systems 6.2 or later. If you will be deploying configuration files using other versions, you will need to deploy to a file or directly to a device.
Deployment Directory	Directory in which configuration files and configuration diffs (activity reports) are stored. You can click Browse to navigate to the location. Default directory is as shown: •For Windows 2000: c:\Program_Files\CSCOpx\MDC\PIXMC\deploy •For Solaris: /opt/CSCOpx/MDC/PIXMC/deploy Caution If you set up a different deployment directory, make sure it is a secured directory.

Configuring Import Controls

The Importing Devices feature allows you to set the import directory default. You use this directory for selecting configuration files when you import devices from a file or directory. See Chapter 7, "Defining Firewall Devices and Identifying Supporting Servers." To access this feature, select Configuration > MC Settings > Import.

---

Caution Make sure the import directory is a secured directory.

---

Setting Up an Import Directory

---

Step 1 Select Configuration > MC Settings > Import.

The Import page appears.

Step 2 The Import Control table shows the default import directory path.

If you have set up a different import directory, you can click Browse to navigate to its location.

---

Caution If you set up a different import directory, make sure it is a secured directory.

---

Step 3 To save your changes, click Apply.

---

Table 3-4 describes the elements on the Import page.

Table 3-4 Import 

Element	Description
Inherit settings check box	When selected, the subgroup or device inherits the settings of the enclosing group to the current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Enforce/Mandate settings for children check box	When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Import Directory:	Identifies default directory from which configuration files are selected when devices are imported from a file. Default directory is C:\Program_Files\CSCOpx\MDC\PIXMC\import Note You can click Browse to navigate to the location. Caution If you set up a different import directory, make sure it is a secured directory.

Configuring Feature Tracking Controls

Feature Tracking allows you to specify how Firewall MC handles commands for features that are not supported by the version of the operating system running on a specific device. Typically, unsupported features are configured at the group level and inherited by the devices within that group. To access this feature, select Configuration > MC Settings > Feature Tracking.

When an unsupported command is encountered while a configuration file is being generated, a warning can be inserted at the top of the resulting configuration file as a Beginning command. The error or warning has the following structure:

Caveat Error (or Warning): Does not support overridden (or inherited) feature, <feature name>

Setting Feature Tracking Information

---

Step 1 Select Configuration > MC Settings > Feature Tracking.

The Feature Tracking page appears.

Step 2 Determine how you want to handle commands not supported by Firewall MC, then click the appropriate radio button. Table 3-5 describes the elements on the Feature Tracking page.

Step 3 To save your changes, click Apply.

---

Table 3-5 describes the elements on the Feature Tracking page.

Table 3-5 Feature Tracking 

Element	Description
Inherit settings check box	When selected, the subgroup or device inherits the settings of the enclosing group to the current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Enforce/Mandate settings for children check box	When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Feature Tracking radio buttons	Specifies how Firewall MC should handle commands for features that are not supported by the version of the operating system running on the device: •Treat overridden features as errors and inherited features as warnings. •Treat all requested unsupported features as errors. •Treat all requested unsupported features as warnings. •Do not check if requested features are supported. If you select an option other than Do not check if requested features are supported, when an unsupported command is encountered during the generation of a configuration file, a warning is inserted at the top of the resulting configuration file as a Beginning command. The error or warning has the following structure: Caveat Error (or Warning): Does not support overridden (or inherited) feature, <feature name>

Configuring Object Grouping

The  Object Grouping feature allows you to specify how Firewall MC handles object groups during device import and configuration generation. If you are importing a device that already uses network objects or service groups, you can retain those building blocks in Firewall MC. Alternatively, you can replace the building blocks with ones already defined in Firewall MC if the settings match the needed criteria. To access this feature, select Configuration > MC Settings > Object Grouping.

Setting Object Grouping Information

---

Step 1 Select Configuration > MC Settings > Object Grouping.

The Object Grouping page appears.

Step 2 Determine how you want to handle object groups during import and generation, then make the appropriate selections. See the Object Grouping table.

Step 3 To save your changes, click Apply.

---

Table 3-6 describes the elements on the Object Grouping page.

Table 3-6 Object Grouping 

Element	Description
Inherit settings check box	When selected, the subgroup or device inherits the settings of the enclosing group to the current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Enforce/Mandate settings for children check box	When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Use Existing Groups on Import
Replace Network in rules with an existing Network Object Group containing this network only check box	When selected, reference to an individual network in rules being imported is replaced with a network object building block, if a building block containing only that network exists. For more information on network objects, see Defining Network Objects, page 10-9. Note If you select this option, you must be careful when making modifications to the network object building blocks. Making changes to these building blocks may affect a larger set of rules than anticipated.
Replace Network Group in rules with an existing Network Object Group with the same contents and name check box	When selected, reference to object groups in rules being imported is replaced with a network object building block, if a building block with the same contents and name as the object group exists. For more information on network objects, see Defining Network Objects, page 10-9.
Replace Service Group in rules with an existing Service Group with the same contents and name check box	When selected, associates a device service group to an existing Firewall MC service group with the same contents and root name. For more information on service groups, see Defining Service Groups, page 10-28.
Group Handling during Import and Generate
Group Operation:	Controls how groups are handled during device import and configuration generation. Options are: •Do not keep—Does not keep group information. Firewall MC creates a separate rule for each object referenced in the object group. •Defer to the optimization level settings— Retains groups only if the optimization settings for import or generate are set to none. •Keep (default)—Retains groups whenever possible, ignoring other settings, such as optimization. Note For versions that do not support object groups, this setting is ignored and the groups are always lost on generation.

Configuring VPN Controls

The  VPN Settings feature allows you to specify how Firewall MC handles transform sets and tunnel templates during import. Transform sets are used in the definition of IPSec tunnel templates. A transform set represents a certain combination of security protocols and algorithms. During the IPSec SA negotiation, the peers agree to use a particular transform set for protecting the data flow. IPSec tunnel templates allow you to define the tunnel policies that are used to create site-to-site and dynamic tunnels. To access this feature, select Configuration > MC Settings > VPN Settings.

Setting VPN Controls

---

Step 1 Select Configuration > MC Settings > VPN Settings.

The VPN Settings page appears.

Step 2 If the Reuse existing transform set on import check box is selected, Firewall MC replaces references to transform sets encountered during import with a transform set building block if a matching transform set exists. To turn this feature off, deselect the Reuse existing transform set on import check box.

---

Note If you select this option, you must be careful when making modifications to the IPSec transform set building blocks. Changes to these building blocks may affect a larger set of IPSec tunnel templates than anticipated.

---

Step 3 If the Reuse existing tunnel templates on import check box is selected, Firewall MC replaces references to tunnel templates encountered during import with a tunnel template building block if a matching template exists. To turn this feature off, deselect the Reuse existing tunnel templates on import check box.

---

Note If you select this option, you must be careful when making modifications to the IPSec tunnel template building blocks. Changes to these building blocks may affect a larger set of tunnels than anticipated.

---

Step 4 To save your changes, click Apply.

---

Table 3-7 describes the elements on the VPN Settings page.

Table 3-7 VPN Settings 

Element	Description
Inherit settings check box	When selected, the subgroup or device inherits the settings of the enclosing group to the current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Enforce/Mandate settings for children check box	When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?. A grayed-out check box disallows changes at the current scope.
Reuse existing transform set on import check box	When selected, references to transform sets encountered during import are replaced with a transform set building block if a matching transform set exists. This setting is enabled by default. For more information on IPSec transform sets, see Defining IPSec Transform Sets, page 10-39. Note If you select this option, you must be careful when making modifications to the IPSec transform set building blocks. Changes to these building blocks may affect a larger set of IPSec tunnel templates than anticipated.
Reuse existing tunnel templates on import check box	When selected, references to tunnel templates encountered during import are replaced with an IPSec tunnel template building block if a matching tunnel template exists. This setting is enabled by default. For more information on IPSec tunnel templates, see Defining IPSec Tunnel Templates, page 10-45. Note If you select this option, you must be careful when making modifications to the IPSec tunnel template building blocks. Changes to these building blocks may affect a larger set of tunnels than anticipated.