-
User Guide for Cisco Security Manager 3.0.1
-
Preface
-
Getting to Know Security Manager
-
Performing Administrative Tasks
-
Working With the Security Manager User Interface
-
Using Map View
-
Managing Devices
-
Managing Policies
-
Managing Activities
-
Managing Objects
-
Managing Site-to-Site VPNs
-
Managing Remote Access VPNs
-
Managing Firewall Services
-
Managing Routers
-
Managing Firewall Devices
-
Using the Catalyst 6500/7600 Device Manager
-
Managing Deployment
-
Managing FlexConfigs
-
Using Tools
-
Devices User Interface Reference
-
Site-to-Site VPN User Interface Reference
-
Policy User Interface Reference
-
Map View User Interface Reference
-
Tools User Interface Reference
-
Administrative Settings User Interface Reference
-
Activities User Interface Reference
-
Deployment User Interface Reference
-
Index
-
Table Of Contents
Understanding Factory-Default Configurations
Configuring Firewall Device Interfaces
Enabling Traffic between Interfaces with the Same Security Level
Configuring PIX 7.0/ASA Interfaces in Single Context Mode
Checklist for Configuring PIX 7.0/ASA Interfaces in Multi Context Mode
Configuring Physical Interfaces of a PIX 7.0/ASA Security Appliance in Multi Context Mode
Configuring PIX 6.3 Interfaces
Configuring NAT Policies on Firewall Devices
Configuring Translation Options
Defining Translation Exemptions (NAT 0 ACL)
Configuring Bridging Policies on Firewall Devices
Configuring Device Administration Policies on Firewall Devices
Configuring Boot Image and Configuration Settings
Configuring Contact Credentials
Configuring Device Access Settings on Firewall Devices
Configuring Resources on Firewall Services Modules
Configuring Server Access Settings on Firewall Devices
Configuring Logging Policies on Firewall Devices
Configuring Multicast Policies on Firewall Devices
Configuring Routing Policies on Firewall Devices
Configuring Security Policies on Firewall Devices
Configuring Floodguard, Anti-Spoofing, and Fragment Settings
Configuring Service Policy Rules on Firewall Devices
Configuring User Preferences on Firewall Devices
Configuring Security Contexts on Firewall Devices
Add/Edit a Security Context for PIX or ASA
Add/Edit a Security Context for FWSM
View the Contexts Defined for a Device
Managing Firewall Devices
The PIX/ASA/FWSM Platform tool supports the management and configuration of security services and policies on Adaptive Security Appliances (ASA), PIX Firewalls, and Firewall Services Modules (FWSM).
The following topics describe how to configure platform policies on firewall devices:
•
Configuring Firewall Device Interfaces
•
•
•
•
•
•
•
•
•
•
Understanding Factory-Default Configurations
Firewall devices come with certain settings already configured. After you manually add a firewall device to Security Manager or add a device from the DCR, you should discover (import) the factory-default policies for that device. Bringing these policies into Security Manager prevents you from unintentionally removing them the first time you deploy to that device. For more information about importing policies, see Discovering Policies, page 1-5.
Security Manager provides a set of configuration files that contain the factory-default policies for various device types and versions (see Table 1-1).
These configuration files are located at: <install_dir>\CSCOpx\MDC\fwtools\pixplatform
(for example, C:\Program Files\CSCOpx\MDC\fwtools\pixplatform).
Configuring Firewall Device Interfaces
The Interfaces page displays configured interfaces and subinterfaces. From this page, you can add or delete interfaces and subinterfaces and enable communication between interfaces on the same security level.
Transparent firewall mode allows only two interfaces to pass through traffic; however, if your platform includes a dedicated management interface, you can use it (either the physical interface or a sub-interface) as a third interface for management traffic.
If you intend to use a physical interface for failover, do not configure the interface in this dialog box; instead, use the Failover page (see Configuring Failover). In particular, do not set the interface name, as this parameter disqualifies the interface from being used as the failover link; other parameters are ignored.
After you assign the interface as the failover link or state link, you cannot edit or delete the interface from the Interfaces page. The only exception is if you set a physical interface to be the state link, then you can configure the speed and duplex.
Firewall devices come in a variety of configurations. The configuration determines how to define the interfaces associated with a firewall device. For more information, see Table 1-2.
Table 1-2 Interface Definition Methods by Device Type
PIX 6.3.x
N/A
N/A
PIX 7.0/ASA
Router or Transparent
Single
PIX 7.0/ASA or Security Context of unmanaged PIX 7.0/ASA
Router or Transparent
Multiple
Checklist for Configuring PIX 7.0/ASA Interfaces in Multi Context Mode
FWSM or Security Context of unmanaged Switch (multiple mode)
Router or Transparent
Single or Multiple
Enabling Traffic between Interfaces with the Same Security Level
For selected platforms, the Interfaces panel lets you enable communication between interfaces on the same security level.
By default, interfaces on the same security level cannot communicate with each other. Allowing communication between same security interfaces provides the following benefits:
•
If you use different levels for each interface and do not assign any interfaces to the same security level, you can configure only one interface per level (0 to 100).
•
Note
Procedure
Step 1
Note
Step 2
Step 3
The Interfaces page is displayed. For a description of the fields on this page, see Table A-142 on page A-261.
Step 4
•
•
•
•
Step 5
Configuring PIX 7.0/ASA Interfaces in Single Context Mode
Defining interfaces for a PIX 7.0 or ASA security appliance operating in single context, routed mode is straight forward. Configured in this mode, the security appliance simply acts as a firewall that inspects and filters traffic traversing among the networks attached to its interfaces. Interfaces attach to router-based networks, and subinterfaces attach to switch-based networks. All subinterfaces must be associated with a physical interface that is responsible for routing allowed traffic correctly.
If the security appliance is operating in transparent mode, you can only define two interfaces: inside and outside. In this mode, the interfaces do not require IP addresses; they simply use VLAN IDs to switch inspected traffic.
Procedure
Step 1
Note
Step 2
Step 3
The Interfaces page is displayed. For a description of the fields on this page, see Table A-142 on page A-261.
Step 4
The Add/Edit Interfaces dialog box appears.
Step 5
Traffic cannot traverse an interface unless it is enabled. If you are defining a sub-interface, enable the interface with which it is associated before attempting to define the sub-interface.
Step 6
By selecting this option, you are restricting the type of traffic allowed by the interface. For example, the intra- and inter-interface traffic flow selections do not apply to this interface.
Step 7
Interface represents a physical interface; whereas Sub-interface represents a logical interface associated with a previously defined physical interface.
Step 8
Specific name values are reserved for specific interfaces, in accordance with the interface naming conventions of the security appliance. As such, these reserved names enforce default, reserved security level values. Specifically, inside and outside are used to represent the internal and external network connections respectively. Also, subinterfaces typically identify their associated interface, as well as their unique name. For example, DMZoobmgmt could represent an out-of-band management network attached to the DMZ interface.
Step 9
If you are defining a sub-interface, you must select the hardware ID of the physical interface to which you want to associate the sub-interface. Otherwise, you must specify the physical_interface ID, which includes the network type, slot, and port number as type[slot/]port.
The physical interface types include the following:
•
•
For the PIX 500 series security appliance, enter the type followed by the port number, for example, ethernet0.
For the ASA 5500 series adaptive security appliance, enter the type followed by slot/port, for example, gigabitethernet0/1. Interfaces that are built into the chassis are assigned to slot 0, while interfaces on the 4GE SSM are assigned to slot 1.
The ASA 5500 series adaptive security appliance also includes the following type:
•
Step 10
•
•
•
Note
Step 11
Note
Step 12
Valid values are 300-65535 bytes. Default is 1500 for all types except PPPoE, for which the default is 1492.
Step 13
Step 14
This VLAN ID must not be in use on connected devices.
Step 15
•
•
•
Step 16
Step 17
Step 18
Step 19
You must save a new interface definition before you can begin to define another.
Related Topics
•
Checklist for Configuring PIX 7.0/ASA Interfaces in Multi Context Mode
When a firewall device uses a single security context, it appears to the network and to Security Manager as a single firewall device, just as a firewall with no support for contexts. However, when you configure a firewall device to use multiple security contexts, each security context appears, from the network perspective, as a standalone firewall device. As such, representing multiple firewalls that reside within the same physical appliance requires special care.
The following checklist describes the basic flow required to define a firewall device running multiple security contexts, describes how to configure the contexts and interfaces, and explains how to represent each context as a firewall device in Security Manager. Each step may contain multiple substeps; the steps and substeps should be performed in order. The checklist contains references to the specific procedures used to perform each task.
Step 1
This task defines the hardware ID and physical parameters of the network interfaces, such as speed, duplex, connection type (Ethernet, gigabit Ethernet, etc.), and VLAN ID associated with a sub-interface. These interfaces and sub-interfaces will be allocated to the security contexts that you define later in this checklist.
Result: All physical interfaces and sub-interfaces are defined.
For more information, see Configuring Physical Interfaces of a PIX 7.0/ASA Security Appliance in Multi Context Mode.
Step 2
This task is called out separately to ensure you define the context for the IP address through which the security appliance will be administered. It follows the same process as that for defining a security context; however, it is designated as the admin context when you select the Admin Context check box. The configuration file for the admin context must reside on the local drive, disk0:/, of the security appliance.
In addition to being used to administer the appliance, the admin context is used to publish syslog and SNMP messages to monitoring devices, such as Cisco Security Monitoring, Analysis, and Response System (CS-MARS), for further processing.
Until you define the IP address associated with the admin context, later in this checklist, the IP address used to manage the security appliance is the one that you specified when defining the device. After you define the IP address associated with the admin context, the admin context's address takes precedence over the settings on the Device Properties page, and you must modify the address associated with the admin context to change the setting.
Result: The admin context is defined and associated with a physical interface.
For more information, see:
•
Step 3
This task defines the individual firewalls, assigning a name and a location for configuration files. While the admin context can operate as a firewall device, it is typically used as such only when operating in single context mode. Therefore, the security contexts are treated separately in this checklist. Each security context represents a virtual firewall, and it identifies the interface and range of VLAN IDs associated that are under the purview of the security context.
Result: Each security context is defined and associated with a physical interface and the VLAN ranges are defined for which that security context will inspect traffic.
For more information, see:
•
Step 4
Just as you would first define the security contexts, and then define the settings for each context at the CLI, you must create the contexts on the security appliance before you can begin defining the individual settings of each context. To create the contexts on the appliance, you must define and then either submit the changes in Workflow mode or deploy the changes to the security appliance in non-Workflow mode.
After you submit the security contexts, a "virtual firewall device" appears beneath the originally defined security appliance in the Device View. These virtual firewalls have the base named of security appliance with "_context_name" appended to the base. For example, asaMultiRouted_admin would represent the admin context (named admin) of the security appliance named asaMultiRouted appliance, and asaMutliRouted_security1 would represent the security context named security1.
The IP address used to create the contexts on the security appliance is the one defined on the Device Properties dialog box of the base security appliance. To access this dialog box, right-click on the security appliance and select Device Properties. After you complete Step 5, the administrative IP will be the one assigned to the admin context.
Result: Your changes are submitted or deployed (depending on the Workflow mode), which creates the admin and security contexts as children of the base security appliance. You can now complete the definition of the interfaces by selecting a device that represents a context and editing its interfaces.
For more information, see:
•
Step 5
This task specifies the interface details, including names, addresses, and security levels, for the interfaces and sub-interfaces managed by each security context.
The difference in the approach that you take here, relative to a single context mode device, is that you select and defined settings for each security context, not the base security appliance. In addition, you cannot add new interfaces or modify the Hardware Port value, you select the interfaces that are defined and edit them within the scope of the security context.
Result: The interface settings are defined for each context.
For more information, see Configuring PIX 7.0/ASA Interfaces in Single Context Mode.
Configuring Physical Interfaces of a PIX 7.0/ASA Security Appliance in Multi Context Mode
Defining interfaces for an firewall device operating in multi context, routed, or transparent mode brings with it a level of indirection—one tied to the security contexts defined for the security appliance.
In this configuration, the appliance acts as multiple firewalls. For each security context, a unique firewall inspects and filters traffic traversing among the networks attached to the interfaces of that security context. Each context is "unaware" of other contexts defined on the same security appliance. As in single context, routed mode, interfaces attach to router-based networks, sub-interfaces attach to switch-based networks, and each sub-interface must be associated the interface that routes allowed traffic correctly. However, you cannot define IP addresses, the routed mode portion of the configuration, or identify the management only interface until you have defined and deployed the admin and security contexts. You cannot define a security context until you define one or more physical interfaces, which requires identifying the hardware ID.
This procedure is not complete; it only defines the physical interface for the base security appliance. Refer to the Checklist for Configuring PIX 7.0/ASA Interfaces in Multi Context Mode for complete instructions.
Procedure
Step 1
The Interfaces page is displayed. For a description of the fields on this page, see Table A-142 on page A-261.
Step 2
The Add/Edit Interfaces dialog box appears.
Step 3
Traffic cannot traverse an interface unless it is enabled. If you are defining a sub-interface, enable the interface with which it is associated before attempting to define the sub-interface.
Step 4
Interface represents a physical interface; whereas sub-interface represents a logical interface that is associated with a previously defined physical interface.
Step 5
If you are defining a sub-interface, you must select the hardware ID of the physical interface to which you want to associate the sub-interface. Otherwise, you must specify the physical_interface ID, which includes the network type, slot, and port number as type[slot/]port.
The physical interface types include the following:
•
•
For the PIX 500 series security appliance, enter the type followed by the port number, for example, ethernet0.
For the ASA 5500 series adaptive security appliance, enter the type followed by slot/port, for example, gigabitethernet0/1. Interfaces that are built into the chassis are assigned to slot 0, while interfaces on the 4GE SSM are assigned to slot 1.
The ASA 5500 series adaptive security appliance also includes the following type:
•
Step 6
Note
Step 7
Step 8
This VLAN ID must not be in use on connected devices.
Step 9
Step 10
Step 11
Step 12
You must save a new interface definition before you can begin to define another.
Related Topics
•
•
Configuring PIX 6.3 Interfaces
Configuring interfaces in a PIX 6.3 security appliance is straightforward because it does not support transparent mode, contexts, or sub-interfaces. You are limited to defining physical and logical interfaces. The number of each type of interface that you can define varies depending on the appliance model and license type that you purchased. For more information on the number and type of interfaces that you can define, see Table 2-6 in the Cisco PIX Firewall and VPN Configuration Guide, Version 6.3.
Note
A logical interface has only Layer 3 attributes. As a result, you can issue certain commands, such as failover link if_name or failover lan interface if_name on a physical interface that you cannot use with a logical interface. When you disable a physical interface, all the associated logical interfaces are also disabled. When you disable a logical interface, it only affects the logical interface.
Procedure
Step 1
The Interfaces page is displayed. For a description of the fields on this page, see Table A-143 on page A-266.
Step 2
The Add/Edit Interfaces page appears.
Step 3
Explicitly enable each interface you are using. All interfaces in a new PIX Firewall are shut down by default.
Step 4
By default, the lowest security interface is named outside, while the highest security interface is named inside.
Step 5
For details about the interface numbering of a specific PIX Firewall model, refer to the Cisco PIX Firewall Hardware Installation Guide, Version 6.3. If you are defining a logical interface, select the previously defined physical interfaces to which you want to associate this logical interface.
Step 6
•
•
•
Note
Step 7
Note
Step 8
Valid values are 300-65535 bytes. Default is 1500 for all types except PPPoE, for which the default is 1492.
Step 9
This VLAN ID must not be in use on connected devices.
Step 10
Step 11
•
•
•
Step 12
Step 13
Step 14
Related Topics
•
Configuring FWSM Interfaces
The FWSM does not include any external physical interfaces. Instead, it uses internal VLAN interfaces. For example, you assign VLAN 201 to the FWSM inside interface, and VLAN 200 to the outside interface. You assign these VLANs to physical switch ports, and hosts connect to those ports. When communication occurs between VLANs 201 and 200, the FWSM is the only available path between the VLANs, forcing traffic to be statefully inspected.
If the FWSM is operating in transparent mode, you can only define two interfaces: inside and outside. In this mode, the interfaces do not require IP addresses. They simply use VLAN IDs to switch the inspected traffic.
Routed mode supports up to 256 interfaces per context or in single mode, with a maximum of 1000 interfaces divided between all contexts. In this mode, each interface requires an IP address on a different subnet.
Note
Procedure
Step 1
The Interfaces page is displayed. For a description of the fields on this page, see Table A-144 on page A-271.
Step 2
The Add/Edit Interfaces page appears.
Step 3
Explicitly enable each interface you are using.
Step 4
Step 5
By default, the lowest security interface is named outside, while the highest security interface is named inside.
Step 6
Step 7
Valid values are 300-65535 bytes. Default is 1500.
Step 8
This VLAN ID must not be in use on connected devices.
Step 9
•
•
•
Step 10
Step 11
Step 12
Step 13
Related Topics
•
Troubleshooting Interfaces
Use the following information to help troubleshoot problems encountered while configuring interfaces.
Error: "Interface IP addresses defined for this device have overlap."
Conditions: Attempting to save changes made to the Interfaces page, such as manually adding an interface to a firewall device.
Description: Indicates that two or more interfaces defined in this device share an IP address on the same subnet. Each interface in the device must be attached to a different network or subnet.
Resolution: Verify that you have entered the correct IP address and subnet mask values required to identify a unique subnet for each interface.
Configuring NAT Policies on Firewall Devices
The NAT section contains pages for defining translation rules and NAT settings for firewall devices. For more information, see the following topics:
•
•
•
•
Understanding NAT
Cisco firewall devices support both the Network Address Translation feature, which provides a globally unique address for each outbound host session, and the Port Address Translation feature, which provides a single, unique global address for up to 64,000 simultaneous outbound or inbound host sessions. The global addresses used for NAT come from a pool of addresses to be used specifically for address translation. The unique global address that is used for PAT can either be one global address or the IP address of a given interface.
Cisco firewall devices can perform NAT or PAT in both inbound and outbound connections. This ability to translate inbound addresses is called Outside NAT because addresses on the outside, or less secure, interface are translated to a usable inside IP address. Outside NAT gives you the option to translate an outside host or network to an inside host or network, and it is sometimes referred to as bidirectional NAT. Just as when you translate outbound traffic with NAT, you may choose dynamic NAT, static NAT, dynamic PAT, and static PAT. If necessary, you may use outside NAT together with inside NAT to translate the both source and destination IP addresses of a packet.
Defining Address Pools
Use the Address Pools page to view, define new, or delete existing global address pools used in dynamic NAT rules.
Procedure
Step 1
•
•
The Address Pools page is displayed. For a description of the fields on this page, see Table A-127 on page A-230.
Step 2
a.
The Address Pool dialog box is displayed.
b.
c.
d.
e.
f.
Step 3
Configuring Translation Options
Use the Translation Options page to configure settings that affect network address translation for a security appliance. These settings apply to all interfaces on the device.
Procedure
Step 1
•
•
The Translation Options page is displayed. For a description of the fields on this page, see Table A-129 on page A-232.
Step 2
Note
Step 3
Step 4
Defining Translation Exemptions (NAT 0 ACL)
Use the Translation Exemptions (NAT 0 ACL) tab to specify traffic that is exempt from address translation.
Procedure
Step 1
•
•
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page A-233.
Step 2
The Translation Exemptions (NAT 0 ACL) tab displays a table containing the translation exemption rules defined for this device or shared policy. For a description of the fields on this page, see Translation Exemptions (NAT 0 ACL) Tab, page A-233.
Step 3
a.
The Add/Edit Translation Exemption (NAT-0 ACL) Rule dialog box is displayed.
b.
c.
The Add/Edit Translation Exemption (NAT-0 ACL) Rule dialog box closes and the translation exemption rule is added to the table.
Step 4
Defining Simple Dynamic Rules
With dynamic NAT, internal IP addresses are dynamically translated using IP addresses from a pool of global addresses. With dynamic PAT, internal IP addresses are translated to a single mapped address by using dynamically assigned port numbers with the mapped address. Dynamic translations are often used to map local, RFC 1918 IP addresses to addresses that are Internet-routable.
Procedure
Step 1
•
•
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page A-233.
Step 2
The Dynamic Rules tab displays a table containing the dynamic translation rules defined for this device or shared policy. For a description of the fields on this page, see Dynamic Rules Tab, page A-236.
Step 3
a.
The Add/Edit Dynamic Translation Rule dialog box is displayed.
b.
c.
The Add/Edit Dynamic Translation Rule dialog box closes and the dynamic translation rule is added to the table.
Step 4
Defining Policy Dynamic Rules
The Policy Dynamic Rules tab allows you to configure dynamic translation rules based on source and destination addresses/ports.
Procedure
Step 1
•
•
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page A-233.
Step 2
The Policy Dynamic Rules tab displays a table containing the policy dynamic translation rules defined for this device or shared policy. For a description of the fields on this page, see Policy Dynamic Rules Tab, page A-238.
Step 3
a.
The Add/Edit Policy Dynamic Rules dialog box is displayed.
b.
c.
The Add/Edit Policy Dynamic Rules dialog box closes and the policy dynamic translation rule is added to the table.
Step 4
Defining Static Rules
With static translation, internal IP addresses are permanently mapped to a global IP address. These rules map a host address on a lower security level interface to a global address on a higher security level interface. For example, a static rule would be used for mapping the local address of a web server on a perimeter network to a global address that hosts on the outside interface would use to access the web server.
Procedure
Step 1
•
•
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page A-233.
Step 2
The Static Rules tab displays a table containing the static translation rules defined for this device or shared policy. For a description of the fields on this page, see Static Rules Tab, page A-241.
Step 3
a.
The Add/Edit Static Rule dialog box is displayed.
b.
c.
The Add/Edit Static Rule dialog box closes and the static translation rule is added to the table.
Step 4
Viewing Translation Summary
You can view a summary of all translation rules defined for a device or shared policy. The summary table shows the translation rules in the order in which the rules are applied on the security appliance.
Procedure
Step 1
•
•
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page A-233.
Step 2
The General tab displays a table summarizing all translation rules in order of consideration. For a description of the fields on this page, see General Tab, page A-244.
Step 3
Configuring Bridging Policies on Firewall Devices
Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a "bump in the wire," or a "stealth firewall," and is not seen as a router hop to connected devices. The security appliance connects the same network on its inside and outside ports. Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network; IP readdressing is unnecessary.
Maintenance is facilitated because there are no complicated routing patterns to troubleshoot and no NAT configuration.
Even though transparent mode acts as a bridge, Layer 3 traffic, such as IP traffic, cannot pass through the security appliance unless you explicitly permit it with an extended access list. The only traffic allowed through the transparent firewall without an access list is ARP traffic. ARP traffic can be controlled by ARP inspection.
In routed mode, some types of traffic cannot pass through the security appliance even if you allow it in an access list. The transparent firewall, however, can allow any traffic through using either an extended access list (for IP traffic) or an EtherType access list (for non-IP traffic).
Note
For example, you can establish routing protocol adjacencies through a transparent firewall; you can allow OSPF, RIP, EIGRP, or BGP traffic through based on an extended access list. Likewise, protocols like HSRP or VRRP can pass through the security appliance.
Non-IP traffic (for example AppleTalk, IPX, BPDUs, and MPLS) can be configured to go through using an EtherType access list.
For features that are not directly supported on the transparent firewall, you can allow traffic to pass through so that upstream and downstream routers can support the functionality. For example, by using an extended access list, you can allow DHCP traffic (instead of the unsupported DHCP relay feature) or multicast traffic such as that created by IP/TV.
When the security appliance runs in transparent mode, the outgoing interface of a packet is determined by performing a MAC address lookup instead of a route lookup. Route statements can still be configured, but they only apply to security appliance-originated traffic. For example, if your syslog server is located on a remote network, you must use a static route so the security appliance can reach that subnet.
Under Bridging, you can customize your transparent firewall by adding static MAC address entries or enabling ARP inspection, for example.
Prerequisites
To change the mode from routed to transparent, access the security appliance CLI and enter the firewall transparent command (in the system execution space in multiple context mode). To change from transparent to routed, enter the no firewall transparent command.
When you change modes, the security appliance clears the configuration because many commands are not supported for both modes. If you already have a populated configuration, be sure to back up your configuration before changing the mode; you can use this backup for reference when you create your configuration.
If you download a text configuration to the security appliance that changes the mode with the firewall transparent command, be sure to put the command at the top of the configuration; the security appliance changes the mode as soon as it reads the command and then continues reading the configuration you downloaded. If the command is later in the configuration, the security appliance clears all the preceding lines in the configuration.
For more information, see Bridging, page A-274.
Bridging Support for FWSM 3.1
Although FWSM 3.1 can support multiple L2 interface pairs, Security Manager only allows you to specify no more than two L2 interfaces (a single interface pair) and one associated management IP address. That means only one bridge group with two named interfaces associated is provisioned with a management IP address. A named interface is one that is configured with the "nameif" subcommand. If the device configuration contains a maximum of one bridge group and two named interfaces, it is valid for discovery. All other scenarios result in an error message and the commands are ignored during discovery. Furthermore, discovery will not show any bridge-group information in the Security Manager user interface although the bridge-group commands will be generated during deploy. Bridge group 1 will be deployed and used in transparent rule policies if no bridge group exists in the device configuration.
Configuring Device Administration Policies on Firewall Devices
The Device Administration section contains pages for configuring device administration policies for firewall devices. For more information, see the following topics:
•
•
•
–
•
•
•
Configuring AAA
AAA enables the security appliance to determine who the user is (authentication), what the user can do (authorization), and what the user did (accounting). You can use authentication alone or with authorization and accounting. Authorization always requires a user to be authenticated first. You can use accounting alone, or with authentication and authorization.
Understanding AAA
AAA provides an extra level of protection and control for user access than using access lists alone. For example, you can create an ACL that allows all outside users to access Telnet on a server on the DMZ network. If you want only some users to access the server and you might not always know IP addresses of these users, you can enable AAA to allow only authenticated and/or authorized users to make it through the security appliance. (The Telnet server enforces authentication, too; the security appliance prevents unauthorized users from attempting to access the server.)
The following list describes the elements that make up AAA:
•
–
–
•
If you need the control that authorization provides, you can configure a broad authentication rule, and then have a detailed authorization configuration. For example, you authenticate inside users who attempt to access any server on the outside network and then limit the outside servers that a particular user can access using authorization.
The security appliance caches the first 16 authorization requests per user, so if the user accesses the same services during the current authentication session, the security appliance does not resend the request to the authorization server.
•
Preparing for AAA
AAA services depend upon the use of the LOCAL database or at least one AAA server. You can also use the LOCAL database as a fallback for most services provided by a AAA server. Before you implement AAA, you should configure the LOCAL database and configure AAA server groups and servers.
How you configure the LOCAL database and AAA servers depends upon the AAA services you want the security appliance to support. Regardless of whether you use AAA servers, you should configure the LOCAL database with user accounts that support administrative access, to prevent accidental lockouts and, if so desired, to provide a fallback method when AAA servers are unreachable. For more information, see Configuring User Accounts.
Table 1-3 provides a summary of AAA service support by each AAA server type and by the LOCAL database. You manage the LOCAL database by configuring user profiles on the Platform > Device Admin > User Accounts page (see Configuring User Accounts). You establish AAA server groups and add individual AAA servers to the server groups using the Platform > Device Admin > AAA page.
Table 1-3 Summary of AAA Support
VPN users
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes1
Firewall sessions
Yes
Yes
Yes
No
No
No
No
No
Administrators
Yes
Yes
Yes
No
No
No
No
No
VPN users
Yes
Yes
No
No
No
No
Yes
No
Firewall sessions
No
Yes2
Yes
No
No
No
No
No
Administrators
Yes3
No
Yes
No
No
No
No
No
VPN connections
No
Yes
Yes
No
No
No
No
No
Firewall sessions
No
Yes
Yes
No
No
No
No
No
Administrators
No
Yes
Yes
No
No
No
No
No
1 HTTP Form protocol supports single-sign on authentication for WebVPN users only.
2 For firewall sessions, RADIUS authorization is supported with user-specific ACLs only, which are received or specified in a RADIUS authentication response.
3 Local command authorization is supported by privilege level only.
LOCAL Database
The security appliance maintains a local database that you can populate with user profiles.
•
•
AAA for Device Administration
You can authenticate all administrative connections to the security appliance, including:
•
•
•
•
•
You can also authenticate administrators who attempt to enter enable mode. You can authorize administrative commands. You can have accounting data for administrative sessions and for commands issued during a session sent to an accounting server.
You can configure AAA for device administration using the Platform > Device Admin > AAA page (see Defining AAA Policies).
AAA for Network Access
You can configure rules for authenticating, authorizing, and accounting for traffic passing through the firewall by using the Firewall > AAA Rules page (see Working with AAA Rules, page 1-81). The rules you create are similar to access rules, except that they specify whether to authenticate, authorize, or perform accounting for the traffic defined; and which AAA server group the security applianceis to use to process the AAA service request.
AAA for VPN Access
AAA services for VPN access include the following:
•
•
•
Defining AAA Policies
Use the following procedure to define the AAA settings for a device or shared policy.
Procedure
Step 1
•
•
The AAA page is displayed. For a description of the fields on this page, see AAA Page, page A-284.
Step 2
Step 3
a.
b.
c.
Step 4
a.
b.
c.
Step 5
Step 6
Step 7
Step 8
a.
b.
c.
Step 9
Step 10
a.
b.
Step 11
a.
b.
Step 12
a.
b.
c.
Step 13
Related Topics
Configuring Banners
You can use the Banner page to specify the Session (exec), Login, and Message-of-the-Day (motd) banners for a firewall device or shared policy.
If you use the tokens $(hostname) or $(domain), they are replaced with the hostname and domain name of the security appliance. When you enter the $(system) token in a context configuration, the context uses the banner configured in the system configuration.
Spaces in the text are preserved; however, tabs cannot be entered. Multiple lines in a banner are handled by entering a line of text for each line you wish to add. Each line is then appended to the end of the existing banner. If the text is empty, then a carriage return (CR) will be added to the banner.
There is no limit on the length of a banner other than RAM and Flash memory limits. You can only use ASCII characters, including new line (the Enter key, which counts as two characters). When accessing the security appliance through Telnet or SSH, the session closes if there is not enough system memory available to process the banner messages or if a TCP write error occurs when attempting to display the banner messages.
Procedure
Step 1
•
•
The Banner page is displayed. For a description of the fields on this page, see Table A-157 on page A-290.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Related Topics
Configuring Boot Image and Configuration Settings
Boot Image/Configuration lets you choose which image file a security appliance running PIX 7.x or later will boot from, as well as which configuration file it will use at startup.
You can specify up to four local binary image files for use as the startup image, and one image located on a TFTP server for the device to boot from. If you specify an image located on a TFTP server, it must be first in the list. In the event the device cannot reach the tftp server to load the image from, it will attempt to load the next image file in the list located in Flash.
If you do not specify any boot variable, the first valid image on internal flash will be chosen to boot the system.
Procedure
Step 1
•
•
The Boot Image/Configuration page is displayed. For a description of the fields on this page, see Table A-158 on page A-292.
Step 2
Step 3
Step 4
•
•
•
Step 5
Step 6
Step 7
Related Topics
•
Configuring Clock Settings
The Clock page lets you manually set the date and time for the security appliance.
Note
To dynamically set the time using an NTP server, see Configuring NTP Settings; time derived from an NTP server overrides any time set manually on the Clock page.
Procedure
Step 1
•
•
The Clock page is displayed. For a description of the fields on this page, see Table A-160 on page A-295.
Step 2
Step 3
Step 4
a.
b.
c.
d.
e.
Step 5
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
Step 6
Related Topics
Configuring Contact Credentials
You can use the Contact Credentials page to specify the future contact settings that Security Manager should use when contacting a device. You can also use the Contact Credentials page to change the login password and the enable password on a device.
The login password lets you access EXEC mode if you connect to the security appliance using a Telnet or SSH session. (If you configure user authentication for Telnet or SSH access, then each user has their own password, and this login password is not used.)
The enable password lets you access privileged EXEC mode after you log in. (If you configure user authentication for enable access, then each user has their own password, and this enable password is not used.)
Procedure
Step 1
•
•
The Contact Credentials page is displayed. For a description of the fields on this page, see Table A-161 on page A-297.
Step 2
a.
The Username and Password fields become enabled.
b.
c.
d.
e.
Step 3
a.
The Enable Password fields become enabled.
b.
c.
Step 4
a.
The Telnet Password fields become enabled.
b.
c.
Step 5
Related Topics
•
Configuring Device Access Settings on Firewall Devices
The Device Access section contains pages for defining access to firewall devices. For more information, see the following topics:
•
Configuring Console Timeout
You can use the Console page to specify the timeout settings for a console session. The firewall device uses the console timeout setting to close inactive sessions.
Procedure
Step 1
•
•
The Console page is displayed. For a description of the fields on this page, see Table A-162 on page A-299.
Step 2
Step 3
Related Topics
Configuring HTTP
The HTTP page provides a table that specifies the addresses of all the hosts or networks that are allowed access to the firewall device using HTTPS. You can use this table to add or change the hosts or networks that are allowed access.
The HTTP page also displays information about HTTP redirection and HTTPS user certificate requirements for interfaces on the firewall device. You can use this table to change the entries for HTTP redirection and HTTPS user certificate requirements.
Procedure
Step 1
•
•
The HTTP page is displayed. For a description of the fields on this page, see Table A-163 on page A-300.
Step 2
•
•
•
Step 3
Step 4
Note
Step 5
Step 6
Step 7
Step 8
Related Topics
Configuring ICMP
The ICMP page provides a table that lists the ICMP rules, which specify the addresses of all hosts or networks that are allowed or denied ICMP access to the firewall device. You can use this table to add or change the hosts or networks that are allowed or prevented from sending ICMP messages to the firewall device.
The ICMP rule list controls ICMP traffic that terminates on any firewall device interface. If no ICMP control list is configured, the firewall device accepts all ICMP traffic that terminates at any interface, including the outside interface. However, by default, the firewall device does not respond to ICMP echo requests directed to a broadcast address.
It is recommended that permission is always granted for the ICMP unreachable message type (type 3). Denying ICMP unreachable messages disables ICMP Path MTU discovery, which can halt IPSec and PPTP traffic. See RFC 1195 and RFC 1435 for details about Path MTU Discovery.
If an ICMP control list is configured, the firewall device uses a first match to the ICMP traffic followed by an implicit deny all. That is, if the first matched entry is a permit entry, the ICMP packet continues to be processed. If the first matched entry is a deny entry or an entry is not matched, the firewall device discards the ICMP packet and generates a syslog message. An exception is when an ICMP control list is not configured; in that case, a permit statement is assumed.
Procedure
Step 1
•
•
The ICMP page is displayed. For a description of the fields on this page, see Table A-165 on page A-302.
Step 2
•
•
•
Step 3
Step 4
Step 5
Step 6
Note
Step 7
Step 8
Related Topics
Configuring Management Access
You can use the Management Access page to specify an interface on a firewall device that permits management access connections. Enabling this feature on an internal interface allows PIX management functions to be performed on the interface over an IPSec VPN tunnel. You can enable the Management Access feature on only one interface at a time.
Procedure
Step 1
•
•
The Management Access page is displayed. For a description of the fields on this page, see Table A-167 on page A-305.
Step 2
Step 3
Related Topics
•
Configuring Secure Shell
The Secure Shell page lets you configure rules that permit only specific hosts or networks to connect to a firewall device for administrative access using the SSH protocol. The rules restrict SSH access to a specific IP address and netmask. SSH connection attempts that comply with the rules must then be authenticated by a AAA server or the Telnet password.
Procedure
Step 1
•
•
The Secure Shell page is displayed. For a description of the fields on this page, see Table A-168 on page A-306.
Step 2
Step 3
Step 4
•
•
•
Step 5
Step 6
Note
Step 7
Step 8
Step 9
Related Topics
•
Configuring SNMP
Simple Network Management Protocol (SNMP) defines a standard way for network management stations running on PCs or workstations to monitor the health and status of many types of devices, including switches, routers, and the security appliance. You can use the SNMP page to configure a firewall device for monitoring by SNMP management stations.
SNMP Terminology
•
•
•
•
•
SNMP
For Cisco MIB files and OIDs, refer to: http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml. OIDs may be downloaded at this URL: ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz.
SNMP CPU Utilization
Cisco firewall devices support monitoring CPU utilization through SNMP. This feature allows network administrators to monitor firewall device CPU usage using SNMP management software, such as HP OpenView, for capacity planning.
This functionality is implemented through support for the cpmCPUTotalTable of the Cisco Process MIB (CISCO-PROCESS-MIB.my). The other two tables in the MIB, cpmProcessTable and cpmProcessExtTable, are not supported in this release.
Each row of the cpmCPUTotalTable includes the index of each CPU and the following objects:
Note
The values of the last three elements are the same as the output from the show cpu usage command.
The security appliance does not support the following new MIB objects in the cpmCPUTotalTable:
•
•
•
Procedure
Step 1
•
•
The SNMP page is displayed. For a description of the fields on this page, see Table A-170 on page A-308.
Step 2
Step 3
Step 4
Step 5
a.
b.
c.
Step 6
•
•
•
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
•
•
Step 13
Step 14
Related Topics
Configuring Telnet
The Telnet page lets you configure rules that permit only specific hosts or networks to connect to the firewall device using the Telnet protocol.
The rules restrict administrative Telnet access through a firewall device interface to a specific IP address and netmask. Connection attempts that comply with the rules must then be authenticated by a preconfigured AAA server or the Telnet password. You can monitor Telnet sessions using Monitoring > Telnet Sessions.
Note
Procedure
Step 1
•
•
The Telnet page is displayed. For a description of the fields on this page, see Table A-173 on page A-314.
Step 2
Step 3
•
•
•
Step 4
Step 5
Note
Step 6
Related Topics
•
Configuring Failover
The Failover page contains the settings for configuring failover on the security appliance. However, the Failover page changes depending upon the type of device and whether you are in multiple mode or single mode, and when you are in multiple mode, it changes based on the security context you are in.
How you configure failover depends upon both the security context and the firewall mode of the security appliance.
In single mode, you only use Active/Standby failover. All failover configuration occurs in the Failover panel and associated sub-tabs. However, the Interfaces tab varies between routed firewall mode and transparent firewall mode.
Note
In multiple mode, you can configure Active/Standby or Active/Active failover. In both types of failover, you need to provide system-level failover settings in the system context, and context-level failover settings in the individual security contexts. Additionally, the security context failover interface settings vary between routed firewall mode and transparent firewall mode.
Related Topics
•
Understanding Failover
Failover allows you to configure two security appliances so that one will take over operation if the other fails. Using a pair of security appliances, you can provide high availability with no operator intervention. The security appliance communicates failover information over a dedicated failover link. This failover link can be either a LAN-based connection or, on the PIX security appliance platform, a dedicated serial failover cable. The following information is communicated over the failover link:
•
•
•
•
•
Caution
The security appliance supports two types of failover: Active/Standby and Active/Active. Additionally, failover can be stateful or stateless. For more information about the types of failover, refer to the following topics:
Active/Standby Failover
In an Active/Standby configuration, the active security appliance handles all network traffic passing through the failover pair. The standby security appliance does not handle network traffic until a failure occurs on the active security appliance. Whenever the configuration of the active security appliance changes, it sends configuration information over the failover link to the standby security appliance.
When a failover occurs, the standby security appliance becomes the active unit. It assumes the IP and MAC addresses of the previously active unit. Because the other devices on the network do not see any changes in the IP or MAC addresses, ARP entries do not change or time out anywhere on the network.
Active/Standby failover is available to security appliances in single mode or multiple mode.
Note
Active/Active Failover
In an Active/Active failover configuration, both security appliances pass network traffic. Active/Active failover is only available to security appliances in multiple context mode.
Note
To enable Active/Active failover on the security appliance, you need to create failover groups. If you enable failover without creating failover groups, you are enabling Active/Standby failover. A failover group is a logical group of one or more security contexts. You can create two failover groups on the security appliance. You should create the failover groups on the unit that will have failover group 1 in the active state. The admin context is always a member of failover group 1. Any unassigned security contexts are also members of failover group 1 by default.
As in Active/Standby failover, each unit in an Active/Active failover pair is given a primary or secondary designation. Unlike Active/Standby failover, this designation does not indicate which unit is active when both units start simultaneously. Each failover group in the configuration is given a primary or secondary role preference. This preference determines on which unit in the failover pair the contexts in the failover group appear in the active state when both units start simultaneously. You can have both failover groups be in the active state on a single unit in the pair, with the other unit containing the failover groups in the standby state. However, a more typical configuration is to assign each failover group a different role preference to make each one active on a different unit, balancing the traffic across the devices.
Initial configuration synchronization occurs when one or both units start. This synchronization occurs as follows:
•
•
After both units are running, commands are replicated from one unit to the other as follows:
•
Note
•
•
Failure to enter the commands on the appropriate unit for command replication to occur will cause the configurations to be out of synchronization. Those changes may be lost the next time the initial configuration synchronization occurs.
Note
In an Active/Active failover configuration, failover occurs on a failover group basis, not a system basis. For example, if you designate both failover groups as active on the primary unit, and failover group 1 fails, failover group 2 remains active on the primary unit, while failover group 1 becomes active on the secondary unit.
Note
Stateless (Regular) Failover
Stateless failover is also referred to as regular failover. In stateless failover, all active connections are dropped when a failover occurs. Clients need to reestablish connections when the new active unit takes over.
Stateful Failover
When stateful failover is enabled, the active unit in the failover pair continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.
Note
To use stateful failover, you must configure a state link to pass all state information to the standby unit. If you are using a LAN failover connection rather than the serial failover interface (available on the PIX security appliance platform only), you can use the same interface for the state link as the failover link. However, it is recommended that you use a dedicated interface for passing state information the standby unit.
The following information is passed to the standby unit when stateful failover is enabled:
•
•
•
•
•
•
The following information is not copied to the standby unit when stateful failover is enabled:
•
•
•
•
Configuring Hostname Settings
Use the Hostname policy to enter a hostname and domain name to be used by the firewall device after the configuration file is deployed.
When you set a hostname for the security appliance, that name appears in the command line prompt. If you establish sessions to multiple devices, the hostname helps you keep track of where you enter commands. The default hostname depends on your platform.
For multiple context mode, the hostname that you set in the system execution space appears in the command line prompt for all contexts. The hostname that you optionally set within a context does not appear in the command line, but can be used by the banner command $(hostname) token.
The firewall device appends the domain name as a suffix to unqualified names. For example, if you set the domain name to "example.com," and specify a syslog server by the unqualified name of "jupiter," the security appliance qualifies the name to "jupiter.example.com."
For multiple context mode, you can set the domain name for each context, as well as within the system execution space.
Procedure
Step 1
Step 2
The Hostname page is displayed. For a description of the fields on this page, see Table A-186 on page A-339.
Step 3
Note
Step 4
Step 5
Related Topics
Configuring Resources on Firewall Services Modules
Use the Resources page to view configured classes and information about each class. You can also use the Resources page to add, edit, or delete a class.
Procedure
Step 1
Step 2
The Resources page is displayed. For a description of the fields on this page, see Resources Page, page A-339.
Step 3
Configuring Server Access Settings on Firewall Devices
The Server Access section contains pages for configuring server access on firewall devices. For more information, see the following topics:
Configuring AUS Settings
The AUS page lets you configure a firewall device to be managed remotely from a server that supports the Auto Update specification. Auto Update lets you apply configuration changes to the firewall device and receive software updates from a remote location.
Auto Update is useful in solving many challenges facing administrators for security appliance management:
•
•
•
•
•
•
•
Procedure
Step 1
•
•
The AUS page is displayed. For a description of the fields on this page, see Table A-189 on page A-345.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
a.
b.
c.
d.
e.
Step 11
a.
b.
Step 12
Related Topics
Configuring DHCP Relay
Use the DHCP Relay page to configure DHCP relay services on a firewall device. DHCP relay passes DHCP requests received on one interface to an external DHCP server located behind a different interface. To configure DHCP relay, you need to specify at least one DHCP relay server and then enable a DHCP relay agent on the interface receiving DHCP requests.
Note
•
Procedure
Step 1
•
•
The DHCP Relay page is displayed. For a description of the fields on this page, see Table A-190 on page A-347.
Step 2
a.
The Configure DHCP Relay Agent Parameters dialog box appears.
b.
c.
d.
e.
The Configure DHCP Relay Agent Parameters dialog box closes and the interface is added to the DHCP Relay Agent table.
Step 3
a.
The Configure DHCP Relay Server Parameters dialog box appears.
b.
c.
d.
The Configure DHCP Relay Server Parameters dialog box closes and the server is added to the DHCP Relay Servers table.
Step 4
Step 5
Related Topics
Configuring DHCP Servers
A Dynamic Host Configuration Protocol (DHCP) server provides network configuration parameters, such as IP addresses, to DHCP clients. The security appliance can provide a DHCP server or DHCP relay services to DHCP clients attached to security appliance interfaces. The DHCP server provides network configuration parameters directly to DHCP clients. DHCP relay passes DHCP requests received on one interface to an external DHCP server located behind a different interface. For more information about DHCP relay, see Configuring DHCP Relay.
Note
In multiple context mode, you cannot enable the DHCP server or DHCP relay on an interface that is used by more than one context.You can configure a DHCP server on each interface of the security appliance. Each interface can have its own pool of addresses to draw from. However, the other DHCP settings, such as DNS servers, domain name, options, ping timeout, and WINS servers, are configured globally and used by the DHCP server on all interfaces.
You cannot configure a DHCP client or DHCP relay services on an interface on which the DHCP server is enabled. Additionally, DHCP clients must be directly connected to the interface on which the server is enabled.
If your firewall is also acting as a DHCP client on the outside interface, you can enable auto-negotiated IP configuration. This allows the firewall to pass the DNS, WINS, and domain name parameters it gets from the outside interface (as a DHCP client) to hosts on its inside network. Alternatively, you can manually specify the DNS, WINS, and domain name parameters. If you specify those parameters manually and auto-configuration is on, your values take precedence over auto-configuration.
Procedure
Step 1
•
•
The DHCP Server page is displayed. For a description of the fields on this page, see Table A-193 on page A-351.
Step 2
a.
The Edit DHCP Server dialog box appears.
b.
c.
d.
e.
The Edit DHCP Server dialog box closes and the interface for which you enabled the DHCP server is added to the table.
Step 3
Step 4
Step 5
Step 6
a.
b.
c.
d.
e.
Step 7
Related Topics
Configuring DNS
The DNS page lets you specify one or more DNS servers for a firewall device so it can resolve server names to IP addresses in your WebVPN configuration or certificate configuration. Other features that define server names (such as AAA) do not support DNS resolution. You must enter the IP address or manually resolve the name to an IP address by adding the server name in the Hosts/Networks panel.
Procedure
Step 1
•
•
The DNS page is displayed. For a description of the fields on this page, see Table A-196 on page A-355.
Step 2
a.
The Add DNS Server Group dialog box appears.
b.
c.
–
The Add DNS Server dialog box appears.
–
–
The Add DNS Server dialog box closes and the server is added to the list.
d.
e.
f.
g.
The Add DNS Server Group dialog box closes and the server group is added to the DNS Server Groups table.
Step 3
a.
The Edit Interfaces dialog box appears.
b.
c.
The Edit Interfaces dialog box closes and the specified interfaces are added to the DNS Lookup Interfaces list.
Step 4
Note
Step 5
Related Topics
Configuring NTP Settings
NTP is used to implement a hierarchical system of servers that provide a precisely synchronized time among network systems. This kind of accuracy is required for time-sensitive operations, such as validating CRLs, which include a precise time stamp. You can configure multiple NTP servers. The firewall device chooses the server with the lowest stratum—a measure of how reliable the data is.
Use the NTP page to define NTP servers to dynamically set the time on a firewall device.
Note
Procedure
Step 1
•
•
The NTP page is displayed. For a description of the fields on this page, see Table A-200 on page A-360.
Step 2
a.
The NTP Server Configuration dialog box appears.
b.
c.
d.
e.
–
–
–
f.
The NTP Server Configuration dialog box closes and the server is added to the table.
Step 3
Related Topics
Configuring SMTP Servers
Use the SMTP Server page to specify the IP address of an SMTP server and, optionally, the IP address of a backup server.
Procedure
Step 1
•
•
The SMTP Server page is displayed. For a description of the fields on this page, see Table A-202 on page A-363.
Step 2
Step 3
Step 4
Related Topics
Configuring TFTP Servers
TFTP is a simple client/server file transfer protocol described in RFC783 and RFC1350 Rev. 2. You can use the TFTP Server page to configure a firewall device to propagate its configuration files to a server using the Trivial File Transfer Protocol (TFTP). Only one server is supported.
This page allows you to specify the gateway interface, the IP address of the TFTP server, and the path and filename to which the configuration file will be written.
Procedure
Step 1
•
•
The TFTP Server page is displayed. For a description of the fields on this page, see Table A-203 on page A-364.
Step 2
Step 3
Step 4
Example TFTP server path: /tftpboot/config/test_config
Note
Step 5
Related Topics
Configuring User Accounts
The User Accounts page lets you manage the local user database. The local database is used for the following features:
•
By default, you can log in to ASDM with a blank username and the enable password. However, if you enter a username and password at the login screen (instead of leaving the username blank), ASDM checks the local database for a match.
Note
•
•
•
•
If you enable command authorization using the local database, the security appliance refers to the user privilege level to determine what commands are available. Otherwise, the privilege level is not generally used. By default, all commands are either privilege level 0 or level 15.
Note
•
•
You cannot use the local database for network access authorization.
For multiple context mode, you can configure usernames in the system execution space to provide individual logins at the CLI using the login command; however, you cannot configure any aaa commands that use the local database in the system execution space.
Note
Procedure
Step 1
•
•
The User Accounts page is displayed. For a description of the fields on this page, see Table A-204 on page A-365.
Step 2
a.
The Add User Account dialog box appears.
b.
c.
d.
e.
The Add User Account dialog box closes and the user is added to the User Accounts list.
Step 3
Related Topics
•
Configuring Logging Policies on Firewall Devices
The Logging feature lets you enable logging, set up logging parameters, configure event lists (syslog filters), apply the filters to a destination, set up syslog messages, configure syslog servers, and specify e-mail notification parameters.
Once you have enabled logging and set up the logging parameters using the Logging Setup page, the Event Lists page lets you configure filters (of a set of syslog messages) which can be sent to a logging destination. The Logging Filters page lets you specify a logging destination for the syslog messages to be sent. Finally, the Syslog and E-Mail pages configure syslog and e-mail setup.
The Logging section contains pages for defining the following settings for firewall devices:
•
Configuring E-Mail Setup
The E-Mail Setup (PIX 7.0/ASA Only) page lets you set up a source e-mail address as well as a list of recipients for specified syslog messages to be sent as e-mails. You can filter the syslog messages sent to a destination e-mail address by severity. The table shows which entries have been set up.
The syslog severity filter used for the destination e-mail address will be the higher of the severity selected in this section and the global filter set for all e-mail recipients in the Logging Filters page.
Procedure
Step 1
The E-Mail Setup page appears.
Step 2
Step 3
•
•
The Add/Edit Email Recipient dialog box appears.
Step 4
Step 5
Step 6
The recipient rule appears in the table on the E-Mail setup page.
Step 7
Related Topics
•
•
Configuring Event Lists
The Event Lists (PIX 7.0/ASA Only) page lets you define a set of syslog messages to filter for logging. Once you have enabled logging and set up the logging parameters using the Logging Setup page, the Event Lists page lets you configure filters (of a set of syslog messages) which can be sent to a logging destination. The Logging Filters page lets you specify a logging destination for event lists.
You can use three criteria to define an event list:
•
•
•
The class associates related syslog messages so you do not have to select the syslog messages individually. For example, the auth class lets you select all the syslog messages that are related to user authentication.
Severity defines syslog messages based on the relative importance of the event in the normal functioning of the network. The highest severity is Emergency, which means the resource is no longer available. The lowest severity is Debugging, which provides detailed information about every network event.
The message ID is a numeric value that uniquely identifies each message. You can use the message ID in an event list to identify a range of syslog messages, such as 101001-101010.
Procedure
Step 1
The Events Lists page appears.
Step 2
•
•
The Add/Edit Event List dialog box appears.
Step 3
Step 4
a.
b.
c.
Step 5
Step 6
a.
These values and their corresponding messages are identified in the System Log Message guides for the appropriate product. You can access these guides from the following URLs:
PIX Firewall
–
ASA
–
FWSM
–
b.
Step 7
Step 8
The event list appears in the table on the Event List page.
Step 9
Related Topics
•
Configuring Logging Filters
The Logging Filters page lets you configure a logging destination for event lists (syslog filters) that have been configured using the Event Lists page, or for only the syslog messages that you specify using the Edit Logging Filters page. Syslog messages from specific or all event classes can be selected using the Edit Logging Filters page.
Procedure
Step 1
The Logging Filters page appears.
Step 2
•
•
The Edit Logging Filters dialog box appears.
Step 3
Step 4
•
Severity levels are aggregate; they add events to lower severity levels. This list organizes from sparse to detailed in ascending order.
•
•
Step 5
The custom event level appears in the list.
Step 6
Step 7
The logging filter rule appears in the table.
Step 8
Related Topics
•
Configuring Logging Setup
The Logging Setup page lets you enable system logging on the security appliance and configure other logging options. These options include enabling logging on the security appliance and failover unit, specifying the base log format and detail, logging to longer-term storage devices, FTP server or flash, before purging the internal buffer.
Procedure
Step 1
The Logging Setup page appears.
Step 2
This option enables logging on the security appliance.
Step 3
Step 4
If you enable EMBLEM, you must use the UDP protocol to publish syslog messages. It is not compatible with TCP.
Step 5
a.
b.
c.
d.
e.
Step 6
a.
b.
c.
Step 7
Step 8
Related Topics
•
Configuring Rate Limit Levels
The Rate Limit (FWSM Only) page allows you to specify the maximum number of log messages of a particular type (for example, alert or critical) that should be generated within a given period of time. You can specify a limit for each logging level or syslog message ID. If the settings differ, syslog message ID limits are recognized.
Using the Add/Edit Rate Limited Syslog Message dialog box you can specify the maximum number of log messages of a particular Syslog ID that should be generated within a given period of time. A limit can be specified for each syslog message ID or logging level (see Add/Edit Rate Limit for Syslog Logging Levels Dialog Box, page A-381). If the settings differ, the syslog message ID limits are recognized. To access this feature, select Platform > Logging > Rate Limit (FWSM Only).
Note
A limit can be specified for each logging level or syslog message ID. If the settings differ, the rate limited syslog ID-level settings override rate limit logging level settings.
Procedure
Step 1
The Rate Limit page appears.
Step 2
•
•
Step 3
Step 4
Step 5
The rule appears in the corresponding table.
Step 6
Related Topics
•
•
Configuring Server Setup
The Server Setup page allows you to configure the syslog server that runs on the security appliance. The settings that you specify on this page define the possible behaviors of the specific syslog server instance on the security appliance. You can set the facility code to include in syslog messages, include timestamp in syslog, view syslog ID levels, modify syslog ID levels, and suppress syslog messages.
To generate meaningful reports about the network activity of a security appliance and to monitor the security events associated with that device, you must select the appropriate logging level. The logging level generates the syslog details required to track session-specific data. After you select a logging level, you can define a syslog rule that directs traffic to a third-party syslog server or CS-MARS.
Procedure
Step 1
The Server Setup page appears.
Step 2
Step 3
Step 4
•
•
•
Step 5
•
•
The Add/Edit Syslog Message dialog box appears.
Step 6
Step 7
Step 8
Step 9
The rule appears in the table.
Step 10
Related Topics
•
Defining Syslog Servers
The Syslog Servers page lets you specify the syslog servers to which the security appliance will send syslog messages. To make use of the syslog server(s) you define, you must enable logging using the Logging Setup page and set up the appropriate filters for destinations using the Logging Filters page.
Note
By directing syslog records generated by a security appliance to a syslog server, you can process and study the records.
Before You Begin
Enable logging. See the Configuring Logging Setup.
Procedure
Step 1
The Syslog Servers page appears.
Step 2
•
•
Step 3
The list displays all interfaces defined at the current scope.
Step 4
Step 5
Step 6
•
•
Step 7
To enable this option, you must select UDP protocol to publish messages to this syslog server.
Step 8
The definition appears in the Syslog Servers table.
Step 9
Related Topics
•
•
Configuring Multicast Policies on Firewall Devices
The Multicast section contains pages for defining multicast routing settings for firewall devices. For more information, see the following topics:
Enabling Multicast Routing
The Enable Multicast Routing page lets you enable multicast routing on the security appliance. Enabling multicast routing enables Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM) on all interfaces by default. IGMP is used to learn whether members of a group are present on directly attached subnets. Hosts join multicast groups by sending IGMP report messages. PIM is used to maintain forwarding tables to forward multicast datagrams.
Procedure
Step 1
•
•
The Enable Multicast Routing page is displayed. For a description of the fields on this page, see Table A-224 on page A-391.
Step 2
Step 3
Related Topics
•
Configuring IGMP
IP hosts use IGMP to report their group memberships to directly connected multicast routers. IGMP uses group address (Class D IP addresses). Host group addresses can be in the range 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is never assigned to any group. The address 224.0.0.1 is assigned to all systems on a subnet. The address 224.0.0.2 is assigned to all routers on a subnet.
For more information about configuring IGMP on the security appliance, see the following:
Protocol
The Protocol tab displays the IGMP parameters for each interface on the security appliance. From this tab, you can disable IGMP and change IGMP parameters for an interface. For more information, see Protocol Tab, page A-392.
Access Group
Access groups control restrict the multicast groups that are allowed on an interface. From the Access Group tab, you can add a new access group to the Access Group Table or change information for an existing access group entry. Some fields may be locked when editing existing entries. For more information, see Access Group Tab, page A-395.
Static Group
Sometimes, hosts on a network may have a configuration that prevents them from answering IGMP queries. However, you still want multicast traffic to be forwarded to that network segment. There are two methods to pull multicast traffic down to a network segment:
•
•
From the Static Group tab, you can statically assign a multicast group to an interface or change existing static group assignments. For more information, see Static Group Tab, page A-397.
Join Group
You can configure the security appliance to be a member of a multicast group. The Join Group tab displays the multicast groups of which the security appliance is a member.
Note
From the Join Group tab, you can configure an interface to be a member of a multicast group or change existing membership information. For more information, see Join Group Tab, page A-399.
Configuring Multicast Routes
Defining static multicast routes lets you separate multicast traffic from unicast traffic. For example, when a path between a source and destination does not support multicast routing, the solution is to configure two multicast devices with a GRE tunnel between them and to send the multicast packets over the tunnel.
Static multicast routes are local to the security appliance and are not advertised or redistributed. For more information, see Multicast Routing Page, page A-401.
Procedure
Step 1
•
•
The Multicast Routing page is displayed. For a description of the fields on this page, see Table A-233 on page A-401.
Step 2
The Add/Edit MRoute Configuration dialog box is displayed.
Step 3
Step 4
Related Topics
•
•
Configuring PIM
Routers use Protocol Independent Multicast (PIM) to maintaining forwarding tables for forwarding multicast datagrams.
When you enable multicast routing on the security appliance, PIM is enabled on all interfaces by default. You can disable PIM on a per-interface basis.
For more information about configuring PIM, see the following:
Protocol
The Protocol tab displays the interface-specific PIM properties. From this tab, you can you change the PIM properties for an interface. For more information, see Protocol Tab, page A-404.
Rendezvous Points
When you configure PIM, you must choose one or more routers to operate as the rendezvous point (RP). An RP is a single, common root of a shared distribution tree and is statically configured on each router. First hop routers use the RP to send register packets on behalf of the source multicast hosts.
You can configure a single RP to serve more than one group. If a specific group is not specified, the RP for the group is applied to the entire IP multicast group range (224.0.0.0/4).
You can configure more than one RP, but you cannot have more than one entry with the same RP. For more information, see Rendezvous Points Tab, page A-406.
Route Tree
By default, PIM leaf routers join the shortest-path tree immediately after the first packet arrives from a new source. This reduces delay, but requires more memory than shared tree.
You can configure whether the security appliance should join shortest-path tree or use shared tree, either for all multicast groups or only for specific multicast addresses. For more information, see Route Tree Tab, page A-410.
Request Filter
When the security appliance is acting as an RP, you can restrict specific multicast sources from registering with it. This prevents unauthorized sources from registering with the RP. The Request Filter panel lets you define the multicast sources from which the security appliance will accept PIM register messages. For more information, see Request Filter Tab, page A-413.
Configuring Routing Policies on Firewall Devices
The Routing section contains pages for defining routing settings for firewall devices. For more information, see the following topics:
Configuring No Proxy ARP
The No Proxy ARP page allows you to disable proxy ARP for global addresses.
When a host sends IP traffic to another device on the same Ethernet network, the host needs to know the MAC address of the device. ARP is a Layer 2 protocol that resolves an IP address to a MAC address. A host sends an ARP request asking "Who is this IP address?" The device owning the IP address replies, "I own that IP address; here is my MAC address."
Proxy ARP is when a device responds to an ARP request with its own MAC address, even though the device does not own the IP address. The security appliance uses proxy ARP when you configure NAT and specify a global address that is on the same network as the security appliance interface. The only way traffic can reach the hosts is if the security appliance uses proxy ARP to claim that the security appliance MAC address is assigned to destination global addresses.
Procedure
Step 1
•
•
The No Proxy ARP page is displayed. For a description of the fields on this page, see Table A-244 on page A-418.
Step 2
The Edit Interfaces dialog box is displayed.
Step 3
Tip
Step 4
Configuring OSPF
OSPF is an interior gateway routing protocol that uses link states rather than distance vectors for path selection. OSPF propagates link-state advertisements (LSAs) rather than routing table updates. Because only LSAs are exchanged, rather than entire routing tables, OSPF networks converge more quickly than RIP networks.
OSPF supports MD5 and clear text neighbor authentication. Authentication should be used with all routing protocols when possible because route redistribution between OSPF and other protocols (like RIP) can potentially be used by attackers to subvert routing information.
If NAT is used, if OSPF is operating on public and private areas, and if address filtering is required, then you need to run two OSPF processes—one process for the public areas and one for the private areas.
A router that has interfaces in multiple areas is called an Area Border Router (ABR). A router that acts as a gateway to redistribute traffic between routers using OSPF and routers using other routing protocols is called an Autonomous System Boundary Router (ASBR).
An ABR uses LSAs to send information about available routes to other OSPF routers. Using ABR type 3 LSA filtering, you can have separate private and public areas with the security appliance acting as an ABR. Type 3 LSAs (inter-area routes) can be filtered from one area to other. This lets you use NAT and OSPF together without advertising private networks.
Note
If NAT is employed but OSPF is only running in public areas, routes to public networks can be redistributed inside the private network, either as default or type 5 AS External LSAs. However, you need to configure static routes for the private networks protected by the security appliance. Also, you should not mix public and private networks on the same security appliance interface.
Procedure
Step 1
•
•
The OSPF page is displayed. For a description of the fields on this page, see OSPF Page, page A-419.
Step 2
Configuring RIP
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection. When RIP is enabled on an interface, the interface exchanges RIP broadcasts with neighboring devices to dynamically learn about and advertise routes.
The security appliance support both RIP version 1 and RIP version 2. RIP version 1 does not send the subnet mask with the routing update. RIP version 2 sends the subnet mask with the routing update and supports variable-length subnet masks. Additionally, RIP version 2 supports neighbor authentication when routing updates are exchanged. This authentication ensures that the security appliance receives reliable routing information from a trusted source.
Note
Limitations
RIP has the following limitations:
•
•
•
•
RIP Version 2 Notes
The following information applies to RIP Version 2 only:
•
•
•
Procedure
Step 1
•
•
The RIP page is displayed. For a description of the fields on this page, see Table A-265 on page A-455.
Step 2
Configuring Static Routes
The Static Route page lets you create static routes that will access networks connected to a router on any interface. To enter a default route, set the IP address and mask to 0.0.0.0, or the shortened form of 0.
If an IP address from one of the security appliance's interfaces is used as the gateway IP address, the security appliance will resolve the designated IP address in the packet instead of resolving the gateway IP address.
Leave the Metric to the default of 1 unless you are sure of the number of hops to the gateway router.
Procedure
Step 1
•
•
The Static Route page is displayed. For a description of the fields on this page, see Table A-267 on page A-459.
Step 2
Configuring Security Policies on Firewall Devices
You can configure the following security policies for firewall devices:
•
Configuring Floodguard, Anti-Spoofing, and Fragment Settings
Use the General page under Security to enable Floodguard on a firewall device, to enable Unicast Reverse Path Forwarding (anti-spoofing) on an interface, and to configure IP fragment settings for a security appliance or for each interface of the security appliance.
Floodguard
Floodguard lets you reclaim firewall resources if the user authentication subsystem runs out of resources. If an inbound or outbound uauth connection is being attacked or overused, the firewall will actively reclaim TCP user resources.
If the user authentication subsystem is depleted, TCP user resources in different states are reclaimed depending on urgency in the following order:
1.
2.
3.
4.
5.
The floodguard command is enabled by default.
Anti-Spoofing
Unicast RPF guards against IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table.
Normally, the security appliance only looks at the destination address when determining where to forward the packet. Unicast RPF instructs the security appliance to also look at the source address; this is why it is called Reverse Path Forwarding. For any traffic that you want to allow through the security appliance, the security appliance routing table must include a route back to the source address. See RFC 2267 for more information.
For outside traffic, for example, the security appliance can use the default route to satisfy the Unicast RPF protection. If traffic enters from an outside interface, and the source address is not known to the routing table, the security appliance uses the default route to correctly identify the outside interface as the source interface.
If traffic enters the outside interface from an address that is known to the routing table, but is associated with the inside interface, the security appliance drops the packet. Similarly, if traffic enters the inside interface from an unknown source address, the security appliance drops the packet because the matching route (the default route) indicates the outside interface.
Unicast RPF is implemented as follows:
•
•
Fragment Settings
Fragment settings provide additional management of packet fragmentation and improve compatibility with the Network File System (NFS).
Procedure
Step 1
•
•
The General page is displayed. For a description of the fields on this page, see Table A-269 on page A-462.
Step 2
Step 3
a.
b.
c.
d.
Step 4
a.
The Add/Edit Anti-Spoofing and Fragment Interface Configuration dialog box appears.
b.
c.
d.
•
•
•
e.
The Add/Edit Anti-Spoofing and Fragment Interface Configuration dialog box closes and the interface is added to the table.
Step 5
Related Topics
Configuring Timeouts
The Timeouts page lets you set the timeout durations for use with the security appliance. All durations are displayed in the format hh:mm:ss. It sets the idle time for the connection and translation slots of various protocols. If the slot has not been used for the idle time specified, the resource is returned to the free pool. TCP connection slots are freed approximately 60 seconds after a normal connection close sequence.
Note
Procedure
Step 1
•
•
The Timeouts page is displayed. For a description of the fields on this page, see Table A-271 on page A-466.
Step 2
Step 3
Related Topics
Configuring Service Policy Rules on Firewall Devices
Some applications require special handling by the security appliance and specific application inspection engines are provided for this purpose. Applications that require special application inspection engines are those that embed IP addressing information in the user data packet or open secondary channels on dynamically assigned ports. Application inspection is enabled by default for many protocols, while it is disabled for other protocols. In many cases, you can change the port on which the application inspection listens for traffic.
Application inspection engines work with NAT to help identify the location of embedded addressing information. This allows NAT to translate these embedded addresses and to update any checksum or other fields that are affected by the translation.
Service policy rules define how specific types of application inspection are applied to different types of traffic that is received by the security appliance. You apply a specific rule to an interface or globally to every interface.
Use traffic match criteria to define the set of traffic to which you want to apply application inspection. For example, TCP traffic with a port value of 23 might be classified as the Telnet traffic class. You can use the traffic class to change the default port for application inspection for protocols where this is permitted.
Multiple traffic match criteria can be assigned to a single interface, but a packet will only match the first criteria within a specific service policy rule.
Service policy rules provide a way to configure security appliance features in a manner similar to Cisco IOS software QoS CLI. For example, with service policy rules you can include IP Precedence as one of the criteria to identify traffic for rate-limiting. You can also create a timeout configuration that is specific to a particular TCP application, as opposed to one that applies to all TCP applications.
Service policy rules are supported with these features:
•
•
•
•
Configuring Service Policy Rules consists of three tasks:
Step 1
Step 2
Step 3
Configuring User Preferences on Firewall Devices
Use the User Preferences policy to specify deployment options for specific firewall devices. You can create a policy with the deployment options you want to use and then apply that policy to all devices that you want using those deployment settings.
Procedure
Step 1
•
•
The Deployment page is displayed. For a description of the fields on this page, see Table A-277 on page A-476.
Step 2
Note
However, clearing the translation table disconnects all current connections that use translations.Step 3
Configuring Security Contexts on Firewall Devices
You can partition a single security appliance into multiple virtual devices, known as security contexts. Each context is an independent device, with its own security policy, interfaces, and administrators. Multiple contexts are similar to having multiple standalone devices. Many features are supported in multiple context mode, including routing tables, firewall features, IPS, and management. Some features are not supported—VPN, multicast, and dynamic routing protocols. Security contexts support only static routes. You cannot enable OSPF or RIP in multiple context mode. Also, some features are not directly managed by Security Manager, such as the IPS feature set in ASA and PIX.
In multiple context mode, the security appliance includes a configuration for each context that identifies the security policy, interfaces, and almost all the options you can configure on a standalone device. The system administrator adds and manages contexts by configuring them in the system configuration, which, like a single mode configuration, is the startup configuration. The system configuration identifies basic settings for the security appliance. The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context. The system configuration is used to add, delete, and edit basic context settings, including allocating network interfaces to the various contexts.
The admin context is just like any other context, except that when a user logs in to the admin context, that user has system administrator rights and can access the system configuration and all other contexts.
This section contains the following topics:
•
•
•
•
Add/Edit a Security Context for PIX or ASA
Use the following procedure to define security contexts for a security appliance. At least one security context must be designated as the admin context.
Before You Begin
Before you can configure contexts using Security Manager, you must make sure the security appliance is in multiple context mode. When manually defining a device, select Multi in the Contexts list under Operating System in the New Device - Device Information dialog box.
Procedure
Step 1
The Security Contexts page is displayed. For a description of the fields on this page, see Table A-278 on page A-477.
Step 2
The Add Security Context dialog box appears.
Step 3
Step 4
Step 5
Step 6
a.
The Allocate Interfaces dialog box appears.
b.
You can select just a physical interface, a single sub-interface (defined as a range of one), or a range of sub-interfaces.
c.
d.
Select this option to see physical interface properties in the show interface command in the security context even if you set a mapped name. If not selected, it only shows the mapped name.
e.
Step 7
A message box states that the context will appear as a standalone device after you perform the Submit operation.
Step 8
Related Topics
•
•
•
•
Add/Edit a Security Context for FWSM
Use the following procedure to define security contexts for an FWSM. At least one security context must be designated as the admin context.
Before You Begin
Before you can configure contexts using Security Manager, you must make sure the security appliance is in multiple context mode. When manually defining a device, select Multi in the Contexts list under Operating System in the New Device - Device Information dialog box.
Procedure
Step 1
The Security Contexts page is displayed. For a description of the fields on this page, see Table A-278 on page A-477.
Step 2
The Add Security Context dialog box appears.
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
A message box states that the context will appear as a standalone device after you perform the Submit operation.
Step 9
Related Topics
•
•
•
•
Delete a Security Context
When you delete a security context, you are deleting all settings and policy references associated with that security context.
Procedure
Step 1
The Security Contexts page is displayed. For a description of the fields on this page, see Table A-278 on page A-477.
Step 2
The Confirm Delete dialog box appears.
Step 3
Note
Step 4
Step 5
Related Topics
•
•
•
•
Enabling Multi-Context Mode
Security Manager does not support enabling multiple context mode on a device. To perform this task, you must delete the device from Security Manager, enable multiple context mode using ASDM or CVDM, and then add the device again to Security Manager. After the device is added as operating in multiple context mode, you can add, edit, or delete security contexts.
Related Topics
•
•
•
•
Restoring Single Context Mode
Security Manager does not support restoring a device to single context mode. To perform this task, you must delete the device and any of its child contexts from Security Manager, restore the single context using ASDM or CVDM, and then add the device again to Security Manager.
Related Topics
•
•
•
View the Contexts Defined for a Device
You can view the contexts that are defined for a device in one of three ways:
•
•
•
Tip
Related Topics
•
•
•
