-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics describe configuration and management of security services and policies on Cisco security devices: Adaptive Security Appliances (ASAs), PIX Firewalls, and Firewall Services Modules (FWSMs) on Catalyst 6500 series switches:
•Default Firewall Configurations
•Configuring Firewall Device Interfaces
•Configuring NAT Policies on Firewall Devices
•Configuring Bridging Policies on Firewall Devices
•Configuring Device Administration Policies 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 Service Policy Rules on Firewall Devices
•Configuring User Preferences on Firewall Devices
•Configuring Security Contexts on Firewall Devices
Firewall devices are shipped with certain settings already configured. When you manually add a newly installed firewall device to Cisco Security Manager, you should discover (import) the pre-set or default policies for that device. Importing these policies into Security Manager prevents them being unintentionally removed the first time you deploy a configuration to that device. For more information about importing policies, see Discovering Policies, page 6-11.
Cisco Security Manager provides a set of configuration files that contain default policies for a number of device types and versions. These configuration files are located in the directory: <install_dir>\CSCOpx\MDC\fwtools\pixplatform\ (for example, C:\Program Files\CSCOpx\MDC\fwtools\pixplatform\
).
The file name indicates device type, operating system version, context support, and operation type. For example, "FactoryDefault_FWSM2_2_MR.cfg" is the configuration file for an FWSM, version 2.2, with support for Multiple contexts, operating in Routed mode. Similarly, "FactoryDefault_ASA7_0_1_ST.cfg" is the configuration file for an ASA, version 7.0.1, in Single-context, Transparent mode.
Refer to Interfaces in Single and Multiple Contexts for more about security contexts, and Interfaces in Routed and Transparent Modes for more about routed and transparent operation.
See Adding Devices from Configuration Files, page 5-10 for information about adding new devices from the supplied configuration files.
The Interfaces page displays configured interfaces, subinterfaces and redundant interfaces for the selected device. From this page, you can add, edit and delete interfaces, subinterfaces and redundant interfaces; enable communication between interfaces on the same security level; and manage VPDN groups and PPPoE users, as described in the following sections.
•Understanding Device Interfaces
–Interfaces in Routed and Transparent Modes
–Interfaces in Single and Multiple Contexts
–Using the Add/Edit Interface Dialog Box
–Device Interface: IP Type (PIX/ASA)
–Device Interface: IP Type (PIX 6.3)
–Device Interface: MAC Address
–Understanding ASA 5505 Ports and Interfaces
•Advanced Device Interface Configuration
–Enabling Traffic between Interfaces with the Same Security Level
–Managing the PPPoE Users List
An interface is a point of connection between a security device and some other network device. Interfaces are initially disabled; thus, as an essential part of firewall configuration, interfaces must be enabled and configured to allow appropriate packet inspection and forwarding.
There are two types of interface: physical and logical, where a physical interface is the actual slot on the device into which a network cable is plugged, and a logical interface is a virtual port assigned to a specific physical port. Generally, physical ports are referred to as "interfaces," while logical ports are referred to as "subinterfaces." The number and type of interfaces you can define varies with appliance model and type of license purchased.
Note On devices running version 6.3 of the PIX operating system, the labels "physical" and "logical" are used, rather than "interface" and "subinterface." Also, transparent mode and multiple contexts are not supported on these devices.
Subinterfaces let you divide a physical interface into multiple logical interfaces that are tagged with different VLAN IDs. Because VLANs keep traffic separate on a given physical interface, you can increase the number of interfaces available to your network without adding additional physical interfaces or security appliances. This feature is particularly useful in multiple-context mode, allowing you to assign unique interfaces to each context.
As a general rule, 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.
Note If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. The physical interface must be enabled for the subinterface to pass traffic, but do not name the physical interface to ensure it does not pass traffic. However, if you do want to let the physical interface pass untagged packets, you can name the interface as usual. (See Using the Add/Edit Interface Dialog Box for information about naming an interface.)
The FWSM does not include any external physical interfaces—instead, it uses internal VLAN interfaces. For example, assume 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.
See the following sections for additional information about device interfaces:
•Interfaces in Routed and Transparent Modes
•Interfaces in Single and Multiple Contexts
Note The ASA 5505, combining switch and security appliance features, is a special case in that you configure both physical switch ports and logical VLAN interfaces. See Understanding ASA 5505 Ports and Interfaces for more information.
Firewall devices come in a variety of configurations, and the configuration determines how to define the interfaces associated with a specific device. The following table outlines the various configurations.
|
(Router or Transparent) |
(Single or Multiple) |
---|---|---|
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 (see Checklist for Configuring Multiple Security Contexts) |
FWSM, or security context of unmanaged switch (multiple mode) |
Router or Transparent |
Single or Multiple |
Beginning with Security Manager 3.2.2, you can define logical "redundant" interfaces to increase security appliance reliability. A redundant interface is a specific pair of physical interfaces, with one designated as active (or primary) and the other as standby (or secondary). When the active interface fails, the standby interface becomes active and starts passing traffic. This feature is separate from device-level failover, but you can configure redundant interfaces as well as failover, if desired. You can configure up to eight redundant interface pairs.
A redundant interface functions as a single interface (inside, outside, etc.), with only one of the member pair active at any one time. This redundant interface is configured normally, with a unique interface name, security level and IP address. Note that each member interface must be of the same type (e.g., GigabitEthernet), and cannot have a name, security level, or IP address assigned. In fact, do not configure any options other than Duplex and Speed on the member interfaces.
The redundant interface uses the MAC address of the first physical interface that you add. If you change the order of the member interfaces in the configuration, then the MAC address changes to match the MAC address of the interface that is now listed first. Alternatively, you can explicitly assign a MAC address to the redundant interface; this address is then used regardless of the member interface MAC addresses. In either case, when the active interface fails over to the standby, the same MAC address is maintained so that traffic is not disrupted.
Beginning with ASA/PIX 7.0 and FWSM 2.2.1, you can configure a security device to operate in one of two modes: routed or transparent. (The PIX 6.3 operates only in routed mode.)
In routed mode, the security appliance acts as a gateway or router for connected networks: it maintains IP addresses for its interfaces, and inspects and filters traffic traversing these interfaces based on IP address (Layer 3) information. In this mode, each device interface is connected to a different IP subnet, and has its own IP address on that subnet. Routed mode supports up to 256 interfaces in single mode or per context, with a maximum of 1000 interfaces divided between all contexts.
In transparent mode, the security appliance operates as a Layer 2 (data link) device, or transparent bridge, and is often referred to as a "bump in the wire," or a "stealth firewall." In this mode, you can define only two interfaces: inside and outside. The interfaces do not require IP addresses; they use VLAN IDs to forward inspected traffic. (However, if your platform includes a dedicated management interface, you can use it—either the physical interface or a subinterface—as a third interface for device-management traffic.)
Note Cisco Security Manager does not populate the interface information for FWSM 2.x devices during discovery.
Security "contexts" allow a single physical device to operate as multiple, independent firewalls. In multiple-context mode, each context defines a single virtual firewall, complete with its own configuration. Each context acts as a unique virtual firewall that inspects and filters traffic traversing the interfaces allocated to that context. Each context is "unaware" of other contexts defined on the same security appliance.
As with a single-context, routed-mode device, interfaces on a multiple-context device connect to router-based networks, subinterfaces connect to switch-based networks, and each subinterface must be associated with an interface that routes allowed traffic correctly.
However, you cannot define IP addresses, the routed-mode portion of the configuration, or identify the management interface until you have defined and deployed the contexts. But you cannot define a security context until you have defined the necessary interfaces and subinterfaces.
In other words, you must enable and configure the interfaces and subinterfaces on a device that will provide multiple security contexts (in either routed or transparent mode) before you can define and configure the security contexts themselves.
Refer to Configuring Security Contexts on Firewall Devices for more information.
The ASA 5505 is unique in that it includes a built-in switch, and there are two kinds of ports and interfaces that you need to configure:
•Physical switch ports—The ASA 5505 has eight Fast Ethernet switch ports that forward traffic at Layer 2, using the switching function in hardware. Two of these ports are power-over-Ethernet (PoE) ports. You can connect these ports directly to user equipment such as PCs, IP phones, or DSL modems. Or you can connect to another switch.
•Logical VLAN interfaces—In routed mode, these interfaces forward traffic between VLAN networks at Layer 3, using the configured security policy to apply firewall and VPN services. In transparent mode, these interfaces forward traffic between the VLANs on the same network at Layer 2, using the configured security policy to apply firewall services.
To segregate the switch ports into separate VLANs, you assign each switch port to a VLAN interface. Switch ports on the same VLAN can communicate with each other using hardware switching. But when a switch port on one VLAN attempts to communicate with a switch port on another VLAN, the ASA 5505 applies the security policy to the traffic, and routes or bridges between the two VLANs.
Note Subinterfaces are not available on the ASA 5505.
For more information, see ASA 5505 Ports and Interfaces Page, page K-45.
The Interfaces page displays configured interfaces, subinterfaces and redundant interfaces for the selected device. Each security device must be configured, and each active interface must be enabled. Inactive interfaces can be disabled. When disabled, the interface does not transmit or receive data, but its configuration information is retained.
If you bootstrapped a new firewall device, the set-up feature configures only the addresses and names associated with the inside interface. You must define the remaining interfaces on that device before you can specify access and translation rules for traffic traversing that security device.
Follow these steps to manage security-device interfaces. You can add, edit and delete configured interfaces, subinterfaces and redundant interfaces, and also enable communication between interfaces with the same security level.
Step 1 Ensure Device View is your present application view; if necessary, click the Device View button on the toolbar.
Note For more information on using the Device View to configure device policies, see Managing Policies in Device View, page 6-19).
Step 2 Select the appliance you want to configure.
Step 3 Select Interfaces in the Device Policy selector.
The Interfaces page is displayed. For a description of the fields on this page, see Interfaces Page: PIX and ASA, page K-23.
Step 4 Add, edit and delete interfaces, as necessary:
•To define a new interface, click the Add Row button at the bottom of the Interfaces page to open the Add/Edit Interface dialog box (see Using the Add/Edit Interface Dialog Box).
•To edit an existing interface, select the desired entry in the Interfaces list and then click the Edit Row button at the bottom of the Interfaces page to open the Add/Edit Interface dialog box (see Using the Add/Edit Interface Dialog Box).
•To delete an existing interface, select the desired entry in the list and then click the Delete Row button. A confirmation dialog box may appear; click OK to delete the interface.
Step 5 Click Save at the bottom of the window to save your interface definitions to the Cisco Security Manager server.
This section describes using the Add/Edit Interface dialog box to configure security-device interfaces. Some of the parameters presented in this dialog box vary according to device type and version, operational mode (routed versus transparent), and whether the device hosts a single or multiple contexts. Thus, some of the following descriptions might not exactly mirror the device you are configuring. However, the basic configuration steps are the same, and links to additional information for specific devices are provided. In addition, you can refer to the reference page, Add/Edit Interface Dialog Box, page K-25, for descriptions of all parameters found in the various versions of the Add/Edit Interface dialog box.
The ASA 5505, combining switch and security appliance features, is a special case in that you configure both physical switch ports and logical VLAN interfaces. See Understanding ASA 5505 Ports and Interfaces for more information.
Note If you intend to use a physical interface for failover, you can define that interface in this dialog box but do not configure it; instead, use the Failover page (see Configuring Failover). In particular, do not specify an interface Name, as this parameter disqualifies the interface from being used as the failover link.
To define and configure an interface, subinterface, or redundant interface, follow these steps:
Step 1 Open the Add/Edit Interface dialog box, as described in Managing Device Interfaces.
Step 2 Select Enable Interface to enable the interface. Deselect this option to disable the interface but preserve its definition.
Traffic cannot traverse an interface, a related subinterface, or a redundant interface if the interface is not enabled. If you are defining a subinterface, enable the interface it will be associated with before defining the subinterface. If you are defining a redundant interface, enable the member interfaces before defining the redundant interface.
Step 3 Select Management Only to reserve this interface for device administration. Only traffic for management of this device is accepted; pass-through traffic for other interfaces and devices is rejected.
Step 4 Select Redundant Interface to configure two physical interfaces as a single logical "redundant" interface. (See About Redundant Interfaces for more information.)
When Redundant Interface is checked, the Type option is disabled, the Hardware Port, Duplex and Speed options disappear, and the Redundant ID, Primary Interface and Secondary Interface options appear.
Provide an identifier for this redundant interface; valid IDs are the integers from 1 to 8. Choose the Primary Interface from the list of available interfaces. Similarly, choose the Secondary Interface from the related list.
Step 5 Choose the type of interface you are defining from the Type list:
Interface represents a physical interface, whereas Subinterface represents a logical interface (or VLAN connection) associated with a previously defined physical interface.
Subinterfaces let you divide a physical interface into multiple logical interfaces that are tagged with different VLAN IDs. Because VLANs keep traffic separate on a given physical interface, you can increase the number of interfaces available to your network without adding additional physical interfaces or security appliances. This feature is particularly useful in multiple-context mode, letting you assign unique interfaces to each context.
Note If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. Because the physical interface must be enabled for the subinterface to pass traffic, do not name the physical interface to ensure it does not pass traffic. However, if you want to let the physical interface pass untagged packets, you can name the interface as usual.
Step 6 (Optional) Provide an identifier of up to 48 characters for this interface in the Name field.
Certain names 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 levels. Specifically, inside and outside are used to represent the internal, highest-security connection, and the external, lowest-security network connection respectively.
Also, a subinterface name typically identifies its associated interface, in addition to its own unique identifier. For example, DMZoobmgmt could represent an out-of-band management network attached to the DMZ interface.
Again, do not name the interface if you intend to use it for failover or as a member of a redundant interface. See Configuring Failover and About Redundant Interfaces for more information.
Step 7 Specify the Hardware Port used by this interface.
If you are defining an interface, enter a physical port ID, which includes network type, slot and port number, in the form: type[slot/]port. If you are defining a subinterface, you can simply choose the desired Hardware Port from a list of previously defined ports (you must also supply a VLAN ID).
The network type specified for the physical interface can be either Ethernet or GigabitEthernet; on the ASA 5580, TenGigabitEthernet is also available. Note that this field provides automatic pattern matching: if you begin typing with the letter e, "Ethernet" is inserted into the field. Similarly, typing the letter g produces "GigabitEthernet."
For a PIX 500 series security appliance, enter the type and port number; for example, ethernet0. For details about the interface numbering for a specific PIX Firewall model, refer to the Cisco PIX Firewall Hardware Installation Guide, Version 6.3.
For an ASA 5500 series appliance, enter the type and a slot/port pair; for example, gigabitethernet0/1. Ports that are built into the chassis are assigned to slot 0, while ports on the 4GE SSM are assigned to slot 1.
The ASA 5500 series appliances also include a management interface type. The management interface is a Fast Ethernet interface designed for device-management traffic only, and is specified as management0/0. You can, however, use this physical interface for through traffic if desired (be sure the Management Only option is not selected). Thus, in transparent firewall mode, you can use the management interface in addition to the two interfaces allowed for through traffic. You can also add subinterfaces to the management interface to provide management in each security context in multiple-context mode.
Step 8 (Subinterfaces only) Provide an identifier for this subinterface: enter an integer between 1 and 4294967295 in the Subinterface ID field.
For subinterface port identification, this ID is appended to the chosen Hardware Port. For example, GigabitEthernet0.4 represents the subinterface assigned an ID of 4, operating on the port GigabitEthernet0.
Step 9 (ASA slot/port interfaces only) Select the Media Type: RJ45 (copper) or SFP (fiber); SFP is required for 10-Gigabit Ethernet cards.
Step 10 (Interfaces only) Choose the appropriate options for Duplex and Speed. Note that the Speed and Duplex options are intended primarily for copper-based interfaces.
On a PIX 6.3 device, Speed and Duplex settings are combined; the options are auto, 10baset, 10full, 100basetx, 100full, aui, and bnc.
Note We strongly recommend you use the auto setting for both parameters, letting the security appliance automatically select the correct speed and duplex settings. If you specify a fixed setting for either and then change it later, the interface will shut down.
Also, to avoid duplex mismatch, be sure the remote interface linked to this interface is configured with the same settings.
Step 11 Specify the maximum packet size in bytes in the MTU (Maximum Transmission Unit) field.
Valid values are 300 to 65535. The default is 1500 for all IP types except PPPoE, for which the default is 1492. See Device Interface: IP Type (PIX/ASA) and Device Interface: IP Type (PIX 6.3) for information about IP types.
Step 12 (Subinterfaces only) Specify a VLAN ID for this subinterface: enter a value between 1 and 4094 (4096 for FWSM) in the VLAN ID field. The specified VLAN ID must not be in use on any connected device.
Step 13 (PIX only) Specify the interface security level: enter a number between 0 (least secure) and 100 (most secure) in the Security Level field.
•The outside interface is always 0.
•The inside interface is always 100.
•DMZ interfaces are between 1 and 99.
Step 14 (Optional) You can enter a Description for this interface of up to 240 characters (on one line; i.e., no carriage returns).
Step 15 Other Add/Edit Interface dialog box sections are:
•Device Interface: IP Type (PIX/ASA) or Device Interface: IP Type (PIX 6.3)
•Device Interface: MAC Address
•Bridge Groups - A bridge group is a pair of VLAN interfaces, along with a management IP address, connecting the same network on an FWSM (3.1 or later) operating in transparent mode. The Add/Edit Interface dialog box opened for such an FWSM contains a read-only Bridge Group field that lists the group to which the interface is assigned. See Add/Edit Bridge Group Dialog Box, page K-44 for information about defining Bridge groups.
•Roles - All interface roles assigned to this interface are listed in this field. Role assignments are based on pattern matching between the Name given to this interface and all currently defined Interface Role objects in Cisco Security Manager. Refer to Understanding Interface Role Objects, page 8-33 for more information.
Step 16 Click OK to close the Add/Edit Interface dialog box and enable the interface.
A security device operating in single-context, routed mode requires IP addressing for its interfaces; firewall interfaces do not have IP addresses until you assign them. (In multiple-context mode, interface IP addresses are set in the context configuration.) Note that in transparent mode, the device acts as an access-control bridge (a "bump in the wire")—you assign different VLANs to each interface, but IP addressing is not necessary.
The Add/Edit Interface dialog box presented for a security device in single-context, routed mode includes the section IP Type, where you specify the type of IP addressing for the interface and provide related parameters, as described here. See Using the Add/Edit Interface Dialog Box for information about the other sections of the dialog box.
Note The IP Type section of the Add/Edit Interface dialog box for PIX 6.3 devices is described in Device Interface: IP Type (PIX 6.3).
Step 1 In the Add/Edit Interface dialog box, choose a method for address assignment from the IP Type list, and then provide related parameters:
•Static IP - Provide a static IP Address and Subnet Mask that represents the security device on this interface's connected network. If you omit the Subnet Mask value, a "classful" network is assumed, as follows:
–The Class A netmask (255.0.0.0) is assumed if the first octet of the IP Address is 1 through 126 (i.e., addresses 1.0.0.0 through 126.255.255.255).
–The Class B netmask (255.255.0.0) is assumed if the first octet of the IP Address is 128 through 191 (i.e., addresses 128.0.0.0 through 191.255.255.255).
–The Class C netmask (255.255.255.0) is assumed if the first octet of the IP Address is 192 through 223 (i.e., addresses 192.0.0.0 through 223.255.255.255).
•Use DHCP - Enables Dynamic Host Configuration Protocol (DHCP) for automatic assignment of an IP address from a DHCP server on the connected network. The following options become available:
–DHCP Learned Route Metric (required) - Assign an administrative distance to the learned route. Valid values are 1 to 255. If this field is blank, the administrative distance for learned routes defaults to 1.
–Obtain Default Route using DHCP - Check this box to obtain a default route from the DHCP server so that you do not need to configure a default static route.
–Enable Tracking for DHCP Learned Route - If Obtain Default Route using DHCP is checked, you can check this box to enable route tracking via a specific Service Level Agreement (SLA) monitor. The following options become available:
–Tracked SLA Monitor - Required if Enable Tracking for DHCP Learned Route is selected. Provide the name of the SLA Monitor object to be used for route tracking. You can use the Select button to select from a list of available SLA monitors. (Refer to Monitoring Service Level Agreements (SLAs) To Maintain Connectivity, page 8-77 for more information.)
•PPPoE (PIX and ASA 7.2+) - Enables PPPoE for automatic assignment of an IP address of an IP address from a PPPoE server on the connected network; not supported with failover.
–VPDN Group Name (required) - Virtual Private Dialup Network (VPDN) group that contains the authentication method and user name/password to use for network connection, negotiation and authentication. See Managing VPDN Groups for more information.
–IP Address - If provided, this static IP address is used for connection and authentication, instead of a negotiated address.
–Subnet Mask - The subnet mask to be used in conjunction with the provided IP Address.
–PPPoE Learned Route Metric (required) - Assign an administrative distance to the learned route. Valid values are 1 to 255. If this field is blank, the administrative distance for learned routes defaults to 1.
–Obtain Default Route using PPPoE - Check this box to obtain a default route from the PPPoE server; sets the default routes when the PPPoE client has not yet established a connection. When using this option, you cannot have a statically defined route in the configuration.
–Enable Tracking for PPPoE Learned Route - If Obtain Default Route using PPPoE is selected, you can select this option to enable route tracking for PPPoE-learned routes. The following options become available:
–Dual ISP Interface - If you are defining interfaces for dual ISP support, choose Primary or Secondary to indicate which connection you are configuring.
–Tracked SLA Monitor - Required if Enable Tracking for DHCP Learned Route is selected. Provide the name of the SLA Monitor object to be used for route tracking. You can use the Select button to select from a list of available SLA monitors. (Refer to Monitoring Service Level Agreements (SLAs) To Maintain Connectivity, page 8-77 for more information.)
Note You can configure DHCP and PPPoE only on the outside interface of a firewall device. If you have already configured PPPoE on the outside interface, it is no longer available as an option.
A PIX version 6.3 security device requires IP addressing for its interfaces; firewall interfaces do not have IP addresses until you assign them.
Note The IP Type options presented for other security appliances are described in Device Interface: IP Type (PIX/ASA).
The Add/Edit Interface dialog box presented for a PIX 6.3 security device includes the section IP Type, where you specify the type of IP addressing for the interface and provide related parameters, as described here. See Using the Add/Edit Interface Dialog Box for information about the other sections of the dialog box.
Step 1 In the Add/Edit Interface dialog box, choose a method for address assignment from the IP Type list, and then provide related parameters:
•Static IP - Provide a static IP Address and Subnet Mask that represents the security device on this interface's connected network. If you omit the Subnet Mask value, a "classful" network is assumed, as follows:
–The Class A netmask (255.0.0.0) is assumed if the first octet of the IP Address is 1 through 126 (i.e., addresses 1.0.0.0 through 126.255.255.255).
–The Class B netmask (255.255.0.0) is assumed if the first octet of the IP Address is 128 through 191 (i.e., addresses 128.0.0.0 through 191.255.255.255).
–The Class C netmask (255.255.255.0) is assumed if the first octet of the IP Address is 192 through 223 (i.e., addresses 192.0.0.0 through 223.255.255.255).
•Use DHCP - Enables Dynamic Host Configuration Protocol (DHCP) for automatic assignment of an IP address from a DHCP server on the connected network. The following options become available:
–Obtain Default Route using DHCP - Check this box to obtain a default route from the DHCP server so that you do not need to configure a default static route.
–Retry Count - The number of times the PIX will resend the DHCP request. Valid values are 4 to 16; the default is four.
•PPPoE (PIX and ASA 7.2+) - Enables PPPoE for automatic assignment of an IP address of an IP address from a PPPoE server on the connected network; not supported with failover.
–IP Address - If provided, this static IP address is used for connection and authentication, instead of a negotiated address.
–Subnet Mask - The subnet mask to be used in conjunction with the provided IP Address.
–Obtain Default Route using PPPoE - Check this box to obtain a default route from the PPPoE server; sets the default routes when the PPPoE client has not yet established a connection. When using this option, you cannot have a statically defined route in the configuration.
–Retry Count - The number of times the PIX will resend the PPPoE request. Valid values are 4 to 16; the default is four.
Note You can configure DHCP and PPPoE only on the outside interface of a firewall device. If you have already configured PPPoE on the outside interface, it is no longer available as an option.
By default, a physical interface uses its burned-in MAC address, and all subinterfaces of a physical interface use the same burned-in MAC address. A redundant interface uses the MAC address of the first physical interface that you add. If you change the order of the member interfaces in the configuration, then its MAC address changes to match the MAC address of the interface that is now listed first. If you manually assign a MAC address to the redundant interface, that is used regardless of the physical-interface MAC addresses.
You also might want to assign unique MAC addresses to subinterfaces. For example, your service provider might control access based on MAC addresses.
Further, if you use failover, you can provide a standby MAC address. If the active unit fails over and the standby unit becomes active, the new active unit starts using the active MAC addresses to minimize network disruption, while the old active unit uses the standby address.
(Optional) To manually assign a private MAC address to the current interface:
Step 1 In the Add/Edit Interface dialog box, provide the desired MAC address in the Active MAC Address field.
MAC addresses are provided in H.H.H format, where H is a 16-bit hexadecimal digit. For example, the MAC address 00-0C-F1-42-4C-DE would be entered as 000C.F142.4CDE.
Step 2 Press the Tab key on your keyboard, or click elsewhere in the dialog box (e.g., in the Description field), to trigger a dialog-box update, which includes activating the Standby MAC Address field.
Step 3 If desired, provide a Standby MAC Address for use with device-level failover.
If the active unit fails over and the standby unit becomes active, the new active unit begins using the active MAC addresses to minimize network disruption, while the old active unit uses the standby address.
Step 4 Continue configuring the device interface in the Using the Add/Edit Interface Dialog Box.
For ASA 5500 series appliances, ports that are built into the chassis are assigned to slot 0, while ports on the 4GE SSM are assigned to slot 1. By default, all connectors used on an ASA are RJ-45 connectors. However, the ports on the 4GE SSM can include fiber SFP connectors.
As part of the interface configuration for one of these fiber-based connections, you must change the Media Type setting from the default (RJ45) to the fiber-connector setting (SFP). Therefore, in the Add/Edit Interface dialog box, when you enter a hardware port ID with slot/port numbers in the Hardware Port field, the Media Type options are enabled.
Note The fiber interface does not support duplexing and has a fixed speed, so the Duplex option is disabled, and the Speed options are limited to auto and nonegotiate. See Using the Add/Edit Interface Dialog Box for more information about the Speed and Duplex options.
Follow these steps to change the Media Type for an ASA interface to fiber:
Step 1 In the Add/Edit Interface dialog box, provide a physical port ID with a slot number of 1 in the Hardware Port field; for example, gigabitethernet1/2.
Step 2 Press the Tab key on your keyboard, or click elsewhere in the dialog box (e.g., in the Description field), to trigger a dialog-box update, which includes enabling the Media Type options.
If this is the first time you have followed this procedure, you may receive a message warning you to ensure a fiber connection is being used. Click OK to close the message box.
Step 3 Click the SFP button to change the connection type for this interface to fiber.
Step 4 Continue configuring the device interface in the Using the Add/Edit Interface Dialog Box.
Advanced configuration options are available for interfaces on devices operating in single-context mode. Note that these are general device-related settings; that is, they are not applied to individual interfaces. These options include:
•Enabling traffic between interfaces with the same security level
•Defining and editing PPPoE users (does not apply to FWSMs)
•Creating and editing VPDN groups (does not apply to FWSMs)
Note The information in this section does not apply to PIX 6.3 devices, nor to security devices in multiple-context mode.
Follow these steps to configure advanced interface settings:
Step 1 Ensure Device View is your present application view; if necessary, click the Device View button on the toolbar.
Note For more information on using the Device View to configure device policies, see Managing Policies in Device View, page 6-19.
Step 2 Select the appliance you want to configure.
Step 3 Select Interfaces in the Device Policy selector.
The Interfaces page is displayed. For a description of the fields on this page, see Managing Device Interfaces.
Step 4 Click the Advanced button at the bottom of the Interfaces page to open the Advanced Interface Settings dialog box.
Step 5 (optional) Choose the desired setting for Traffic between interfaces with the same security levels, as described in Enabling Traffic between Interfaces with the Same Security Level.
Step 6 (optional; PIX/ASA only) To create and manage a list of PPPoE users, click the PPPoE Users button to open the PPPoE Users dialog box.
You can add, edit and delete PPPoE users in this dialog box, as described in Managing the PPPoE Users List.
Step 7 (optional; PIX/ASA only) Follow these steps to manage VPDN groups:
•To add a VPDN group, click the Add Row button in the Advanced Interface Settings dialog box; the Add VPDN Group dialog box appears.
•To edit a VPDN group, select the desired group from the list in the dialog box and then click the Edit Row button; the Edit VPDN Group dialog box appears.
•To delete a VPDN group, select the desired group from the list in the dialog box and then click the Delete Row button. A confirmation dialog box may appear; click OK to delete the group.
The Add VPDN Group dialog box and the Edit VPDN Group dialog box are virtually identical; they are described in Managing VPDN Groups.
Step 8 Click OK to close the Advanced Interface Settings dialog box.
The Advanced Interface Settings dialog box presented for a single-context security device includes the "Traffic between interfaces with the same security level" drop-down list, as described in this section. (See Advanced Device Interface Configuration for information about the Advanced Interface Settings dialog box.)
By default, interfaces or subinterfaces on the same security level cannot communicate with each other. Allowing communication between same-security interfaces provides the following benefits:
•You can configure more than 101 communicating interfaces.
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).
•You can allow traffic to flow freely between all same-security interfaces without access lists.
Note If you enable NAT control, you do not need to configure NAT between same-security-level interfaces.
Step 1 In the Advanced Interface Settings dialog box, choose the option that identifies how you want this device to handle Traffic between interfaces with the same security levels:
•Disabled—Communication between interfaces on the same security level is not allowed.
•Inter-interface—Enables traffic flows between interfaces with the same security level setting. When this option is enabled, you are not required to define translation rules to enable traffic flow between interfaces in the firewall device.
•Intra-interface—Enables traffic flows between subinterfaces with the same security level setting. When this option is enabled, you are not required to define translation rules to enable traffic flow between subinterfaces assigned to an interface.
•Both—Allows both intra- and inter-interface communications among interfaces and subinterfaces with the same security level.
Step 2 Continue with Advanced Device Interface Configuration, or click OK to close the Advanced Interface Settings dialog box.
Point-to-Point Protocol over Ethernet (PPPoE) allows standard PPP communication between a security device and an external ISP, via an Ethernet interface on the device. To establish a communication link, the device must provide authentication credentials and obtain network parameters. This is accomplished using a Virtual Private Dialup Network (VPDN) group, which basically consists of an established PPPoE user (i.e., a user name and password) and an authentication protocol. See Managing VPDN Groups for more information about VPDN groups.
The PPPoE user credentials available for use with VPDN groups are maintained in the PPPoE Users dialog box, which opens when you click the PPPoE Users button in the Advanced Interface Settings dialog box (see Advanced Device Interface Configuration).
The PPPoE Users dialog box presents a table of currently defined PPPoE users, along with standard Add Row, Edit Row, and Delete Row buttons:
•To add a new PPPoE user to the list, click the Add Row button; the Add PPPoE User dialog box appears.
•To edit a PPPoE user, select the desired user in the list and then click the Edit Row button; the Edit PPPoE User dialog box appears.
•To delete a PPPoE user, select the desired user in the list and then click the Delete Row button. A confirmation dialog box may appear; click OK to delete the user.
Except for the title, the Add PPPoE User dialog box and the Edit PPPoE User dialog box are identical; use of both to manage PPPoE user credentials is described in the following steps.
Step 1 Enter or edit the following PPPoE user-credential parameters:
•Username—The name assigned to this user account; generally provided by the external ISP.
•Password—The password assigned to this user account; generally provided by the external ISP.
•Confirm—Re-enter the password.
•Store Username and Password in Local Flash—If selected, this PPPoE user information will be stored in the device's local Flash memory, ensuring it cannot be inadvertently overwritten.
Step 2 Click OK to close the Add (Edit) PPPoE User dialog box and return to the PPPoE Users dialog box.
A Virtual Private Dialup Network (VPDN) group—basically an established PPPoE user and an authentication protocol—is used by a security device to contact an external ISP and authenticate itself, in order to establish a PPPoE communications link and obtain network parameters. (See Managing the PPPoE Users List for information about establishing PPPoE users.)
Available VPDN groups are maintained in the Advanced Interface Settings dialog box, which opens when you click the Advanced button at the bottom of the Interfaces page, as described in Advanced Device Interface Configuration.
The dialog box includes a table of currently defined VPDN groups, and standard Add Row, Edit Row, and Delete Row buttons. The Add Row button opens the Add VPDN Group dialog box; the Edit Row button opens the virtually identical Edit VPDN Group dialog box. Use of both is described in the following steps.
Step 1 Enter or edit the following VPDN group parameters:
•Group Name—A name to identify this group in Security Manager; up to 63 characters.
•PPPoE Username—The name identifying the PPPoE credentials to be used by this group for authentication with an ISP.
Choose from the list of available PPPoE users. Refer to Managing the PPPoE Users List for information about creating and editing users.
•PPP Authentication—Choose the authentication method expected by the ISP:
–PAP—Password Authentication Protocol, with exchange of credentials in clear text.
–CHAP—Challenge Handshake Authentication Protocol, with encrypted credential exchange.
–MSCHAP—Microsoft's CHAP, version 1 only.
Step 2 Click OK to close the Add (Edit) VPDN Group dialog box and return to the Advanced Interface Settings dialog box.
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 on 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.
The NAT section contains information about defining Network Address Translation (NAT) settings and translation rules for security devices. This information is presented in the following topics:
•Configuring Translation Options
•Configuring Translation Rules
–Defining Translation Exemptions (NAT 0 ACL)
–Defining Simple Dynamic Rules
–Defining Policy Dynamic Rules
–Viewing A General Summary of Translation Rules
Address translation substitutes the real address in a packet with a mapped address that is routable on the destination network. Network Address Translation (NAT) actually consists of two steps: the translation of a real address into a mapped address, and the reverse translation for returning traffic.
Cisco security devices support both the NAT feature, which provides a globally unique address for each outbound host session, and the Port Address Translation (PAT) 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 specifically designated 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.
The security appliance translates an address when an existing NAT rule matches the specific traffic. If no NAT rule matches, processing for the packet continues. The exception is when you enable NAT control. NAT control requires that packets traversing from a higher security interface (inside) to a lower security interface (outside) match a NAT rule, or processing for the packet stops.
Cisco security devices can perform NAT or PAT on 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, or static PAT. If necessary, you can use outside NAT together with inside NAT to translate the both source and destination IP addresses of a packet.
Note In this document, all types of translation are referred to as NAT. When describing NAT, the terms inside and outside represent the security relationship between any two interfaces. The higher security level is inside and the lower security level is outside. For example, interface 1 is at 60 and interface 2 is at 50; therefore, interface 1 is "inside" and interface 2 is "outside."
The following table briefly describes the various types of address translation available within Cisco Security Manager.
Use the Address Pools page to view, define new, and delete existing global address pools used by dynamic NAT rules.
To manage NAT address pools, follow these steps:
Step 1 Access the Address Pools page by doing one of the following:
•(Device view) Select NAT > Address Pools from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Address Pools from the Policy Types selector. Select an existing policy from the Policies selector, or right-click Address Pools and choose New Address Pools Policy to create a new policy.
The Address Pools page is displayed. For a description of the fields on this page, see Table K-1 on page K-4.
Step 2 For each address pool you want to define:
a. Click the Add Row button to open the Address Pool Dialog Box, page K-5.
b. Enter or Select the name of the interface to which this address pool will apply.
c. Enter a unique Pool ID number for this address pool, an integer between 1 and 2147483647.
d. In the IP address ranges field, enter or Select the addresses to be assigned to this pool. You can specify these addresses as follows:
•Address range for dynamic NAT (e.g., 192.168.1.1-192.168.1.15)
•Subnetwork (e.g., 192.168.1.0/24)
•List of addresses separated by commas (e.g., 192.168.1.1, 192.168.1.2, 192.168.1.3)
•Single address to use for PAT (192.168.1.1)
•Combinations of the above (192.168.1.1-192.168.1.15, 192.168.1.25)
•Names of hosts on the connected network; these will be resolved to IP addresses.
e. Optionally, enter a description for the pool.
f. To enable interface Port Address Translation (PAT), select Enable Interface PAT.
g. Click OK to close the dialog box.
Step 3 To edit an address pool, select it from the list on the Address Pools page and then click the Edit Row button.
The Address Pool Dialog Box, page K-5 opens. Make the desired changes and click OK to close the dialog box.
Step 4 To delete an address pool, select it from the list on the Address Pools page and then click the Delete Row button.
A confirmation dialog box may appear; click OK to confirm the deletion.
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.
To configure NAT options for the selected device, follow these steps:
Step 1 Access the Translation Options page by doing one of the following:
•(Device view) Select NAT > Translation Options from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Options from the Policy Types selector. Select an existing policy from the Policies selector, or right-click Translation Options and choose New Translation Options Policy to create a new policy.
The Translation Options page is displayed. For a description of the fields on this page, see Table K-3 on page K-6.
Step 2 To allow traffic to pass through the security appliance without address translation, check Enable traffic through the firewall without address translation. If this option is not selected, any traffic that does not match a translation rule is dropped.
Note This option is only available on PIX 7.x, FWSM 3.x and ASA devices.
Step 3 To disable NAT sessions for untranslated traffic (called "xlate bypass"), check Enable xlate bypass.
Note This option is available only on FWSM 3.2 and higher.
By default, the FWSM creates NAT sessions for all connections even if NAT is not used. For example, a session is created for each untranslated connection even if NAT control is not enabled, if NAT exemption or identity NAT is used, or if you use same-security interfaces and do not configure NAT. Because there is a maximum number of NAT sessions (266,144 concurrent), these kinds of NAT sessions might cause you to run into the limit. To avoid reaching the limit, enable xlate bypass.
If you disable NAT control and have untranslated traffic or use NAT exemption, or if you enable NAT control and use NAT exemption, then with xlate bypass, the FWSM does not create a session for those types of untranslated traffic. However, NAT sessions are still created in the following instances:
•You configure identity NAT (with or without NAT control)—identity NAT is considered to be a translation.
•You use same-security interfaces with NAT control. Traffic between same-security interfaces create NAT sessions even when you do not configure NAT for the traffic. To avoid NAT sessions in this case, disable NAT control, or use NAT exemption as well as xlate bypass.
Step 4 To allow VPN traffic to pass through the security appliance without address translation, check Do not translate VPN traffic.
Use the Translation Rules page to define address translation rules on the selected device. The Translation Rules page consists of the following tabs:
•Translation Exemptions (NAT 0 ACL)
•Dynamic Rules
•Policy Dynamic Rules
•Static Rules
•General
To configure translation rules for the selected device, follow these steps:
Step 1 Access the Translation Rules page by doing one of the following:
•(Device view) Select NAT > Translation Rules from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Rules from the Policy Type selector. Select an existing policy from the Shared Policy selector, or right-click Translation Rules to create a new policy.
The Translation Rules page is displayed. See Translation Rules Page, page K-6 for a description of this page.
Step 2 To configure rules specifying traffic that is exempt from address translation, click the Translation Exemptions (NAT 0 ACL) tab. See Defining Translation Exemptions (NAT 0 ACL) for information about using this tab.
Note Translation exemptions are only supported by PIX, ASA and FWSM devices in router mode, and FWSM 3.2 devices in transparent mode. Other devices in transparent mode support only static translation rules.
Step 3 To configure dynamic NAT and PAT rules, click the Dynamic Rules tab. See Defining Simple Dynamic Rules for information about using this tab.
Note Dynamic translation rules are only supported by PIX, ASA and FWSM devices in router mode, and FWSM 3.2 devices in transparent mode. Other devices in transparent mode support only static translation rules.
Step 4 To configure dynamic translation rules based on source and destination addresses and services, click the Policy Dynamic Rules tab. See Defining Policy Dynamic Rules for information about using this tab.
Note Policy dynamic rules are only supported by PIX, ASA and FWSM devices in router mode, and FWSM 3.2 devices in transparent mode. Other devices in transparent mode support only static translation rules.
Step 5 To configure static translation rules for a security appliance or shared policy, click the Static Rules tab. See Defining Static Rules for information about using this tab.
Step 6 To view all current translation rules, listed in the order that they will be evaluated on the device, click the General tab. See Viewing A General Summary of Translation Rules for more information about this tab.
Note The General tab is visible only for PIX, ASA and FWSM devices in router mode, and FWSM 3.2 devices in transparent mode. Other devices in transparent mode support only static translation rules and do not need to display summary information.
Use the options on the Translation Exemptions (NAT 0 ACL) tab of the Translation Rules page to specify traffic that is exempt from address translation.
Follow these steps to manage translation exemptions:
Step 1 Access the Translation Rules page by doing one of the following:
•(Device view) Select NAT > Translation Rules from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Rules from the Policy Types selector. Select an existing policy from the Policies selector, or right-click Translation Rules and choose New Translation Rules Policy to create a new policy.
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page K-6.
Step 2 Click the Translation Exemptions (NAT 0 ACL) tab.
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 K-7.
Step 3 To add a translation exemption rule:
a. Click the Add Row button to open the Add/Edit Translation Exemption (NAT-0 ACL) Rule dialog box.
b. Complete the fields in this dialog box. For more information, see Add/Edit Translation Exemption (NAT-0 ACL) Rule Dialog Box, page K-8.
c. Click OK to close the dialog box and add the translation exemption rule to the table.
Step 4 To edit a translation exemption rule:
a. Select the rule in the list and then click the Edit Row button to open the Add/Edit Translation Exemption (NAT-0 ACL) Rule dialog box.
b. Make the necessary changes in the dialog box. For more information, see Add/Edit Translation Exemption (NAT-0 ACL) Rule Dialog Box, page K-8.
c. Click OK to close the dialog box, updating the rule.
Step 5 To delete a translation exemption rule:
a. Select the rule in the list and then click the Delete Row button.
b. A confirmation dialog box may appear. Click OK to confirm the deletion and close the dialog box.
Step 6 Re-order the rules list, as necessary.
Rules are evaluated line by line, from top to bottom, so the ordering of the rules is important. After adding or deleting rules, you may need to re-order the list:
a. Select a rule in the list and then click the Up Row button to move the rule up one line, or click the Down Row button to move the rule down one line.
b. Repeat until the rule is in the desired location in the list.
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.
Follow these steps to manage dynamic translation rules:
Step 1 Access the Translation Rules page by doing one of the following:
•(Device view) Select NAT > Translation Rules from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Rules from the Policy Types selector. Select an existing policy from the Policies selector, or right-click Translation Rules and choose New Translation Rules Policy to create a new policy.
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page K-6.
Step 2 Click the Dynamic Rules tab.
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 K-9.
Step 3 To define a simple dynamic rule:
a. Click the Add Row button to open the Add/Edit Dynamic Translation Rule dialog box.
b. Complete the fields in this dialog box. For more information, see Add/Edit Dynamic Translation Rule Dialog Box, page K-11.
c. Click OK to close the dialog box and add the dynamic translation rule to the table.
Step 4 To edit a simple dynamic rule:
a. Select the rule in the list and then click the Edit Row button to open the Add/Edit Dynamic Translation Rule dialog box.
b. Make the necessary changes in the dialog box. For more information, see Add/Edit Dynamic Translation Rule Dialog Box, page K-11.
c. Click OK to close the dialog box, updating the rule.
Step 5 To delete a simple dynamic rule:
a. Select the rule in the list and then click the Delete Row button.
b. A confirmation dialog box may appear. Click OK to confirm the deletion and close the dialog box.
Step 6 Re-order the rules list, as necessary.
Rules are evaluated line by line, from top to bottom, so the ordering of the rules is important. After adding or deleting rules, you may need to re-order the list:
a. Select a rule in the list and then click the Up Row button to move the rule up one line, or click the Down Row button to move the rule down one line.
b. Repeat until the rule is in the desired location in the list.
The Policy Dynamic Rules tab lets you configure dynamic translation rules based on source and destination addresses and services.
Follow these steps to manage policy dynamic rules:
Step 1 Access the Translation Rules page by doing one of the following:
•(Device view) Select NAT > Translation Rules from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Rules from the Policy Types selector. Select an existing policy from the Policies selector, or right-click Translation Rules and choose New Translation Rules Policy to create a new policy.
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page K-6.
Step 2 Click the Policy Dynamic Rules tab.
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 K-13.
Step 3 To define a policy dynamic rule:
a. Click the Add Row button to open the Add/Edit Policy Dynamic Rules dialog box.
b. Complete the fields in this dialog box. For more information, see Add/Edit Policy Dynamic Rules Dialog Box, page K-14.
c. Click OK to close the dialog box and add the policy dynamic translation rule to the table.
Step 4 To edit a policy dynamic rule:
a. Select the rule in the list and then click the Edit Row button to open the Add/Edit Policy Dynamic Rules dialog box.
b. Make the necessary changes in the dialog box. For more information, see Add/Edit Policy Dynamic Rules Dialog Box, page K-14.
c. Click OK to close the dialog box, updating the rule.
Step 5 To delete a policy dynamic rule:
a. Select the rule in the list and then click the Delete Row button.
b. A confirmation dialog box may appear. Click OK to confirm the deletion and close the dialog box.
Step 6 Re-order the rules list, as necessary.
Rules are evaluated line by line, from top to bottom, so the ordering of the rules is important. After adding or deleting rules, you may need to re-order the list:
a. Select a rule in the list and then click the Up Row button to move the rule up one line, or click the Down Row button to move the rule down one line.
b. Repeat until the rule is in the desired location in the list.
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.
Follow these steps to manage static translation rules:
Step 1 Access the Translation Rules page by doing one of the following:
•(Device view) Select NAT > Translation Rules from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Rules from the Policy Types selector. Select an existing policy from the Policies selector, or right-click Translation Rules and choose New Translation Rules Policy to create a new policy.
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page K-6.
Step 2 Click the Static Rules tab.
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 K-15.
Step 3 To define a new static rule:
a. Click the Add Row button to open the Add/Edit Static Rule dialog box.
b. Complete the fields in this dialog box. For more information, see Add/Edit Static Rule Dialog Box, page K-17.
c. Click OK to close the dialog box and add the static translation rule to the table.
Step 4 To edit a static rule:
a. Select the rule in the list and then click the Edit Row button to open the Add/Edit Static Rule dialog box.
b. Make the necessary changes in the dialog box. For more information, see Add/Edit Static Rule Dialog Box, page K-17.
c. Click OK to close the dialog box, updating the rule.
Step 5 To delete a static rule:
a. Select the rule in the list and then click the Delete Row button.
b. A confirmation dialog box may appear. Click OK to confirm the deletion and close the dialog box.
Step 6 Re-order the rules list, as necessary.
Rules are evaluated line by line, from top to bottom, so the ordering of the rules is important. After adding or deleting rules, you may need to re-order the list:
a. Select a rule in the list and then click the Up Row button to move the rule up one line, or click the Down Row button to move the rule down one line.
b. Repeat until the rule is in the desired location in the list.
You can view a summary of all translation rules defined for the current device or shared policy. This general summary shows the translation rules in the order in which the rules are applied on the security appliance.
Follow these steps to view the rules summary:
Step 1 Access the Translation Rules page by doing one of the following:
•(Device view) Select NAT > Translation Rules from the Device Policy selector.
•(Policy view) Select NAT (PIX/ASA/FWSM) > Translation Rules from the Policy Type selector. Select an existing policy from the Shared Policy selector, or right-click Translation Rules to create a new policy.
The Translation Rules page is displayed. For a description of the fields on this page, see Translation Rules Page, page K-6.
Step 2 Click the General tab.
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 K-19.
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 re-addressing is unnecessary.
Maintenance is facilitated because there are no complicated routing patterns to troubleshoot and no NAT configuration.
Although 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, which 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 The transparent-mode security appliance does not pass CDP packets.
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 pass 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.
Using the Bridging options, you can customize your transparent firewall by adding static MAC address entries, enabling ARP inspection, and so on.
For more information, see Bridging, page K-50.
Although FWSM 3.1 can support multiple L2 interface pairs, Cisco Security Manager 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. 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 Cisco Security Manager, although the bridge-group commands will be generated during deployment. Bridge group 1 will be deployed and used in transparent rule policies if no bridge group exists in the device configuration.
The Device Admin section contains pages for configuring device administration policies for firewall devices. For more information, see the following topics:
•Configuring Boot Image and Configuration Settings
•Configuring Contact Credentials
•Configuring Device Access Settings on Firewall Devices
–Configuring Management Access
•Configuring Hostname Settings
•Configuring Resources on Firewall Services Modules
•Configuring Server Access Settings on Firewall Devices
Authentication-Authorization-Accounting (AAA) enables the security appliance to determine who a 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 also can use accounting alone, or with authentication and authorization.
Authentication-Authorization-Accounting provides an extra level of protection and control for user access beyond 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 to limit user access to the server when you may not always know the 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.)
•Authentication—Authentication grants access based on user identity. Authentication establishes user identity by requiring valid user credentials, which are typically a user name and password. You can configure the security appliance to authenticate the following items:
–Administrative connections to the security appliance using Telnet, SSH, HTTPS/ASDM, or serial console.
–The enable command.
•Authorization—Authorization controls user capabilities after users are authenticated. Authorization controls the services and commands available to each authenticated user. If you do not enable authorization, authentication alone would provide the same access to services for all authenticated users.
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 might authenticate inside users who attempt to access any server on the outside network, and then use authorization to limit the outside servers that a particular user can access.
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.
•Accounting—Accounting tracks traffic that passes through the security appliance, providing a record of user activity. If you enable authentication for that traffic, you can account for traffic per user. If you do not authenticate the traffic, you can account for traffic per IP address. Accounting information includes when sessions start and stop, user name, the number of bytes that pass through the security appliance for the session, the service used, and the duration of each session.
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 an AAA server. Before you implement AAA, you should configure the Local database and configure AAA server groups and servers.
Configuration of 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 lock-outs and, if so desired, to provide a fallback method when AAA servers are unreachable. For more information, see Configuring User Accounts.
The following table 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 accounts 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.
The security appliance maintains a Local database that you can populate with user accounts, which contain, at a minimum, a user name. Typically, you assign a password and a privilege level to each user name, although passwords are optional. You can manage Local user accounts on the Platform > Device Admin > User Accounts page (see Configuring User Accounts).
If you enable command authorization using the Local database, the security appliance refers to the assigned user privilege level to determine what commands are available. By default, all commands are assigned either privilege level 0 or level 15.
Note If you add users to the Local database with access to the CLI and whom you do not want to enter privileged mode, you should enable command authorization. Without command authorization, users can access privileged mode (and all commands) at the CLI using their own password if their privilege level is 2 or greater (2 is the default). Alternatively, you can use RADIUS or TACACS+ authentication for console access so the user will not be able to use the login command, or you can set all local users to level 1 so you can control who can use the system enable password to access privileged mode.
You cannot use the local database for network access authorization.
The user accounts in the Local database can provide fallback support for console and enable-password authentication, for command authorization, and for VPN authentication and authorization. This behavior is designed to help you prevent accidental lock-out from the security appliance.
For users who need fallback support, we recommend that their user names and passwords in the Local database match their user names and passwords on the AAA servers. This provides transparent fallback support. Because the user cannot determine whether a AAA server or the local database is providing the service, using user names and passwords on AAA servers that are different than the user names and passwords in the Local database means that the user cannot be certain which user name and password should be given.
For multiple-context mode, you can configure user names 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 VPN functions are not supported in multiple mode.
You can authenticate all administrative connections to the security appliance, including:
•Telnet
•SSH
•Serial console
•ASDM
•VPN management access
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).
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 11-40). 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 appliance is to use to process the AAA service request.
AAA services for VPN access include the following:
•User account settings for assigning users to VPN groups, configured on the Platform > Device Admin > User Accounts page (see Configuring User Accounts).
•VPN group policies that can be referenced by many user accounts or tunnel groups, configured on the Remote Access VPN > RA VPN Policies > User Group Policy or Site to Site VPN > User Group Policy page.
•Tunnel group policies, configured on the Remote Access VPN > RA VPN Policies > PIX7.0/ASA Tunnel Group Policy or Site to Site VPN > PIX7.0/ASA Tunnel Group Policy page.
Use the following procedure to define the AAA settings for a device or shared policy.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > AAA from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > AAA from the Policy Types selector. Right-click AAA and choose New AAA Policy to create a policy, or select an existing policy from the Policies selector.
The AAA page is displayed. For a description of the fields on this page, see AAA Page, page K-56.
Step 2 Click the Authentication tab.
Step 3 To require AAA authentication for privileged commands:
a. Check the Enable box under Require AAA Authentication to allow use of privileged commands.
b. Enter the name of the AAA server group to use for authentication, or click Select to select from a list.
c. To use the local database as a fallback method for privileged command authentication, check the Use LOCAL when server group fails box.
Step 4 To require AAA authentication for HTTP, serial-console, SSH, or Telnet access to the security appliance:
a. Check the box next to the type of device access you want to authenticate (HTTP, Serial, SSH, or Telnet).
b. Enter the name of the AAA server group to use for authentication, or click Select to select from a list.
c. To use the local database as a fallback method for authentication of this device access, check the Use LOCAL when server group fails box.
Step 5 In the Login Prompt field, enter the prompt you want users to see when authentication takes place.
Step 6 Enter the messages you want users to see when accepted or rejected in the corresponding boxes.
Step 7 Click the Authorization tab.
Step 8 To require AAA authorization for command access:
a. Check the Enable Authorization for Command Access box.
b. Enter the name of the AAA server group to use for authorization, or click Select to select from a list.
c. To use the local database as a fallback method for command authorization, check the Use LOCAL when server group fails box.
Step 9 Click the Accounting tab.
Step 10 To require AAA accounting for privileged commands:
a. Check Enable under Require AAA Accounting for privileged commands.
b. Enter the name of the AAA server group to use for accounting, or click Select to select from a list.
Step 11 To require AAA accounting for HTTP, serial-console, SSH, or Telnet access to the security appliance:
a. Check the box next to the type of device access for which you want accounting enabled (HTTP, Serial, SSH, or Telnet).
b. Enter the name of the AAA server group to use for accounting, or click Select to select from a list.
Step 12 To require AAA accounting for command access:
a. Check Enable under Require Accounting for command access.
b. Enter the name of the AAA server group to use for accounting, or click Select to select from a list.
c. Select the minimum privilege level that must be associated with a command for an accounting record to be generated.
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 host name 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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Banner from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Banner from the Policy Types selector. Right-click Banner and choose New Banner Policy to create a policy, or select an existing policy from the Policies selector.
The Banner page is displayed. For a description of the fields on this page, see Table K-40 on page K-60.
Step 2 In the Session (exec) Banner box, enter the text that you want the system to display as a banner before displaying the enable prompt.
Step 3 In the Login Banner box, enter the text that you want the system to display as a banner before the password login prompt when accessing the security appliance using Telnet.
Step 4 In the Message-of-the-Day (motd) Banner box, enter the text that you want the system to display as a message-of-the-day banner.
Step 5 To replace a banner, change the contents of the appropriate box.
Step 6 To remove a banner, clear the contents of the appropriate box.
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 start-up.
You can specify up to four local binary image files for use as the start-up 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 memory.
If you do not specify any boot variable, the first valid image on internal Flash will be chosen to boot the system.
Related Topics
•Boot Image/Configuration Page, page K-61
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Boot Image/Configuration from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Boot Image/Configuration from the Policy Types selector. Right-click Boot Image/Configuration and choose New Boot Image/Configuration Policy to create a policy, or select an existing policy from the Policies selector.
The Boot Image/Configuration page is displayed. For a description of the fields on this page, see Table K-41 on page K-61.
Step 2 Enter the URL of the configuration file to use when the system is loaded. For syntax information, see Table K-41 on page K-61.
Step 3 Enter the path to the ASA image file on the security appliance, for example, flash:/asa
. For syntax information, see Table K-41 on page K-61.
Step 4 For each system image file that you want to add, edit, or delete, do one of the following:
•To add a system image file to the Boot Images table, click Add Row to open the Images dialog box.
•To edit a system image file, select the entry and click Edit Row to open the Images dialog box.
•To delete a system image file from the Boot Images table, select the entry and click Delete Row.
Step 5 Enter the URL of the system image file to use when the system is loaded, and then click OK. For syntax information, see Images Dialog Box, page K-62.
Step 6 To move a system image file up or down in the table, select the row for that image file and then click the Up Arrow or Down Arrow buttons as necessary.
The Clock page lets you manually set the date and time for the security appliance.
Note In multiple-context mode, set the time in the system configuration only.
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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Clock from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Clock from the Policy Types selector. Right-click Clock and choose New Clock Policy to create a policy, or select an existing policy from the Policies selector.
The Clock page is displayed. For a description of the fields on this page, see Table K-43 on page K-63.
Step 2 Select the time zone for this device in the Device Time Zone list box.
Step 3 If daylight savings time does not apply to this device, select None.
Step 4 Otherwise, to specify daylight savings time using a start and end date:
a. Select Set by Date.
b. Click the Calendar button under Start to pick the date on which daylight savings time begins.
c. Select the hour and minute that daylight savings time begins using the drop-down list boxes.
d. Click the Calendar button under End to pick the date on which daylight savings time ends.
e. Select the hour and minute that daylight savings time ends using the drop-down list boxes.
Step 5 To specify daylight savings time using a specific day of the year (for example, the first Sunday in August):
a. To specify that daylight savings time occurs on the same days every year, select the Specify Recurring Time check box.
b. Select the month in which daylight savings time begins in the Month drop-down list box under Start.
c. Select the number that corresponds to the week in which daylight savings time begins in the Week drop-down list box under Start.
d. Select the day of the week on which daylight savings time begins in the Weekday drop-down list box under Start.
e. Select the hour at which daylight savings time begins in the Hour drop-down list box under Start.
f. Select the minute at which daylight savings time begins in the Minute drop-down list box under Start.
g. Select the month in which daylight savings time ends in the Month drop-down list box under End.
h. Select the number that corresponds to the week in which daylight savings time ends in the Week drop-down list box under End.
i. Select the day of the week on which daylight savings time ends in the Weekday drop-down list box under End.
j. Select the hour at which daylight savings time ends in the Hour drop-down list box under End.
k. Select the minute at which daylight savings time ends in the Minute drop-down list box under End.
You can use the Contact Credentials page to specify the future contact settings that Cisco 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.)
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Contact Credentials from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Contact Credentials from the Policy Types selector. Right-click Contact Credentials and choose New Contact Credentials Policy to create a policy, or select an existing policy from the Policies selector.
The Contact Credentials page is displayed. For a description of the fields on this page, see Table K-44 on page K-64.
Step 2 To change the contact user name and password:
a. Check the Change the contact username and password box.
The Username and Password fields are enabled.
b. Enter a user name for logging in to the device.
c. Enter the password for logging in to the device.
d. Re-enter the password for logging in to the device.
e. Select the privilege level of the user logging in to the device.
Step 3 To change the enable password:
a. Check the Change the enable password box.
The Enable Password fields are enabled.
b. Enter the enable password.
c. Re-enter the enable password.
Step 4 To change the Telnet/SSH password:
a. Check the Change the TELNET/SSH password box.
The Telnet Password fields are enabled.
b. Enter the enable password.
c. Re-enter the enable password.
The Device Access section contains pages for defining access to firewall devices. For more information, see the following topics:
•Configuring Management Access
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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > Console from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > Console from the Policy Types selector. Right-click Console and choose New Console Policy to create a policy, or select an existing policy from the Policies selector.
The Console Page, page K-65 is displayed.
Step 2 Enter the number of minutes (0-60) a console session can remain idle before the firewall device closes it. The default timeout is 0, which means the console will not time out.
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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > HTTP from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > HTTP from the Policy Types selector. Right-click HTTP and choose New HTTP Policy to create a policy, or select an existing policy from the Policies selector.
The HTTP page is displayed. For a description of the fields on this page, see Table K-46 on page K-66.
Step 2 Do one of the following:
•To add an HTTP entry, click Add Row to open the HTTP Configuration dialog box.
•To edit an HTTP entry, select the entry and click Edit Row to open the HTTP Configuration dialog box.
•To delete an HTTP entry, select the entry and click Delete Row.
Step 3 In the HTTP Configuration dialog box, enter the name of the interface from which administrative access to the security appliance is allowed. You can click Select to select the interface from a list.
Step 4 Enter the IP address and netmask of the host or network that is permitted to connect to this security appliance through the specified interface. The default netmask is 255.255.255.255 regardless of class.
Note To limit access to a single IP address, use 255.255.255.255. Do not use the subnetwork mask of the internal network.
Step 5 To require authentication via certificate from users who are establishing HTTPS connections, check Enable Authentication Certificate.
Step 6 To enable HTTP redirect, enter the number of the port the security appliance listens on for HTTP requests, which it then redirects to HTTPS. To disable HTTP redirect, ensure that this field is blank.
Step 7 To enable the HTTP server on the security appliance, check the Enable HTTP Server box.
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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > ICMP from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > ICMP from the Policy Types selector. Right-click ICMP and choose New ICMP Policy to create a policy, or select an existing policy from the Policies selector.
The ICMP page is displayed. For a description of the fields on this page, see Table K-48 on page K-68.
Step 2 Do one of the following:
•To add an ICMP entry, click Add Row to open the Add ICMP dialog box.
•To edit an ICMP entry, select the entry and click Edit Row to open the Edit ICMP dialog box.
•To delete an ICMP entry, select the entry and click Delete Row.
Step 3 Select the action (permit or deny) associated with this ICMP entry.
Step 4 Enter the ICMP service to which this ICMP rule applies. You can click Select to select the ICMP service from a list.
Step 5 Enter the name of the interface to which this ICMP rule applies. You can click Select to select the interface from a list.
Step 6 Enter the IP address and netmask of the host or network from which ICMP access is permitted or denied. The default netmask is 255.255.255.255 regardless of class.
Note To limit access to a single IP address, use 255.255.255.255. Do not use the subnetwork mask of the internal network.
Step 7 Click OK to close the dialog box.
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 firewall 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.
Related Topics
•Management Access Page, page K-69
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > Management Access from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > Management Access from the Policy Types selector. Right-click Management Access and choose New Management Access Policy to create a policy, or select an existing policy from the Policies selector.
The Management Access Page, page K-69 is displayed.
Step 2 Enter the name of the interface on the firewall device that should permit management access connections. Enabling this feature on an internal interface allows 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. Clear this field to disable management access. You can click Select to select the interface from a list of interface building blocks.
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.
Related Topics
•Add and Edit SSH Host Dialog Boxes, page K-70
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > Secure Shell from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > Secure Shell from the Policy Types selector. Right-click Secure Shell and choose New Secure Shell Policy to create a policy, or select an existing policy from the Policies selector.
The Secure Shell page is displayed. For a description of the fields on this page, see Table K-50 on page K-70.
Step 2 Specify the version of SSH accepted by the security appliance. By default, SSH Version 1 and SSH Version 2 connections are accepted
Step 3 In the Timeout field, enter the number of minutes (1 - 60) an SSH session can remain idle before the firewall device closes it.
Step 4 Manage SSH entries, as follows:
•To add an SSH entry, click Add Row to open the Add Host dialog box.
Enter or Select the name of an interface that will permit SSH sessions.
Enter the IP address and netmask of each host or network permitted to connect to this security appliance through the specified interface; separate multiple entries with commas. The default netmask is 255.255.255.255 regardless of class.
Note To limit access to a single IP address, use 255.255.255.255. Do not use the subnetwork mask of the internal network.
Refer to Add and Edit SSH Host Dialog Boxes, page K-70 for more information.
•To edit an SSH entry, select the entry and click Edit Row to open the Edit Host dialog box.
Refer to Add and Edit SSH Host Dialog Boxes, page K-70 for more information.
•To delete an SSH entry, select the entry and click Delete Row.
Step 5 Click OK to close the dialog box.
Step 6 To enable the secure copy server on the security appliance, select Enable Secure Copy.
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.
Here are definitions for some common SNMP terms:
•Management station—Network management stations running on PCs or workstations use the SNMP protocol to administer standardized databases residing on the device being managed. Management stations can also receive messages about events, such as hardware failures, which require attention.
•Agent—In the context of SNMP, the management station is a client and an SNMP agent running on the security appliance is a server.
•OID—The SNMP standard assigns a system object ID (OID) so that a management station can uniquely identify network devices with SNMP agents, and indicate to users the source of information monitored and displayed.
•MIB—The agent maintains standardized data structures called Management Information Databases (MIBs), which are compiled into management stations. MIBs collect information, such as packet, connection, and error counters, buffer usage and failover status. MIBs are defined for specific products and for the common protocols and hardware standards used by most network devices. SNMP management stations can browse MIBs or request only specific fields. In some applications, MIB data can be modified for administrative purposes.
•Trap—The agent also monitors alarm conditions. When an alarm condition defined in a trap occurs, such as a link up, link down, or syslog event, the agent sends notification, also known as SNMP trap, to the designated management station immediately.
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.
Cisco firewall devices support CPU utilization monitoring 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 Because all current firewall device hardware platforms support a single CPU, the firewall device returns only one row from cpmCPUTotalTable
and the index is always 1.
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
:
•cpmCPUTotal5secRev
•cpmCPUTotal1minRev
•cpmCPUTotal5minRev
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > SNMP from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > SNMP from the Policy Types selector. Right-click SNMP and choose New SNMP Policy to create a policy, or select an existing policy from the Policies selector.
The SNMP page is displayed. For a description of the fields on this page, see Table K-52 on page K-71.
Step 2 Enter the shared secret used by the SNMP management station when sending requests to the security appliance in the Read Community String field.
Step 3 Enter the name of the system administrator.
Step 4 Enter the location of the security appliance.
Step 5 For PIX 7.x and ASA:
a. To enable the security appliance to send traps to the SNMP management station, check Enable SNMP Servers.
b. To configure the traps that are sent to the SNMP management station, click Configure Traps to display the SNMP Trap Configuration dialog box, check the boxes corresponding to the traps you want to enable, and then click OK to close the dialog box.
c. Specify the port on which incoming requests will be accepted.
Step 6 Do one of the following:
•To add an SNMP Host entry, click Add Row to open the Add SNMP Host Access Entry dialog box.
•To edit an SNMP Host entry, select the entry and click Edit Row to open the Add SNMP Host Access Entry dialog box.
•To delete an SNMP Host entry, select the entry and click Delete Row.
Step 7 Enter the name of the interface on which the SNMP management station resides, or click Select to select the interface from a list.
Step 8 Enter the IP address of the SNMP management station.
Step 9 For PIX 7.x, ASA and FWSM 2.3 devices, enter the port to which notifications should be sent.
Step 10 For PIX 7.x and ASA, enter the community string to use for this management station.
Step 11 For PIX 7.x and ASA, select the SNMP version used by this management station.
Step 12 Check the appropriate boxes to identify the method for communicating with this management station:
•Poll—Firewall device waits for a periodic request from the management station.
•Trap—Sends syslog events when they occur.
Step 13 Click OK to close the dialog box.
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 Only five Telnet sessions can be active at the same time in single-context mode. In multiple-context mode on ASAs, there can be only five Telnet sessions active per context, 100 Telnet sessions active per blade. With resource class, the administrator can further tune this parameter.
Related Topics
•Telnet Configuration Dialog Box, page K-75
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > Telnet from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Device Access > Telnet from the Policy Types selector. Right-click Telnet and choose New Telnet Policy to create a policy, or select an existing policy from the Policies selector.
The Telnet page is displayed. For a description of the fields on this page, see Table K-55 on page K-75.
Step 2 In the Timeout field, enter the number of minutes a Telnet session can remain idle (1 - 1440) before the firewall device closes it.
Step 3 Manage Telnet entries, as follows:
•To add a Telnet entry, click Add Row to open the Telnet Configuration dialog box.
Enter or Select an interface that can receive Telnet packets from a client.
Enter or Select the IP address and netmask, separated by a "/", of each host or network permitted to access the Telnet console through the specified interface. Use commas to separate multiple entries.
Note To limit access to a single IP address, use 255.255.255.255 or 32 as the netmask. Do not use the subnetwork mask of the internal network.
Refer to Telnet Configuration Dialog Box, page K-75 for more information.
•To edit a Telnet entry, select the entry and click Edit Row to open the Telnet Configuration dialog box.
Refer to Telnet Configuration Dialog Box, page K-75 for more information.
•To delete a Telnet entry, select the entry and click Delete Row.
The Failover page provides access to failover settings for the selected security appliance. The available settings and the overall appearance of the Failover page may change slightly, depending upon the type of device selected, its mode of operation (routed or transparent), and its context mode (single or multiple).
In other words, how you configure failover depends upon both the firewall mode and the security context of the security appliance.
Please note the following caveats when assigning an interface as a failover link:
•You can define the interface in the Using the Add/Edit Interface Dialog Box, but do not configure it. In particular, do not specify an interface Name, as this parameter disqualifies the interface from being used as the failover link.
•On an ASA 5505, an interface assigned as the backup for another interface cannot be used as a failover link (although no checking is performed to prevent this).
•Do not assign a PPPoE-enabled interface as a failover link. PPPoE and Failover should not be configured on the same device interface (although no checking is performed to prevent this).
•A Failover interface cannot use the same IP address as another interface, especially the Management IP address (although no checking is performed to prevent this).
Note also that after you assign an interface as a failover link, the interface is listed on the Interfaces page, but you cannot edit or delete the interface from that page. The only exception is if you set a physical interface to be the stateful failover link—you can configure its speed and duplex.
Related Topics
Failover lets you set up two identical security appliances such that one will take over firewall operations if the other fails. Using a pair of security appliances, you can provide high system availability without operator intervention.
The linked security appliances communicate failover information over a dedicated link. This failover link can be either a LAN-based connection or, on PIX security appliances, a dedicated serial failover cable. The following information is communicated over the failover link:
•Current failover state (active or standby)
•"Hello" messages (keep-alives)
•Network link status
•MAC address exchange
•Configuration replication
Cisco security appliances support two types of failover:
•Active/Standby - The active security appliance inspects all network traffic, while the standby security appliance remains idle until a failure occurs on the active appliance. Changes to the configuration of the active security appliance are transmitted over the failover link to the standby security appliance.
When failover occurs, the standby security appliance becomes the active unit, and it assumes the IP and MAC addresses of the previously active unit. Because 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 operating in single- or multiple-context mode. In single-context mode, only Active/Standby failover is available, and all failover configuration is by means of the Failover page.
Note When using Active/Standby failover, you must make all configuration changes on the active unit. The active unit automatically replicates the changes to the standby unit. The standby unit should not be imported or added to the Cisco Security Manager device list.
•Active/Active - Both security appliances inspect network traffic by alternating their roles—such that one is active and one is standby—on a per context basis. This means Active/Active failover is available only on security appliances operating in multiple-context mode.
However, Active/Active failover is not required in multiple-context mode. That is, on a device operating in multiple-context mode, you can configure Active/Standby or Active/Active failover. In either case, you provide system-level failover settings in the system context, and context-level failover settings in the individual security contexts.
See Active/Active Failover for additional information about this topic.
In addition, failover can be stateless or stateful:
•Stateless - Also referred to as regular failover. With stateless failover, all active connections are dropped when failover occurs. Clients need to re-establish connections when the new active unit takes over.
•Stateful - The active unit in the failover pair continually passes per-connection state information to the standby unit. When failover occurs, the same connection information is available on the new active unit. Supported end-user applications are not required to reconnect to maintain the current communication session.
See Stateful Failover for more information.
Active/Active failover is available only on security appliances operating in multiple-context mode. In an Active/Active failover configuration, both security appliances inspect network traffic, on a per-context basis. That is, for each context, one of the appliances is the active device, while the other is the standby device.
The active and standby roles are assigned over the complete set of security contexts, more or less arbitrarily.
To enable Active/Active failover on the security appliance, you must assign the security contexts to one of two failover groups. A failover group is a simply a logical group of one or more security contexts. You should specify failover group assignments 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 the unit on which 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.
Note To reliably manage security contexts in Active/Active failover mode, Cisco Security Manager requires an IP address for the management interface of each context so that it can communicate directly with the active security context of a failover pair.
Initial configuration synchronization occurs when one or both units start. This synchronization occurs as follows:
•When both units start simultaneously, the configuration is synchronized from the primary unit to the secondary unit.
•When one unit starts while the other unit is already active, the unit that is starting up receives the configuration from the already active unit.
After both units are running, commands are replicated from one unit to the other as follows:
•Commands entered within a security context are replicated from the unit on which the security context appears in the active state to the peer unit.
Note A context is considered in the active state on a unit if the failover group to which it belongs is in the active state on that unit.
•Commands entered in the system execution space are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.
•Commands entered in the admin context are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.
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 When bootstrapping the peer devices in an Active/Active Failover configuration, the bootstrap configurations are only applied to the system contexts of the respective failover peer devices.
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 When configuring Active/Active failover, make sure that the combined traffic for both units is within the capacity of each unit.
Note Stateful Failover is not supported on the ASA 5505 appliance.
When stateful failover is enabled, the active unit in the failover pair continually updates the current connection state information on the standby unit. When failover occurs, supported end-user applications are not required to reconnect to maintain the current communication session.
Note The IP and MAC addresses for the state and LAN failover links do not change at failover.
To employ stateful failover, you must configure a link to pass all state information to the standby unit. If you are using a LAN failover connection rather than the serial failover interface (which is available only on the PIX platform), you can use the same interface for the state link and the failover link. However, we recommend that you use a dedicated interface for passing state information to the standby unit.
The following information is passed to the standby unit when stateful failover is enabled:
•NAT translation table
•TCP connection table (except for HTTP), including the timeout connection
•HTTP connection states (if HTTP replication is enabled)
•H.323, SIP and MGCP UDP media connections
•The system clock
•The ISAKMP and IPsec SA table
The following information is not copied to the standby unit when stateful failover is enabled:
•HTTP connection table (unless HTTP replication is enabled)
•The user authentication (uauth) table
•The ARP table
•Routing tables
The following steps describe basic failover configuration. Please note the following caveats when assigning an interface as a failover link:
•You can define the interface in the Using the Add/Edit Interface Dialog Box, but do not configure it. In particular, do not specify an interface Name, as this parameter disqualifies the interface from being used as the failover link.
•On an ASA 5505, an interface assigned as the backup for another interface cannot be used as a failover link (although no checking is performed to prevent this).
•Do not assign a PPPoE-enabled interface as a failover link. PPPoE and Failover should not be configured on the same device interface (although no checking is performed to prevent this).
•A Failover interface cannot use the same IP address as another interface, especially the Management IP address (although no checking is performed to prevent this).
Note When you save a failover configuration, it is applied to both the security appliance and the failover peer.
Step 1 Ensure Device View is your present application view; if necessary, click the Device View button on the toolbar.
Note For more information on using the Device View to configure device policies, see Managing Policies in Device View, page 6-19.
Step 2 Select the appliance you want to configure.
Step 3 Expand the Platform entry in the Device Policy selector, then expand Device Admin and select Failover.
The Failover page is displayed.
Step 4 (PIX only) Choose the Failover Method: Serial Cable or LAN Based.
Step 5 Select Enable Failover to enable failover on this appliance.
Step 6 Click the Bootstrap button to open the Bootstrap configuration for LAN failover dialog box, which provides bootstrap configurations that can be applied to the primary and secondary devices in a LAN failover configuration. See Bootstrap Configuration for LAN Failover Dialog Box, page K-91 for more information.
Step 7 (Multiple-context devices only) In the Configuration section, select the failover mode: Active/Active or Active/Standby.
Step 8 (Optional) Click the Settings button to open the Settings dialog box for the selected device. The contents of the Settings dialog box depend on the type of device, and whether it is operating in single or multiple mode—some options may not be available. Refer to the following sections:
•Settings Dialog Box, page K-85 (ASA/PIX 7+)
•Advanced Settings Dialog Box, page K-81 (FWSM)
Step 9 (Optional) Follow these steps to configure an interface for LAN Failover communications between the two devices:
a. Assign a device Interface for LAN-based communications, and then press the Tab key on your keyboard to update the page.
You can type in a port ID (e.g., gigabitethernet1), or you can choose the port if you have already defined the interface (see Using the Add/Edit Interface Dialog Box). Note that this cannot be a Named interface, nor can the interface be configured for PPPoE.
Note On an FWSM, this is a VLAN interface.
b. Provide a Logical Name for this failover interface.
c. Enter the Active IP address for failover communications.
d. Enter a Standby IP address for failover communications. The Standby IP address is used on the security appliance that is currently the standby unit.
e. Enter the Subnet Mask for both IP addresses. Both must be on the same subnet.
Step 10 (Optional) Follow these steps to enable and configure an interface for Stateful Failover communications between the two devices:
a. Assign a device Interface for update communications, and then press the Tab key on your keyboard to update the page.
You can type in a port ID (e.g., gigabitethernet1), or you can choose the port if you have already defined the interface (see Using the Add/Edit Interface Dialog Box; note that this cannot be a Named interface).
Note On an FWSM, this is a VLAN interface.
b. Provide a Logical Name for this interface.
c. Enter the Active IP address for connection updates.
d. Enter a Standby IP address for update communications.
e. Enter the Subnet Mask for both IP addresses. Both must be on the same subnet.
f. Select Enable HTTP Replication to preserve HTTP connection information.
Connection information is communicated to the standby unit for all TCP protocols except HTTP, because HTTP connections are generally short-lived. Select this option to maintain HTTP connections during failover.
Step 11 Provide a communications-encryption key: enter a Shared Key and then repeat it in the Confirm field. Be sure to enter the same key on both devices. (Not available on FWSM versions prior to 3.1)
The Shared Key can be any arbitrary string of up to 63 alphanumeric characters. If HEX is checked, the Shared Key is an arbitrary string of exactly 32 hexadecimal characters. (The HEX option is available only on PIX/ASA version 7.0.5 and later, and FWSM versions 3.1.3 and later.)
Note This step is optional, but we strongly recommend encrypting failover communications.
Step 12 To specify a failover reconnect timeout value for asymmetrically routed sessions, enter a length of time in the Timeout field, in the form hh:mm:ss (the minutes and seconds values are optional). If the field is blank (the default), or contains a zero, reconnections are prevented. Setting this value to -1 disables the timeout, allowing connections to reconnect after any amount of time.
Step 13 (FWSM only) - Configured interfaces are listed in the Interface Configuration table. To edit the failover configuration for a listed interface, select it and click the Edit Row button to open the Edit Failover Interface Configuration Dialog Box (FWSM), page K-82.
Use the Hostname policy to enter a host name and domain name to be used by the firewall device after the configuration file is deployed.
When you set a host name for the security appliance, that name appears in the command line prompt. If you establish sessions to multiple devices, the host name helps you keep track of where you enter commands. The default host name depends on your platform.
For multiple-context mode, the host name that you set in the system execution space appears in the command line prompt for all contexts. The host name 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.
Related Topics
Step 1 Select the firewall device for which you want to configure host name settings.
Step 2 Select Platform > Device Admin > Hostname from the Device Policy selector.
The Hostname page is displayed. For a description of the fields on this page, see Table K-68 on page K-92.
Step 3 Enter the name you want to use for the device in the Host Name field.
Note We recommend that you use a unique host name for each device you create. The device name can be up to 63 alphanumeric (U.S. English) characters and can include any of the following special characters: ` () + -,. / : =.
Step 4 Optionally, enter a valid Domain Name System (DNS) domain name for the device; for example, cisco.com.
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.
Step 1 Select the system context of an FWSM in multiple-context mode.
Step 2 Select Resources from the Device Policy selector.
The Resources page is displayed. For a description of the fields on this page, see Resources Page, page K-92.
The Server Access section contains pages for configuring server access on firewall devices. For more information, see the following topics:
The AUS page lets you configure a security appliance to be updated remotely from a server that supports the Auto Update specification. Auto Update lets you apply configuration changes and software updates to the device automatically from a remote location.
Related Topics
•Add and Edit Auto Update Server Dialog Boxes, page K-98
Follow these steps to configure Auto Update polling on this device:
Step 1 Access the AUS page by doing one of the following:
•(Device view) Select Platform > Device Admin > Server Access > AUS from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > AUS from the Policy Types selector. Right-click AUS and choose New AUS Policy to create a policy, or select an existing policy from the Policies selector.
For a description of the fields on this page, see Table K-71 on page K-97.
Step 2 Add and edit AUS server definitions, as necessary. Refer to Add and Edit Auto Update Server Dialog Boxes, page K-98 for more information about this step.
Step 3 Choose a Device ID Type, and provide related information if necessary.
This is the method used to identify this device to the AUS server; choose:
•Hostname—The host name of this device is used.
•Serial Number—The serial number of this device is used.
•IP Address—The IP address of the specified interface is used: an Interface field appears; enter or Select the desired device interface.
•MAC Address—The MAC address of the specified interface is used: an Interface field appears; enter or Select the desired device interface.
•User Defined—A unique user-specified ID is used: a User Defined field appears; enter an arbitrary alphanumeric string.
Step 4 Choose a Poll Type, and provide related information as necessary.
If you choose At Specified Frequency, provide a Poll Period, which is the number of minutes the firewall device waits between polls of the AUS server.
If you choose At Scheduled Time, the following options are displayed. (This option is effective only on ASA/PIX devices running version 7.2 or later.)
•Days of the week - Select one or more days on which the device is to poll the AUS server.
•Polling Start Time in Hours - The hour at which polling is to begin on the selected days; based on a 24-hour clock.
•Polling Start Time in Mins - The minute within the chosen hour when polling is to begin.
•Enable Randomization of the Start Time - Select this option to specify a random polling window; the Randomization Window field is enabled.
–Randomization Window - The maximum number of minutes the device can use to randomize the specified polling time. This is accomplished by adding a random number of minutes between zero and this value to the poll start time.
Step 5 Enter a Retry Count, which is the number of times the device will try to poll the AUS server for new information. Optional; if you enter zero or leave this field blank, the device will not retry after a failed poll attempt.
Step 6 If you entered a Retry Count, enter a Retry Period, which is the number of minutes the device will wait to re-poll the AUS server if the previous attempt failed.
Step 7 If you select Disable Device After, if no response is received from the AUS server within the specified Timeout period, the security appliance will stop passing traffic.
This is a brute-force method of requiring that the device receive AUS updates.
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 You cannot enable a DHCP relay agent on an interface that has a DHCP relay server configured for it.
The DHCP relay agent works only with external DHCP servers; it will not forward DHCP requests to a security appliance interface configured as a DHCP server.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > DHCP Relay from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > DHCP Relay from the Policy Types selector. Right-click DHCP Relay and choose New DHCP Relay Policy to create a policy, or select an existing policy from the Policies selector.
The DHCP Relay page is displayed. For a description of the fields on this page, see Table K-73 on page K-100.
Step 2 For each interface on which you want to enable a DHCP Relay Agent:
a. Click the Add Row button for the DHCP Relay Agent table to open the Configure DHCP Relay Agent Parameters dialog box.
b. Enter the name of the interface.
c. Check Enable DHCP Relay Agent.
d. To configure the DHCP relay agent to modify the default router address in the information returned from the DHCP server, check Set Route. When this option is selected, the DHCP relay agent substitutes the address of the selected interface for the default router address in the information returned from the DHCP server.
e. Click OK.
The Configure DHCP Relay Agent Parameters dialog box closes and the interface is added to the DHCP Relay Agent table.
Step 3 For each DHCP relay server that you want to define:
a. Click the Add Row button for the DHCP Relay Servers table to open the Configure DHCP Relay Server Parameters dialog box.
b. Enter the IP address of a configured, external DHCP server.
c. Enter the name of the interface to which the specified DHCP server is attached.
d. Click OK.
The Configure DHCP Relay Server Parameters dialog box closes and the server is added to the DHCP Relay Servers table.
Step 4 Enter the amount of time, in seconds, allowed for DHCP address negotiation.
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 The security appliance DHCP server does not support BOOTP requests.
In multiple-context mode, you cannot enable a 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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > DHCP Server from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > DHCP Server from the Policy Types selector. Right-click DHCP Server and choose New DHCP Server Policy to create a policy, or select an existing policy from the Policies selector.
The DHCP Server page is displayed. For a description of the fields on this page, see Table K-76 on page K-102.
Step 2 Enter the global DHCP server settings:
a. Enter the ping timeout in milliseconds.
b. Enter the lease length in seconds.
c. To enable auto-configuration, check Enable auto-configuration and enter the name of the interface on which the DHCP client is enabled.
d. To define the values that the server communicates to DHCP clients, or to override the auto-configuration settings:
•Enter the domain name.
•Enter the IP address of the primary DNS server.
•Enter the IP address of an alternate DNS server.
•Enter the IP address of the primary WINS server.
•Enter the IP address of an alternate WINS server.
Step 3 To define global DDNS update options (available only on ASA/PIX 7.2 and higher), select Enable Dynamic DNS Update and provide the global settings:
•Select the type of resource-record updating: PTR Record only, or A Record and PTR Record.
•You also can select Override DHCP Client Request. If selected, DHCP server updates override any updates requested by DHCP clients.
Step 4 For each interface on which you want to enable DHCP server:
a. Click the Add Row button to open the Add DHCP Server Interface Configuration dialog box. See Add/Edit DHCP Server Interface Configuration Dialog Boxes, page K-104 for detailed information about this dialog box.
b. Enter the name of the interface.
c. Enter the beginning and ending IP addresses, separated by a hyphen, for the range of addresses that this DHCP server will use when assigning IP addresses.
d. Check Enable DHCP Server.
e. To enable DDNS updating on this interface, select Enable Dynamic DNS Update and select the type of resource-record updating: PTR Record only, or A Record and PTR Record.
You also can select Override DHCP Client Request. If selected, DHCP server updates override any updates requested by DHCP clients.
f. Click OK to close the dialog box and add the interface to the DHCP Server Interface Configuration table.
Step 5 To manage specific DHCP server advanced options, click the Advanced button to open the Add/Edit DHCP Server Advanced Configuration Dialog Box, page K-104.
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.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > DNS from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > DNS from the Policy Types selector. Right-click DNS and choose New DNS Policy to create a policy, or select an existing policy from the Policies selector.
The DNS page is displayed. For a description of the fields on this page, see Table K-80 on page K-107.
Step 2 For each DNS server group that you want to define:
a. Click the Add Row button to open the Add DNS Server Group dialog box.
b. Enter the name of the DNS server group.
c. For each DNS server that you want to define for this DNS server group:
•Click the Add button to open the Add DNS Server dialog box.
•Enter the IP address or the object name of the DNS server.
•Click OK.
d. Enter the number of times, from 0 to 10, to retry the list of DNS servers when the firewall device does not receive a response.
e. Enter the amount of time, from 1 to 30 seconds, to wait before trying the next DNS server in the list.
f. Enter a valid DNS domain name for the server; for example "example.com."
g. Click OK.
The Add DNS Server Group dialog box closes and the server group is added to the DNS Server Groups table.
Step 3 To specify the interfaces on which you want to enable DNS lookup:
a. Click Edit to open the Edit Interfaces dialog box.
b. Enter the names of the interfaces on which you want to enable DNS look-up, separated by commas.
c. Click OK.
The Edit Interfaces dialog box closes and the specified interfaces are added to the DNS Lookup Interfaces list.
Step 4 (ASA/PIX 7.0(5), 7.2(x) and 8.x only) To enable DNS Guard for the selected device or shared policy, check Enable DNS Guard. This command is effective only on interfaces for which DNS inspection is disabled. When DNS inspection is enabled, the DNS guard function is always performed.
Note In releases prior to 7.0(5), the DNS guard functions are always enabled regardless of the configuration of DNS inspection.
Dynamic DNS (DDNS) provides IP-address and domain-name mapping updates so hosts can find each other even though their DHCP-assigned IP addresses may change frequently. Beginning with the version 7.2(3), Cisco security appliances can generate DDNS updates. The DDNS page is where you configure this feature.
The DDNS mappings are maintained on the DHCP server in two types of resource records (RRs): the address or A records contain the name-to-IP-address mappings, while the pointer or PTR records map addresses to host names.
Related Topics
•Add/Edit DDNS Interface Rule Dialog Box, page K-110
Follow these steps to configure Dynamic DNS on the selected appliance:
Step 1 Use one of the following methods to access the DDNS page:
•(Device view) Select Platform > Device Admin > Server Access > DDNS from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > DDNS from the Policy Types selector. Select an existing policy from the Policies selector, or right-click DNS and choose New DNS Policy to create a new policy.
The DDNS page is displayed. For a description of the fields on this page, see DDNS Page, page K-109.
Step 2 Add, edit, and delete DDNS interface rules, as necessary:
•To define a new rule, click the Add Row button to open the Add/Edit DDNS Interface Rule Dialog Box, page K-110.
•To edit an existing rule, select the desired entry in the Interface rules list and then click the Edit Row button to open the Add/Edit DDNS Interface Rule Dialog Box, page K-110.
•To delete an existing rule, select the desired entry in the list and then click the Delete Row button. A confirmation dialog box may appear; click OK to delete the rule.
Step 3 Choose an option for DHCP Client requests DHCP Server to update records: Not Selected, Only PTR Record, Both A and PTR Record, or No Update. This is the global setting for the appliance.
Step 4 Enter or Select the appliance's DHCP Client ID Interface, for communications with the DHCP server.
Step 5 Select Enable DHCP Client Broadcast.
Network Time Protocol (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 Time derived from an NTP server overrides any time set manually in the Clock panel.
Related Topics
•NTP Server Configuration Dialog Box, page K-113
Step 1 Access the NTP page by doing one of the following:
•(Device view) Select Platform > Device Admin > Server Access > NTP from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > NTP from the Policy Types selector. Select an existing policy from the Policies selector, or right-click NTP and choose New NTP Policy to create a new policy.
The NTP page is displayed. For a description of the fields on this page, see Table K-88 on page K-112.
Step 2 For each NTP server that you want to define:
a. Click the Add Row button to open the NTP Server Configuration Dialog Box, page K-113.
b. Enter the IP address of the NTP server.
c. To set this server as the preferred server, check Preferred.
d. Enter the name of the outgoing interface for NTP packets.
e. If you want to use MD5 authentication for communicating with the NTP server:
•Specify the key ID for this authentication key in the Key Number list. The NTP server packets must also use this key ID. If you previously configured a key ID for another server, you can select it in the list; otherwise, type a number between 1 and 4294967295.
•To set this key as a trusted key, check Trusted.
•Enter the authentication key as a string of up to 32 characters in the Key Value and Confirm fields.
f. Click OK.
The NTP Server Configuration dialog box closes and the server is added to the table.
Use the SMTP Server page to specify the IP address of an SMTP server and, optionally, the IP address of a backup server.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > SMTP Server from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > SMTP Server from the Policy Types selector. Right-click SMTP Server and choose New SMTP Server Policy to create a policy, or select an existing policy from the Policies selector.
The SMTP Server page is displayed. For a description of the fields on this page, see Table K-90 on page K-114.
Step 2 Enter the IP address of the SMTP server in the Primary Server IP Address field.
Step 3 To specify a secondary server, enter the IP address of the secondary SMTP server in the Secondary Server IP Address field.
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 name of the file to which the configuration will be written.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > TFTP Server from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > Server Access > TFTP Server from the Policy Types selector. Right-click TFTP Server and choose New TFTP Server Policy to create a policy, or select an existing policy from the Policies selector.
The TFTP Server page is displayed. For a description of the fields on this page, see Table K-91 on page K-115.
Step 2 Enter the name of the interface that will use these TFTP server settings.
Step 3 Enter the IP address of the TFTP server.
Step 4 Enter the path on the TFTP server, beginning with a forward slash (/) and ending with the file name, to which the running configuration will be written.
Example TFTP server path:
/tftpboot/config/test_config
Note The path must begin with a forward slash (/).
The User Accounts page lets you manage the device's Local user database. User accounts in the Local database can be used in conjunction with the Authentication, Authorization, Accounting (AAA) functions to determine "who is allowed to do what" on the device. Refer to Configuring AAA for more information.
Related Topics
•User Accounts Page, page K-115
•Add/Edit User Account Dialog Box, page K-115
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > User Accounts from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Device Admin > User Accounts from the Policy Types selector. Right-click User Accounts and choose New User Accounts Policy to create a policy, or select an existing policy from the Policies selector.
The User Accounts page is displayed. For a description of the fields on this page, see Table K-92 on page K-115.
Step 2 For each user account you want to define:
a. Click the Add Row button to open the Add/Edit User Account Dialog Box, page K-115.
b. Enter a user name of at least four characters. Entries are case-sensitive.
c. Enter the user's password in the Password and Confirm fields. Passwords must be at least three characters, and no more than 32 characters. Entries are case-sensitive.
d. Select a privilege level for the user account.
e. Click OK to close the dialog box and add the new user to the User Accounts list.
The Logging feature lets you enable and manage NetFlow "collectors," and enable system 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. 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:
•Syslog
–Configuring Rate Limit Levels
A device configured for NetFlow data export captures flow-based traffic statistics on the device. This information is periodically transmitted from the device to a NetFlow collection server, in the form of User Datagram Protocol (UDP) datagrams.
The NetFlow page lets you enable NetFlow export on the selected device, and define and manage NetFlow "collectors" to which collected flow information is transmitted.
Note NetFlow data export is available only the ASA 5580.
Related Topics
•Adding and Editing NetFlow Collectors
Step 1 Access the NetFlow page by doing one of the following:
•(Device view) Select Platform > Logging > NetFlow from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Logging > NetFlow from the Policy Types selector. Select an existing policy from the Policies selector, or right-click NetFlow and choose New NetFlow Policy to create a new policy.
For a description of the fields on this page, see NetFlow Page, page K-117.
Step 2 Select Enable Flow Export to enable NetFlow on the security appliance.
Step 3 Specify a Template Export Interval in minutes.
This is the frequency at which flow information is sent to the collectors. Can be from one to 3600 minutes; default is 30.
Step 4 Define and manage NetFlow collectors, as follows:
•To define a new collector, click the Add Row button at the bottom of the NetFlow page to open the Add Collector dialog box (described in Adding and Editing NetFlow Collectors).
•To edit an existing collector, select the desired entry in the Collectors list and then click the Edit Row button at the bottom of the NetFlow page to open the Edit Collector dialog box (described in Adding and Editing NetFlow Collectors).
•To delete an existing collector, select the desired entry in the list and then click the Delete Row button. A confirmation dialog box may appear; click OK to delete the collector.
Use the Add Collector dialog box to define a new NetFlow "collector." Note that with the exception of the title, the Edit Collector dialog box is identical to the Add Collector dialog box. The following procedure applies to both.
Note NetFlow data export is available only the ASA 5580.
Follow these steps to define or edit a NetFlow collector.
Step 1 Enter or Select the device Interface through which the collector is contacted.
Step 2 Enter or Select the Collector ID; that is, the IP address or network name of the server to which NetFlow packets will be sent.
Step 3 Enter the number of the UDP port on the specified Collector to which the NetFlow packets will be sent. Values can range from 1 to 65535; the default is 2055.
Step 4 Click OK to close the Add (Edit) Collector dialog box and return to the NetFlow page.
The E-Mail Setup page (PIX 7.0/ASA Only) 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.
Related Topics
•E-Mail Setup Page, page K-118
•Add/Edit Email Recipient Dialog Box, page K-119
Step 1 Select Platform > Logging > Syslog > E-Mail Setup (PIX7.0/ASA Only).
The E-Mail Setup page appears.
Step 2 Verify or enter the address from which these notifications will be sent in the Source Email Address field.
Step 3 Do one of the following:
•To add a new recipient, click the Add Row button.
•To edit the settings of an existing recipient, select the check box for that recipient, then click the Edit Row button.
The Add/Edit Email Recipient Dialog Box, page K-119 opens.
Step 4 Specify the recipients e-mail address in the Destination Email Address field.
Step 5 Select the severity level of the events that should be sent to the recipient in the Severity list.
Step 6 Click OK.
The recipient rule appears in the table on the E-Mail setup page.
The Event Lists page (PIX 7.0/ASA Only) 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 (for 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:
•Class
•Severity
•Message ID
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.
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.
Related Topics
•Add/Edit Event List Dialog Box, page K-121
Step 1 Select Platform > Logging > Syslog > Event Lists (PIX 7.0/ASA Only).
The Events Lists page appears.
Step 2 Do one of the following:
•To add a new event list definition, click the Add Row button.
•To edit an existing event list definition, select the check box for the row, then click the Edit Row button.
The Add/Edit Event List Dialog Box, page K-121 appears.
Step 3 Specify a unique name for the event list in the Event List Name field.
Step 4 To add events based on system event classes and severity level pairings, click Add Row under Event Class/Severity Filters, and do the following:
a. Select the event class in the Event Class list.
b. Select the severity level of the events that you want to generate in the Severity list.
c. Click OK to add this new filter.
Step 5 Repeat Step 4 as needed.
Step 6 To add events based on the message ID, click Add Row under Message ID Filters, and do the following:
a. Enter one or more message ID in the Message IDs field.
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
•http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_system_message_guides_list.html
ASA
•http://www.cisco.com/en/US/products/ps6120/products_system_message_guides_list.html
FWSM
•http://www.cisco.com/en/US/products/hw/modules/ps2706/ps4452/tsd_products_support_model_home.html
b. Click OK to add this new filter.
Step 7 Repeat as needed
Step 8 Click OK.
The event list appears in the table on the Event List page.
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.
Related Topics
•Logging Filters Page, page K-123
•Edit Logging Filters Dialog Box, page K-124
Step 1 Select Platform > Logging > Syslog > Logging Filters to display the Logging Filters page.
Step 2 Open the Edit Logging Filters Dialog Box, page K-124:
•To add a new filter rule, click the Add Row button.
•To edit the settings defined for a rule, select the check box for the filter rule, then click the Edit Row button.
Step 3 Select the destination for this filter rule in the Logging Destination list.
Step 4 To specify settings that apply to all syslog event classes, do one of the following:
•To specify the highest level of events to log, click the Filter on severity radio button and then select the appropriate level in the list box that becomes editable.
Severity levels are aggregate; they add events to lower severity levels. This list organizes from sparse to detailed in ascending order.
•To specify that you want this device to generate only those events defined in an event list, click the Use event list radio button and then select the appropriate event list in the list box.
•To disable event logging for this security appliance, click the Disable logging radio button.
Step 5 To define custom event levels based on a system-defined event class, select the event class and the associated level of events, and click the >> (Add) button.
The custom event level appears in the list.
Step 6 Repeat as needed.
Step 7 Click OK.
The logging filter rule appears in the table.
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, and logging to longer-term storage devices, FTP server or Flash, before purging the internal buffer.
Related Topics
•Logging Setup Page, page K-125
Step 1 Select Platform > Logging > Syslog > Logging Setup to display the Logging Setup page.
Step 2 Check Enable Logging.
This option enables logging on the security appliance.
Step 3 To enable logging on the failover unit paired with this security appliance, select the Enable logging on the standby failover unit check box.
Step 4 To enable EMBLEM format, or to send debug messages as part of the syslog messages, select the corresponding check boxes.
If you enable EMBLEM, you must use the UDP protocol to publish syslog messages. It is not compatible with TCP.
Step 5 To write the internal buffer data to an FTP server for future processing prior to clearing the buffer, do the following:
a. Check FTP Server Buffer wrap.
b. Enter the IP address of the FTP server in the IP Address field.
c. Enter the user name of the account used to log into the FTP server in the User Name field.
d. Enter the path in the Path field, relative to the FTP root, where the file should be stored.
e. Enter and confirm the password used to authenticate the user name.
Step 6 To write the internal buffer data to Flash for future processing prior to clearing the buffer, do the following:
a. Check Flash.
b. Specify the maximum amount of memory to allocate to the storage of internal buffer data.
c. Specify the minimum memory that should remain free on the Flash drive. If this minimum value cannot be retained while writing out the data from the internal buffer, the messages will be pruned to meet the space requirements.
Step 7 To specify the maximum queue size maintained on the appliance for viewing by an ASDM client, enter that value in the Message Queue Size (Messages) field.
The Rate Limit page lets you specify the maximum number of log messages of specific types (e.g., "alert" or "critical"), and messages with specific Syslog IDs, that can be generated within given periods of time. You can specify individual limits for each logging level, and each Syslog message ID. If the settings conflict, the Syslog message ID limits take precedence.
The Add/Edit Rate Limited Syslog Message Dialog Box, page K-128 is used to specify the maximum number of messages that can be generated for a particular Syslog message ID within a given period of time.
The Add/Edit Rate Limit for Syslog Logging Levels Dialog Box, page K-127 is used to specify the maximum number of messages that can be generated for a particular Syslog logging level within a given period of time.
Related Topics
•Add/Edit Rate Limit for Syslog Logging Levels Dialog Box, page K-127
•Add/Edit Rate Limited Syslog Message Dialog Box, page K-128
Follow these steps to manage rate limits for message logging:
Step 1 Access the Rate Limit page by doing one of the following:
•(Device view) Select Platform > Logging > Syslog > Rate Limit from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Logging > Syslog > Rate Limit from the Policy Type selector. Select an existing policy from the Shared Policy selector, or right-click Rate Limit to create a new policy.
Step 2 Add, edit and delete rate limits for Syslog logging levels:
•To specify the maximum number of messages that can be generated within a given period of time for particular logging level, click the Add Row button under the Rate Limits for Syslog Logging Levels table to open the Add/Edit Rate Limit for Syslog Logging Levels Dialog Box, page K-127. Choose a logging level and define a rate limit.
•To edit the rate limit for a particular logging level, select the appropriate entry in the Rate Limits for Syslog Logging Levels table, and then click the Edit Row button under the table to open the Add/Edit Rate Limit for Syslog Logging Levels Dialog Box, page K-127. Alter the rate limit as necessary.
•To delete a rate limit entry from the Rate Limits for Syslog Logging Levels table, select it and then click the Delete Row button under the table. A confirmation dialog box may be displayed; click OK to delete the entry.
Step 3 Add, edit and delete limits for log messages according to message IDs:
•To specify the maximum number of messages that can be generated within a given period of time for particular message ID, click the Add Row button under the Individually Rate Limited Syslog Messages table to open the Add/Edit Rate Limited Syslog Message Dialog Box, page K-128. Choose a Syslog message ID and define a rate limit.
•To edit the rate limit for a particular Syslog message ID, select the appropriate entry in the Individually Rate Limited Syslog Messages table, and then click the Edit Row button under the table to open the Add/Edit Rate Limited Syslog Message Dialog Box, page K-128. Alter the rate limit as necessary.
•To delete a message limit entry from the Individually Rate Limited Syslog Messages table, select it and then click the Delete Row button under the table. A confirmation dialog box may be displayed; click OK to delete the entry.
The Server Setup page lets you configure the syslog server that runs on the security appliance. The settings that you specify on this page define possible behaviors for 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.
Related Topics
•Server Setup Page, page K-128
•Add/Edit Syslog Message Dialog Box, page K-130
Step 1 Select Platform > Logging > Syslog > Server Setup to display the Server Setup page.
Step 2 Select the log facility to use for this security appliance in the Facility field.
Step 3 To include a timestamp with each syslog message, check Enable Timestamp on Each Syslog Message.
Step 4 To specify a unique device ID as part of the syslog message, check Enable Syslog Device ID and do one of the following:
•To identify the device using the interface name from which the syslog messages are sent, click the Interface radio button and enter (or select) the interface name in the related text box.
•To provide a custom name, click the User Defined ID radio button and enter the name in the related text box.
•To use the host name of the security appliance, click the Host Name radio button.
Step 5 Open the Add/Edit Syslog Message Dialog Box, page K-130 to modify the syslog settings:
•To add a new row, click the Add Row button.
•To edit a row, select the row and then click the Edit Row button.
Step 6 Select the message for which you want to change the current settings in the Syslog ID list.
Step 7 To change the logging level of this message, select the new level in the Logging Level list.
Step 8 To enable the generation of this message, deselect Suppress.
Step 9 Click OK.
The rule appears in the table.
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 Syslog messages also can be sent to CS-MARS and third-party products.
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 Configuring Logging Setup.
Related Topics
•Syslog Servers Page, page K-131
•Add/Edit Syslog Server Dialog Box, page K-132
Step 1 Select Platform > Logging > Syslog > Syslog Servers to display the Syslog Servers page.
Step 2 Do one of the following:
•To add a new syslog target, click the Add Row button.
•To edit an existing syslog target, select the check box for the row, then click the Edit Row button.
Step 3 Enter or select the interface name in the Interface field.
The list displays all interfaces defined at the current scope.
Step 4 Enter or select the IP address of the syslog server in the IP Address field.
Step 5 Determine whether to use UDP or TCP, then click the appropriate radio button under Protocol.
Step 6 Enter the port from which the security appliance sends either UDP or TCP syslog messages. The port must be the same port on which the syslog server listens.
•TCP—1470 (Default). TCP ports work only with a security appliance syslog server.
•UDP—514 (Default).
Step 7 To generate syslog messages using the EMBLEM format, select the Log messages in Cisco EMBLEM format check box.
To enable this option, you must select UDP protocol to publish messages to this syslog server.
Step 8 Click OK.
The definition appears in the Syslog Servers table.
The Multicast section contains pages for defining multicast routing settings for firewall devices. For more information, see the following topics:
•Configuring Multicast Boundary Filters
The Enable PIM and IGMP page lets you enable or disable Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM) on all interfaces on the security appliance. 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.
Step 1 Do one of the following:
•(Device view) Select Platform > Multicast > Enable PIM and IGMP from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Multicast > Enable PIM and IGMP from the Policy Types selector. Select an existing policy from the Policies selector, or create a new policy.
Step 2 To enable Internet Group Management Protocol and Protocol Independent Multicast on the security appliance, select Enable PIM and IGMP.
This enables PIM and IGMP on all interfaces on the security appliance. Deselect this option to disable PIM and IGMP on the device.
Note that you can disable IGMP and PIM on a per-interface basis; see Configure IGMP Parameters Dialog Box, page K-135 and Add/Edit PIM Protocol Dialog Box, page K-143 for more information.
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.
The IGMP page provides these tabs:
•Protocol - This 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 IGMP Page - Protocol Tab, page K-134.
•Access Group - Access groups 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 IGMP Page - Access Group Tab, page K-136.
•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:
–Use the IGMP Page - Join Group Tab, page K-138 tab to configure the interface as a member of the multicast group. With this method, the security appliance accepts the multicast packets in addition to forwarding them to the specified interface.
–Use the Static Group tab to configure the security appliance to be a statically connected member of a group. With this method, the security appliance does not accept the packets itself, but only forwards them. Therefore, this method allows fast switching. The outgoing interface appears in the IGMP cache, but itself is not a member of the multicast group.
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 IGMP Page - Static Group Tab, page K-137.
•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 If you simply want to forward multicast packets for a specific group to an interface without the security appliance accepting those packets as part of the group, see IGMP Page - Static Group Tab, page K-137.
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 IGMP Page - Join Group Tab, page K-138.
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 Routes Page, page K-139.
Related Topics
•Configuring Multicast Policies on Firewall Devices
•Multicast Routes Page, page K-139
Step 1 Do one of the following:
•(Device view) Select Platform > Multicast > Multicast Routing from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Multicast > Multicast Routing from the Policy Types selector. Right-click Multicast Routing and choose New Multicast Routing Policy to create a policy, or select an existing policy from the Policies selector.
The Multicast Routing page is displayed. For a description of the fields on this page, see Table K-121 on page K-140.
Step 2 To add a multicast route, click the Add Row button.
The Add/Edit MRoute Configuration dialog box is displayed.
Step 3 For instructions on completing this dialog box, see Add/Edit MRoute Configuration Dialog Box, page K-140.
On an ASA running version 7.2(1) or later, you can use the Multicast Boundary Filter page to configure the appliance to act as a boundary between multicast domains. The ASA compares multicast group addresses to an access-filter list, blocking all multicast traffic except that specifically permitted by the list.
Related Topics
•Configuring Multicast Policies on Firewall Devices
•Multicast Boundary Filter Page, page K-140
Step 1 Do one of the following:
•(Device view) Select Platform > Multicast > Multicast Boundary Filter from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Multicast > Multicast Boundary Filter from the Policy Types selector. Select an existing policy from the Policy selector, or you can right-click Multicast Boundary Filter and choose New Multicast Boundary Filter Policy to create a policy.
The Multicast Boundary Filter page is displayed. For a description of the fields on this page, see Multicast Boundary Filter Page, page K-140.
Step 2 To add a multicast boundary filter, click the Add Row button.
The Add/Edit MBoundary Configuration dialog box is displayed.
Step 3 For instructions on completing this dialog box, see Add/Edit MBoundary Configuration Dialog Box, page K-141.
Routers use Protocol Independent Multicast (PIM) to maintain tables for forwarding multicast datagrams.
When you enable multicast routing on a security appliance, PIM is enabled on all interfaces by default. You can disable PIM on a per-interface basis.
The PIM page provides these tabs:
•Protocol - This tab displays the interface-specific PIM properties. From this tab, you can you change the PIM properties for an interface. For more information, see PIM Page - Protocol Tab, page K-143.
•Neighbor Filter - This tab lists the neighbor filters defined for individual interfaces (ASA 7.2(1) or later). These filters are defined and managed with the Add/Edit PIM Neighbor Filter dialog box, which is accessed from this tab. See PIM Page - Neighbor Filter Tab, page K-144 for more information.
•Bidirectional Neighbor Filter - This tab lists the bidirectional neighbor filters defined for individual interfaces (ASA 7.2(1) or later). These filters are defined and managed with the Add/Edit PIM Bidirectional Neighbor Filter dialog box, which is accessed from this tab. See PIM Page - Bidirectional Neighbor Filter Tab, page K-145 for more information.
•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 registration 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 PIM Page - Rendezvous Points Tab, page K-147.
•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 PIM Page - Route Tree Tab, page K-149.
•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 registration messages. For more information, see PIM Page - Request Filter Tab, page K-150.
The Routing section contains pages for defining routing settings for firewall devices. For more information, see the following topics:
The No Proxy ARP page lets you 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.
Step 1 Do one of the following:
•(Device view) Select Platform > Routing > No Proxy ARP from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Routing > No Proxy ARP from the Policy Types selector. Right-click No Proxy ARP and choose New No Proxy ARP Policy to create a policy, or select an existing policy from the Policies selector.
The No Proxy ARP Page, page K-152 is displayed.
Step 2 Enter the names of the interfaces for which proxy ARP is disabled. By default, proxy ARP is enabled for all interfaces. Separate multiple interfaces with commas.
You can click Select to choose the interfaces from a list of interfaces defined on the device, or from the interface roles defined in Cisco Security Manager.
Open Shortest Path First (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 whenever 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 Only type 3 LSAs can be filtered. If you configure the security appliance as an ASBR in a private network, it will send type 5 LSAs describing private networks, which will get flooded to the entire AS including public areas.
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.
Step 1 Do one of the following:
•(Device view) Select Platform > Routing > OSPF from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Routing > OSPF from the Policy Types selector. Right-click OSPF and choose New OSPF Policy to create a policy, or select an existing policy from the Policies selector.
The OSPF page is displayed. For a description of the fields on this page, see OSPF Page, page K-153.
Routing Information Protocol (RIP) is a dynamic routing protocol, or more precisely, an interior gateway protocol that is based on distance vectors. RIP uses hop count as the metric for path selection. When RIP is enabled on an interface, the interface exchanges RIP broadcast packets with neighboring devices to dynamically learn about and advertise routes. These RIP packets contain the information of the destination networks that the gateways can reach and the number of gateways that a packet must travel through to reach the destination.
Tip For detailed general information see the Configuring RIP article on the Cisco Documentation website.
Cisco Security Manager supports 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 You cannot enable RIP if you have OSPF processes running.
Limitations
RIP has the following limitations:
•Cisco Security Manager cannot pass RIP updates between interfaces.
•RIP Version 1 does not support variable-length subnet masks.
•RIP has a maximum hop count of 15. A route with a hop count greater than 15 is considered unreachable.
•RIP convergence is relatively slow compared to other routing protocols.
RIP Version 2 Notes
The following information applies to RIP Version 2 only:
•If using neighbor authentication, the authentication key and key ID must be the same on all neighbor devices that provide RIP version 2 updates to the interface.
•With RIP version 2, the security appliance transmits and receives default route updates using the multicast address 224.0.0.9. In passive mode, it receives route updates at that address.
•When RIP version 2 is configured on an interface, the multicast address 224.0.0.9 is registered on that interface. When a RIP version 2 configuration is removed from an interface, that multicast address is unregistered.
Step 1 Do one of the following:
a. (Device view) Select Platform > Routing > RIP from the Device Policy selector.
b. (Policy view) Select PIX/ASA/FWSM Platform > Routing > RIP from the Policy Types selector.
Right-click RIP and choose New RIP Policy to create a policy. (Alternatively you can select an existing policy to edit from the Policies selector.)
The Create a Policy dialog box is displayed.
In the Policy Name field, enter a name for the new policy.
Use the Version field to select from the two RIP command versions available, as follows:
•PIX/ASA 6.3-7.1 and FWSM
•PIX/ASA 7.2 and Later
Click OK.
Step 2 Complete the fields required:
For a description of the fields on this page for the PIX/ASA 6.3-7.1 and FWSM RIP command version, see RIP Page for PIX/ASA 6.3-7.1 and FWSM, page K-176.
For a description of the fields on this page for the PIX/ASA 7.2 and Later command version, see RIP Page for PIX/ASA 7.2 and Later, page K-178.
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 use the shortened form: 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 value of 1 unless you are sure of the number of hops to the gateway router.
Step 1 Do one of the following:
•(Device view) Select Platform > Routing > Static Route from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Routing > Static Route from the Policy Types selector. Right-click Static Route and choose New Static Route Policy to create a policy, or select an existing policy from the Policies selector.
The Static Route page is displayed. For a description of the fields on this page, see Table K-164 on page K-184.
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 or disable Floodguard on a PIX 6.3 or FWSM 2.x 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 in the following order, depending on urgency:
1. Timewait
2. LastAck
3. FinWait
4. Embryonic
5. Idle
Floodguard is enabled by default.
Anti-Spoofing
Unicast RPF guards against IP spoofing (a packet using 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.
With 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:
•ICMP packets have no session, so each packet is checked.
•UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets arriving during the session are checked using an existing state maintained as part of the session. Non-initial packets are checked to ensure they arrived on the same interface used by the initial packet.
Fragment Settings
Fragment settings provide additional management of packet fragmentation and improve compatibility with the Network File System (NFS).
Related Topics
•Add/Edit General Security Configuration Dialog Box, page K-187
Step 1 Do one of the following:
•(Device view) Select Platform > Security > General from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Security > General from the Policy Types selector. Right-click General and choose New General Policy to create a policy, or select an existing policy from the Policies selector.
The General page is displayed. For a description of the fields on this page, see Table K-166 on page K-187.
Step 2 To disable floodguard, check the Disable Floodguard (PIX 6.3 and FWSM 2.x only) box.
Step 3 To configure default fragment settings for this policy:
a. Check Enable Default Settings.
b. Enter the maximum number of packets that can be in the IP re-assembly database waiting for re-assembly. The default is 200.
c. Enter the maximum number of packets into which a full IP packet can be fragmented. The default is 24 packets.
d. Enter the maximum number of seconds to wait for an entire fragmented packet to arrive. The timer starts after the first fragment of a packet arrives. If all fragments of the packet do not arrive by the number of seconds specified, all fragments of the packet that were already received are discarded. The default is 5 seconds.
Step 4 For each interface on which you want to enable anti-spoofing or configure fragment settings:
a. Click the Add Row button to open the Add/Edit General Security Configuration Dialog Box, page K-187.
b. Enter the name of the interface for which you want to enable anti-spoofing, or configure fragment settings.
c. To enable anti-spoofing on the specified interface, check Enable Anti-Spoofing.
d. To override the default fragment settings on the specified interface, check Override Default Fragment Settings and then enter the new value:
•Enter the maximum number of packets that can be in the IP re-assembly database waiting for re-assembly. The default is 200.
•Enter the maximum number of packets into which a full IP packet can be fragmented. The default is 24 packets.
•Enter the maximum number of seconds to wait for an entire fragmented packet to arrive. The timer starts after the first fragment of a packet arrives. If all fragments of the packet do not arrive by the number of seconds specified, all fragments of the packet that were already received are discarded. The default is 5 seconds.
e. Click OK.
The Add General Security Configuration dialog box closes and the interface is added to the table.
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 It is recommended that you do not change these values unless advised to do so by Customer Support.
Related Topics
Step 1 Do one of the following:
•(Device view) Select Platform > Security > Timeouts from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > Security > Timeouts from the Policy Types selector. Right-click Timeouts and choose New Timeouts Policy to create a policy, or select an existing policy from the Policies selector.
The Timeouts page is displayed. For a description of the fields on this page, see Table K-168 on page K-189.
Step 2 To enter a timeout value for a field, select the radio button to the left of the field and then enter the timeout value in the box to the right of the field. For information on valid values and formats, see Table K-168 on page K-189.
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 a specific 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:
•TCP and general connection settings
•Content security control (CSC)
•Application inspection
•Intrusion Prevention Services
•Trusted Flow Acceleration (see About Trusted Flow Acceleration)
•QoS queuing and policing
Details regarding the scope and implementation of particular service policies are beyond the scope of this guide. Detailed information can be found on cisco.com. The following references may be particularly helpful:
•QoS Configuration and Monitoring
•Using Modular Policy Framework
Configuring Service Policy Rules consists of three tasks:
Step 1 Configure a service policy. Create a service policy and determine the interfaces to which the service policy applies. For more information, see Step 1. Configure a Service Policy, page K-193.
Step 2 Configure the traffic class. Specify the criteria you want to use to identify the traffic to which the service policy applies. For more information, see Step 2. Configure the traffic class, page K-194.
Step 3 Configure the actions. Specify the actions that should be taken to protect information or resources, or to perform QoS functionality for the traffic specified in this service policy. For more information, see Step 3. Configure the actions, page K-194.
Trusted Flow Acceleration lets a Firewall Service Module (FWSM) take advantage of the processing power of its switch supervisor to greatly increase packet throughput without forgoing security. Very high-speed communications between trusted hosts are enabled by allowing flows to bypass the FWSM.
The Trusted Flow Accelerator incorporated into the FWSM 4.0(1)+ establishes a secure connection between trusted hosts, and then suspends per-packet analysis. This allows large volumes of information to be transferred in a secure environment, based on policy, in a fraction of the time that would otherwise be required. Once the transaction is completed, the FWSM closes and secures the connection, and re-establishes per-packet analysis between these hosts.
Note Trusted Flow Acceleration (TFA) is supported only in routed firewall mode, for single and multiple contexts. In multiple-context mode, shared interfaces are not supported.
Using Trusted Flow Acceleration
In multiple-context mode, you specify whether a particular context can use Trusted Flow Acceleration (see Add/Edit a Security Context for FWSM). If it is enabled for a context, you can then configure a service policy to specify the traffic to be accelerated within the context configuration (using the Insert/Edit Service Policy (MPC) Rule wizard, and specifically Step 3. Configure the actions, page K-194). An activity validation error is issued if TFA is enabled in IPS, QoS and Connection Rules, but not enabled in a security context.
Note Supervisor-accelerated traffic flows do not support stateful failover; after the FWSM fails over, all flows need to be re-established by the newly active FWSM.
Traffic directed to an FWSM is sent to the FWSM MAC address. When you identify traffic for Trusted Flow Acceleration, for the VLAN on which that traffic resides, the supervisor claims ownership of the FWSM MAC address. All traffic on that VLAN (including traffic that you did not specify for acceleration) is initially checked by the supervisor:
•When traffic matches an acceleration entry on the supervisor, it is processed by the supervisor and then sent out of the switch, bypassing the FWSM.
•For traffic that does not match an entry (new connections for accelerated traffic, and non-accelerated traffic), it is sent on to the FWSM for processing.
This checking on the switch supervisor does not have any performance impact for non-accelerated traffic. For VLANs on which no traffic is identified for acceleration, the supervisor does not claim the FWSM MAC address, and traffic goes to the FWSM normally.
Because the supervisor is less secure than the FWSM, you may want to limit the traffic sent on the supervisor-accelerated path to data that you feel is not at risk. You might also focus on traffic that requires high bandwidths and would otherwise slow the FWSM. For example:
•Bulk FTP downloads
•High-bandwidth file back-ups
•Network Attached Storage (NAS) back-ups
•Grid computing and high-performance computing (HPC)
Note that the following features are not supported for Trusted Flow Acceleration:
•Multicast and asymmetric routing
•Stateful failover
•Transparent firewall mode
•Shared interfaces in multiple-context mode
•Virtual switching
•Distributed-Forwarding-enabled line cards
•Other NetFlow features on Trusted Flow Acceleration VLANs
Related Topics
•Configuring Security Contexts on Firewall Devices
•Add/Edit a Security Context for FWSM
•Configuring Security Policies on Firewall Devices; specifically Step 3. Configure the actions, page K-194
Use the User Preferences Deployment page 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.
Step 1 Do one of the following:
•(Device view) Select Platform > User Preferences > Deployment from the Device Policy selector.
•(Policy view) Select PIX/ASA/FWSM Platform > User Preferences > Deployment from the Policy Types selector. Right-click Deployment and choose New Deployment Policy to create a policy, or select an existing policy from the Policies selector.
The Deployment page is displayed, as described in User Preferences, page K-198.
Step 2 Check Clear XLATE on deployment if you want the translation table cleared when a configuration is deployed to this device.
Note This option is necessary for certain commands to take effect. If these commands are changed, you should make sure this option is enabled for the device. However, clearing the translation table disconnects all current connections that use translations.
You can define multiple security "contexts" on a single security appliance. Each context operates as an independent virtual device, with its own security policy, interfaces and administrators. Multiple contexts are similar to having multiple stand-alone 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 Cisco 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 most of the options you can configure on a stand-alone device. The system administrator adds and manages contexts by configuring them in the system configuration, which, like a single-mode configuration, is the start-up configuration. The system configuration identifies basic settings for the security appliance, but it 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 the context 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:
•Enabling and Disabling Multiple-Context Mode
•Checklist for Configuring Multiple Security Contexts
–Add/Edit a Security Context for PIX or ASA
–Add/Edit a Security Context for FWSM
Cisco Security Manager does not support switching to multiple-context mode on an existing device. To perform this task, you must delete the device from Security Manager, enable multiple-context mode using a device manager or CLI input, and then add the device again to Cisco Security Manager. After the device is added in multiple-context mode, you can add, edit and delete security contexts.
Note When manually defining a multiple-context device, choose Multi from the Contexts list in the Operating System section of the New Device - Device Information dialog box.
Similarly, Cisco Security Manager does not support restoring an existing device to single-context mode. To perform this task, you must delete the device and any of its child contexts from Cisco Security Manager, restore single-context operation using a device manager or CLI input, and then add the device again to Cisco Security Manager.
Note When manually defining a single-context device, choose Single from the Contexts list in the Operating System section of the New Device - Device Information dialog box.
Related Topics
•Configuring Security Contexts on Firewall Devices
•Checklist for Configuring Multiple Security Contexts
–Add/Edit a Security Context for PIX or ASA
–Add/Edit a Security Context for FWSM
Security "contexts" allow a single physical device to act as multiple independent firewalls. Each security context defines a single virtual firewall, complete with its own configuration—and just as with physical devices, each security context must be correctly configured, or overall security can be compromised. Thus, defining and configuring multiple firewalls on the same physical appliance requires special care.
The following checklist outlines the basic steps necessary to configure a firewall device with multiple security contexts. Each of these steps may involve multiple substeps; all steps should be performed in the order presented. For example, you must define interfaces before configuring the various contexts.
|
|
---|---|
Step 1 |
Define interfaces and subinterfaces, or VLANs, on the physical appliance. In this task, you define the interfaces and subinterfaces, or VLANs on FWSMs, that will be allocated to the various security contexts when you create them later. Provide physical interface parameters, such as connection type (Ethernet, gigabit Ethernet, etc.), hardware Port ID, speed, and duplex mode, as well as VLAN ID if defining a subinterface. Result: All interfaces and subinterfaces are defined. For more information, see Configuring Firewall Device Interfaces. |
Step 2 |
Define an admin context for administering the base security appliance. This task is called out separately to ensure you define a context and IP address specifically for administration of the security appliance. The process is the same as defining a security context; however, during the process, be sure to check Admin Context to designate this as the admin context. 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 the Cisco Security Monitoring, Analysis and Response System (CS-MARS), for further processing. Until you associate a specific management IP address with the admin context, the IP address used to manage the security appliance is the one you specified when defining the device. When you specify a Management IP Address with the admin context, it takes precedence over the one on the Device Properties page. Result: The admin context is defined and associated with a physical interface. For more information, see: •Add/Edit a Security Context for PIX or ASA |
Step 3 |
Define each security context, or virtual firewall, on the base appliance. In this task, you define individual security contexts, naming each, assigning a location for its configuration files, and allocating interfaces. Each security context represents a virtual firewall, and its definition includes the interfaces and range of associated VLAN IDs that are under its control. Note While the admin context can operate as a firewall device, it is typically used as such only in single-context mode. Therefore, security contexts are treated as separate entities in this checklist. You cannot add new interfaces or modify the hardware Port value when defining a security context—you simply select previously defined interfaces for allocation to the context. Result: Each security context is defined and associated with a physical interface; the VLANs on which the security context will inspect traffic are also specified. For more information, see: •Add/Edit a Security Context for PIX or ASA |
Step 4 |
Submit/deploy to generate the virtual firewalls as children of the base appliance. You must create the desired contexts on the security appliance before you can begin defining the individual settings of each context. To create contexts on the appliance, you must define them, and then either submit changes in Workflow mode, or deploy the changes to the security appliance in non-Workflow mode. When you create a security context, a "virtual firewall device" appears beneath the original security appliance in the Device View. Each virtual device is indicated by a related device icon with a dotted outline, and its name is the base security appliance name, underscore (_), context name. For example, the virtual device asaMultiRouted_admin would represent the admin context (named "admin") on the security appliance named "asaMultiRouted." Similarly, asaMultiRouted_security1 would represent the security context "security1" on the same base appliance. Result: Your changes are submitted or deployed (depending on the Workflow mode), which in turn creates the admin and security contexts as children of the base security appliance. For more information, see: •Submitting an Activity for Approval, page 7-12 •Working with Deployment and the Configuration Archive, page 17-15 |
Step 5 |
Define additional settings for each security context. You can now complete the definition of each security context by selecting a virtual firewall device and editing available policies, such as access rules, translation options and so on. Result: Each security context is fully defined, ready to operate as a virtual firewall. |
The Security Contexts page lists security contexts configured for the selected device. You can add, edit and delete security contexts from this page.
Before You Begin
Remember, the security appliance must be in multiple-context mode in order for you to configure contexts using Cisco Security Manager. See Enabling and Disabling Multiple-Context Mode for more information.
Follow these steps to manage security contexts:
Step 1 Ensure Device View is your present application view; if necessary, click the Device View button on the toolbar.
Note For more information on using the Device View to configure device policies, see Managing Policies in Device View, page 6-19).
Step 2 Select the appliance you want to configure.
Step 3 Select Security Contexts in the Device Policy selector to display the Security Contexts Page, page K-198.
Note The child contexts of a multiple-mode device are represented using a different icon than firewall devices in single mode.
Step 4 Add, edit and delete contexts, as necessary:
•To define a new context, click the Add Row button at the bottom of the page to open the Add Security Context box.
•To edit an existing context, select the desired entry in the Security Contexts list and then click the Edit Row button at the bottom of the page to open the Edit Security Context dialog box.
•To delete an existing context, select the desired entry in the list and then click the Delete Row button.
Note Deleting the security context will also cause the security context device to be removed from device inventory.
Confirm the deletion of the security context and corresponding security context device.
Note Except for the title, the Add Security Context dialog box and the Edit Security Context dialog box are identical. For PIX/ASA devices, refer to Add/Edit a Security Context for PIX or ASA; for FWSMs, refer to Add/Edit a Security Context for FWSM.
This section describes use of the Add Security Context dialog box and the Edit Security Context dialog box to define and maintain contexts for the currently selected PIX/ASA security appliance. Note that at least one security context must be designated as the admin context.
Note Except for the titles, the Add Security Context dialog box and the Edit Security Context dialog box are identical; the following steps apply to both.
Step 1 Open the Add Security Context dialog box or the Edit Security Context dialog box, as described in Managing Security Contexts.
Step 2 Provide a Name for this context.
Step 3 Description
Step 4 If this context is the admin context, check the Admin Context box.
Step 5 Under Configuration URL, select the file system type and enter the path and name of the file to access for the context configuration.
Step 6 For each interface belonging to this security context, do the following:
a. Click the Add a row button beneath the Interfaces table to open the Allocate Interfaces Dialog Box (PIX/ASA only), page K-202.
b. Under Interfaces, specify the physical interface and sub-interface IDs for which the security context will inspect traffic.
You can select just a physical interface, a single sub-interface (defined as a range of one), or a range of sub-interfaces.
c. To enable an aliased name for ACLs applied to the specified interfaces as part of this security context, check Use aliased names in the security context and then enter a name in the Alias Name field.
d. To show the hardware properties of this context, check the Show hardware properties in context box.
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. Click OK to save the interface settings.
Step 7 If active/active failover is enabled, select the failover group for this context in the Failover Group list.
Step 8 In the Management IP Address field, enter the IP address that Cisco Security Manager should use for communications with this security context, or Select it from a list of available network/host combinations.
Step 9 Click OK to define the security context.
A message box states that the context will appear as a stand-alone device after you perform the Submit operation.
This section describes use of the Add Security Context and Edit Security Context dialog boxes to define and maintain contexts for the currently selected FWSM. Note that at least one security context must be designated as the admin context.
Except for the titles, the Add Security Context dialog box and the Edit Security Context dialog box are identical; the following descriptions apply to both.
Step 1 Open the Add Security Context dialog box or the Edit Security Context dialog box, as described in Managing Security Contexts.
Step 2 Provide a Name for this context.
Step 3 If this context is for an FWSM version 3.1 or later, select the mode (Router or Transparent) in which this context should operate.
Step 4 If this is the admin context, check Admin Context.
Step 5 Enter one or more VLAN IDs for this context. Use commas to separate multiple VLAN IDs.
Step 6 In the Config URL fields, select the file system type and enter the path and name of the file to access for the context configuration.
Step 7 If active/active failover is enabled, select the failover group for this context in the Failover Group list.
Step 8 If desired, provide a Description for this context.
Step 9 In the Management IP Address field, enter the IP address that Security Manager should use for communications with this security context, or click Select to choose it from a list of available network/host combinations.
Step 10 Select Enable Trusted Flow Acceleration to activate Trusted Flow Acceleration for this context. (Available for FWSM 4.0(1)+ in routed-mode only.) See About Trusted Flow Acceleration for more information.
Step 11 Click OK to define the security context.