Usage Guidelines

The shun command lets you block connections from an attacking host. All future connections from the source IP address are dropped and logged until the blocking function is removed manually or by the Cisco IPS sensor. The blocking function of the shun command is applied whether or not a connection with the specified host address is currently active.

If you specify the destination address, source and destination ports, and the protocol, then you drop the matching connection as well as placing a shun on all future connections from the source IP address; all future connections are shunned, not just those that match these specific connection parameters.

If you do not specify a VLAN or an interface, the shun interface will be determined by a route look-up for the shunned IP.

You can only have one shun command per source IP address per interface.

Because the shun command is used to block attacks dynamically, it is not displayed in the ASA configuration.

Whenever an interface configuration is removed, all shuns that are attached to that interface are also removed. If you add a new interface or replace the same interface (using the same name), then you must add that interface to the IPS sensor if you want the IPS sensor to monitor that interface.

Usage Guidelines

This command in CA server mode is similar to the shutdown command in interface mode. At setup time, the local CA server is shutdown by default and must be enabled using the no shutdown command. When you use the no shutdown command for the first time, you enable the CA server and generate the CA server certificate and keypair.

Note	The CA configuration cannot be changed once you lock it and generate the CA certificate by issuing the no shutdown command.

To enable the CA server and lock down the current configuration with the no shutdown command, a 7-character password is required to encode and archive a PKCS12 file containing the CA certificate and keypair that is to be generated. The file is stored to the storage identified by a previously specified database path command.

Usage Guidelines

The default state of an interface depends on the type and the context mode.

In multiple context mode, all allocated interfaces are enabled by default, no matter what the state of the interface is in the system execution space. However, for traffic to pass through the interface, the interface also has to be enabled in the system execution space. If you shut down an interface in the system execution space, then that interface is down in all contexts that share it.

In single mode or in the system execution space, interfaces have the following default states:

• Physical interfaces—Disabled.

• Redundant Interfaces—Enabled. However, for traffic to pass through the redundant interface, the member physical interfaces must also be enabled.

• Subinterfaces—Enabled. However, for traffic to pass through the subinterface, the physical interface must also be enabled.

Note	This command only disables the software interface. The physical link remains up, and the directly connected device is still recognized as being up even when the corresponding interface is configured with the shutdown command.

Usage Guidelines

For clients that use SLAAC in conjunction with the Prefix Delegation feature, you can configure the ASA to provide information in an ipv6 dhcp pool , including the SIP server, when they send Information Request (IR) packets to the ASA. The ASA only accepts IR packets, and does not assign addresses to the clients. Configure the DHCPv6 stateless server using the ipv6 dhcp server command; you specify an ipv6 dhcp pool name when you enable the server.

Configure Prefix Delegation using the ipv6 dhcp client pd command.

This feature is not supported in clustering.

Usage Guidelines

For clients that use SLAAC in conjunction with the Prefix Delegation feature, you can configure the ASA to provide information in an ipv6 dhcp pool , including the SIP domain name, when they send Information Request (IR) packets to the ASA. The ASA only accepts IR packets, and does not assign addresses to the clients. Configure the DHCPv6 stateless server using the ipv6 dhcp server command; you specify an ipv6 dhcp pool name when you enable the server.

Configure Prefix Delegation using the ipv6 dhcp client pd command.

This feature is not supported in clustering.

Usage Guidelines

You can configure each cluster chassis to belong to a separate site ID.

Site IDs work with site-specific MAC addresses. Packets egressed from the ASA cluster use a site-specific MAC address, while packets received by the cluster use a global MAC address. This feature prevents the switches from learning the same global MAC address from both sites on two different ports, which causes MAC flapping; instead, they only learn the site MAC address. Site-specific MAC addresses are supported for routed mode using Spanned EtherChannels only.

Site IDs are also used to enable flow mobility using LISP inspection.

Configure the MAC addresses on the master unit using the mac-address site-id command, and then assign each unit (master and slave) to a site using the site-id command as part of the cluster bootstrap configuration.

Usage Guidelines

The ASA generates gratuitous ARP (GARP) packets to keep the switching infrastructure up to date: the highest priority member at each site periodically generates GARP traffic for the global MAC/IP addresses.

When using per-site MAC and IP addresses, packets sourced from the cluster use a site-specific MAC address and IP address, while packets received by the cluster use a global MAC address and IP address. If traffic is not generated from the global MAC address periodically, you could experience a MAC address timeout on your switches for the global MAC address. After a timeout, traffic destined for the global MAC address will be flooded across the entire switching infrastructure, which can cause performance and security concerns.

GARP is enabled by default when you set the site ID for each unit and the site MAC address for each Spanned EtherChannel.

Usage Guidelines

To protect flows from a site failure, you can enable site redundancy. If the connection backup owner is at the same site as the owner, then an additional backup owner will be chosen from another site to protect flows from a site failure.

Director localization and site redundancy are separate features; you can configure one or the other, or configure both.

Usage Guidelines

The sla monitor command creates SLA operations and enters SLA Monitor configuration mode. Once you enter this command, the command prompt changes to ciscoasa (config-sla-monitor)# to indicate that you are in SLA Monitor configuration mode. If the SLA operation already exists, and a type has already been defined for it, then the prompt appears as ciscoasa (config-sla-monitor-echo)#. You can create a maximum of 2000 SLA operations. Only 32 SLA operations may be debugged at any time.

The no sla monitor command removes the specified SLA operation and the commands used to configure that operation.

After you configure an SLA operation, you must schedule the operation with the sla monitor schedule command. You cannot modify the configuration of the SLA operation after scheduling it. To modify the the configuration of a scheduled SLA operation, you must use the no sla monitor command to remove the selected SLA operation completely. Removing an SLA operation also removes the associated sla monitor schedule command. Then you can reenter the SLA operation configuration.

To display the current configuration settings of the operation, use the show sla monitor configuration command. To display operational statistics of the SLA operation, use the show sla monitor operation-state command . To see the SLA commands in the configuration, use the show running-config sla monitor command.

Usage Guidelines

When an SLA operation is in an active state, it immediately begins collecting information. The following time line shows the age-out process of the operation:

W----------------------X----------------------Y----------------------Z

• W is the time the SLA operation was configured with the sla monitor command.

• X is the start time of the SLA operation. This is when the operation became “active”.

• Y is the end of life as configured with the sla monitor schedule command (the life seconds have counted down to zero).

• Z is the age out of the operation.

The age out process, if used, starts counting down at W, is suspended between X and Y, and is reset to its configured size are starts counting down again at Y. When an SLA operation ages out, the SLA operation configuration is removed from the running configuration. It is possible for the operation to age out before it executes (that is, Z can occur before X). To ensure that this does not happen, the difference between the operation configuration time and start time (X and W) must be less than the age-out seconds.

The recurring keyword is only supported for scheduling single SLA operations. You cannot schedule multiple SLA operations using a single sla monitor schedule command. The life value for a recurring SLA operation should be less than one day. The ageout value for a recurring operation must be “never” (which is specified with the value 0), or the sum of the life and ageout values must be more than one day. If the recurring option is not specified, the operations are started in the existing normal scheduling mode.

You cannot modify the configuration of the SLA operation after scheduling it. To modify the configuration of a scheduled SLA operation, you must use the no sla monitor command to remove the selected SLA operation completely. Removing an SLA operation also removes the associated sla monitor schedule command. Then you can reenter the SLA operation configuration.

Usage Guidelines

The smart-tunnel auto sign-on feature supports only applications communicating HTTP and HTTPS using the Microsoft WININET library. For example, Microsoft Internet Explorer uses the WININET dynamic linked library to communicate with web servers.

You must use the smart-tunnel auto-signon list command to create a list of servers first. You can assign only one list to a group policy or username.

A realm string is associated with the protected area of the website and is passed back to the browser either in the authentication prompt or in the HTTP headers during authentication. If adminstrators do not know the corresponding realm, they should perform logon once and get the string from the prompt dialog.

Administrators can now optionally specify a port number for the corresponding hosts. For Firefox, if no port number is specified, auto sign-on is performed on HTTP and HTTPS, accessed by the default port numbers 80 and 443 respectively.

Usage Guidelines

The smart-tunnel auto sign-on feature supports only applications communicating HTTP and HTTPS using the Microsoft WININET library. For example, Microsoft Internet Explorer uses the WININET dynamic linked library to communicate with web servers.

Following the population of a smart tunnel auto sign-on list, use the smart-tunnel auto-signon enable list command in group policy webvpn or username webvpn mode to assign the list.

Usage Guidelines

This command requires that you use the smart-tunnel list command to create the list of applications first.

This option to start smart tunnel access upon user login applies only to Windows.

Usage Guidelines

By default, smart tunnels are not enabled, so the smart-tunnel disable command is necessary only if the (default) group policy or username configuration contains a smart-tunnel auto-start or smart-tunnel enable command that you do not want applied for the group policy or username in question.

Usage Guidelines

The smart-tunnel enable command assigns a list of applications eligible for smart tunnel access to a group policy or username. It requires the user to start smart tunnel access manually, using the Application Access > Start Smart Tunnels button on the clientless-SSL-VPN portal page. Alternatively, you can use the smart-tunnel auto-start command to start smart tunnel access automatically upon user login.

Both commands require that you use the smart-tunnel list command to create the list of applications first.

Usage Guidelines

You can configure more than one smart tunnel list on an ASA, but you cannot assign more than one smart tunnel list to a given group policy or username. To populate a smart tunnel list, enter the smart-tunnel list command once for each application, entering the same list string, but specifying an application and path that is unique for the OS. Enter the command once for each OS you want the list to support.

The session ignores a list entry if the OS does not match the one indicated in the entry. It also ignores an entry if the path to the application is not present.

To view the smart tunnel list entries in the SSL VPN configuration, enter the show running-config webvpn smart-tunnel command in privileged EXEC mode.

The path must match the one on the computer, but it does not have to be complete. For example, the path can consist of nothing more than the executable file and its extension.

Smart tunnels have the following requirements:

• The remote host originating the smart tunnel connection must be running a 32-bit version of Microsoft Windows Vista, Windows XP, or Windows 2000; or Mac OS 10.4 or 10.5.

• Users of Microsoft Windows Vista who use smart tunnels or port forwarding must add the URL of the ASA to the Trusted Site zone. To access the Trusted Site zone, they must start Internet Explorer and choose the Tools > Internet Options > Security tab. Vista users can also disable Protected Mode to facilitate smart tunnel access; however, we recommend against this method because it increases the computer’s vulnerability to attack.

• The browser must be enabled with Java, Microsoft ActiveX, or both.

• Smart tunnel support for Mac OS requires Safari 3.1.1 or later.

On Microsoft Windows, only Winsock 2, TCP-based applications are eligible for smart tunnel access.

On Mac OS, applications using TCP that are dynamically linked to the SSL library can work over a smart tunnel. The following types of applications do not work over a smart tunnel:

• Applications using dlopen or dlsym to locate libsocket calls

• Statically linked applications to locate libsocket calls

• Mac OS applications that use two-level name spaces.

• Mac OS, console-based applications, such as Telnet, SSH, and cURL.

• Mac OS, PowerPC-type applications. To determine the type of a Mac OS application, right-click its icon and select Get Info.

On Mac OS, only applications started from the portal page can establish smart tunnel sessions. This requirement includes smart tunnel support for Firefox. Using Firefox to start another instance of Firefox during the first use of a smart tunnel requires the user profile named csco_st. If this user profile is not present, the session prompts the user to create one.

The following limitations apply to smart tunnels:

• If the remote computer requires a proxy server to reach the ASA, the URL of the terminating end of the connection must be in the list of URLs excluded from proxy services. In this configuration, smart tunnels support only basic authentication.

• The smart tunnel auto sign-on feature supports only applications communicating HTTP and HTTPS using the Microsoft WININET library on a Microsoft Windows OS. For example, Microsoft Internet Explorer uses the WININET dynamic linked library to communicate with web servers.

• A group policy or local user policy supports no more than one list of applications eligible for smart tunnel access and one list of smart tunnel auto sign-on servers.

• A stateful failover does not retain smart tunnel connections. Users must reconnect following a failover.

Note	A sudden problem with smart tunnel access may be an indication that a path value is not up-to-date with an application upgrade. For example, the default path to an application typically changes following the acquisition of the company that produces the application and the next upgrade.

Entering a hash provides a reasonable assurance that clientless SSL VPN does not qualify an illegitimate file that matches the string you specified in the path . Because the checksum varies with each version or patch of an application, the hash you enter can only match one version or patch on the remote host. To specify a hash for more than one version of an application, enter the smart-tunnel list command once for each version, entering the same list string, but specifying the unique application string and unique hash value in each command.

Note

You must maintain the smart tunnel list in the future if you enter hash values and you want to support future versions or patches of an application with smart tunnel access. A sudden problem with smart tunnel access may be an indication that the application list containing hash values is not up-to-date with an application upgrade. You can avoid this problem by not entering a hash .

Following the configuration of a smart tunnel list, use the smart-tunnel auto-start or smart-tunnel enable command to assign the list to group policies or usernames.

Usage Guidelines

When the smart tunnel is turned on, you can allow traffic outside of the tunnel with the smart-tunnel network command, which configures the network (a set of hosts), and the smart-tunnel tunnel-policy command, which uses the specified smart-tunnel network to enforce a policy on a user.

Usage Guidelines

When the smart tunnel is turned on, you can allow traffic outside of the tunnel with the smart-tunnel network command, which configures the network (a set of hosts), and the smart-tunnel tunnel-policy command, which uses the specified smart-tunnel network to enforce a policy on a user.

Usage Guidelines

The ASA includes an internal SMTP client that the Events system can use to notify external entities that a certain event has occurred. You can configure SMTP servers to receive these event notices, and then forward them to specified e-mail addresses. The SMTP facility is active only when you enable E-mail events to the ASA. This command also allows interface association to identify the routing table to be used for logging—management routing table or data routing table. If no interface is provided, ASA would refer to management routing table lookup, and if no proper route entry is present, it would look at the data routing table.

Usage Guidelines

You cannot configure the critical CPU threshold level, which is maintained at a constant 95 percent. Valid threshold values range from 10 to 94 percent of CPU usage. Valid values for the monitoring period range from 1 to 60 minutes.

Usage Guidelines

Valid threshold values range from 30 to 99 percent of physical interfaces. The snmp interface threshold command is available only in the admin context.

Usage Guidelines

Use the snmp-map command to identify a specific map to use for defining the parameters for SNMP inspection. When you enter this command, the system enters the SNMP map configuration mode, which lets you enter the different commands used for defining the specific map. After defining the SNMP map, you use the inspect snmp command to enable the map. Then you use the class-map , policy-map , and service-policy commands to define a class of traffic, to apply the inspect command to the class, and to apply the policy to one or more interfaces.

Usage Guidelines

The SNMP community string is a shared secret among the SNMP management station and the network nodes being managed. It is used only for Version 1 and 2c communication between the management station and the device. The ASA uses a key to determine whether or not the incoming SNMP request is valid.

You should avoid the use of special characters (!, @, #, $, %, ^, &, *, \) in community strings. In general, using any special characters reserved for functions used by the operating system can cause unexpected results. For example, the backslash (\) is interpreted as an escape character and should not be used in the community string.

For example, you could designate a site with a community string and then configure the routers, the ASA, and the management station with this same string. The ASA uses this string and does not respond to requests with an invalid community string.

After you have used an encrypted community string, only the encrypted form is visible to all systems (for example, CLI, ASDM, CSM, and so on). The clear text password is not visible.

The encrypted community string is always generated by the ASA; you normally enter the clear text form.

Note	If you downgrade from version 8.3(1) to a lower version of the ASA software and have configured encrypted passwords, you must first revert the encrypted passwords to clear text using the no key config-key password encryption command, then save the results.

Usage Guidelines

You can enable and disable SNMP easily, without configuring and reconfiguring SNMP traps or other configuration.

Usage Guidelines

To allow SNMP walk operations of these MIB objects, you can enable these MIB objects using the snmp-server enable oid mempool command. When doing SNMP walk operations, the ASA will query memory information from the MEMPOOL_DMA and MEMPOOL_GLOBAL_SHARED pools. When the ASA queries memory information, the CPU may be held by the SNMP process for too long before releasing the CPU to other processes. This can result in SNMP-related CPU hogs causing packet drops.

To mitigate this issue, avoid polling the OIDs that relate to the Global Shared pool using the no snmp-server enable oid mempool command. When disabled, the mempool OIDs would return 0 bytes. The clear configure snmp-server command restores the default enabling of SNMP MIB objects for memory queries.

Usage Guidelines

To enable individual traps or sets of traps, enter this command for each feature type. To enable all traps, enter the all keyword.

To send traps to the NMS, enter the logging history command, then enable logging using the logging enable command.

Traps generated in the admin context only include the following:

• connection-limit-reached

• entity

• memory-threshold

Traps generated through the admin context only for physically connected interfaces in the system context include the following:

• interface-threshold

All other traps are available in the admin and user contexts.

The config trap enables the ciscoConfigManEvent notification and the ccmCLIRunningConfigChanged notification, which are generated after you have exited configuration mode.

Some traps are not applicable to certain hardware models. Use ? in place of a trap keyword to determine which traps are available for your device. For example:

• The accelerator-temperature threshold trap applies only to the ASA 5506-X and ASA 5508-X.

• The chassis-fan-failure trap does not apply to the ASA 5506-X.

• The following traps do not apply to the ASA 5506-X and ASA 5508-X: fan-failure , fru-insert , fru-remove , power-supply , power-supply-presence , and power-supply-temperature .

• The Firepower 1000 series, except the 1010, supports the following entity traps only: chassis-temperature , config-change , and cpu-temperature . The 1010 supports the following traps only: config-change , fru-insert , fru-remove .

Multiple Context Mode Guidelines

• In multiple context mode, the fan-failure trap, the power-supply-failure trap, and the cpu-temperature trap are generated only from the admin context, and not the user contexts. These traps apply only to the ASA 5512-X, 5515-X, 5525-X, 5545-X, and 5555-X; they do not apply to the ASA 5505.

• The snmp-server enable traps remote-access session-threshold-exceeded command is not supported in multiple context mode.

If the CPU usage is greater than the configured threshold value for the configured monitoring period, a cpu threshold rising trap is generated.

When the used system memory reaches 80 percent, the memory-threshold trap is generated.

Note	SNMP does not monitor voltage sensors.

Usage Guidelines

To use the Version 3 security model, you must first configure an SNMP group, then configure an SNMP user, and then configure an SNMP host. You must also specify Version 3 and a security level. When a community string is configured internally, two groups with the name “public” are automatically created—one for the Version 1 security model and one for the Version 2c security model. When you delete a community string, both configured groups are automatically deleted.

Note	A user that is configured to belong to a certain group should have the same security model as the group.

During bootup or upgrade of the ASA, single-digit passwords and passwords starting with a digit followed by a whitespace are no longer supported. For example, 0 pass and 1 are invalid passwords.

Note	If you downgrade from version 8.3(1) to a lower version of the ASA software and have configured encrypted passwords, you must first revert the encrypted passwords to clear text using the no key config-key password encryption command, then save the results.

Usage Guidelines

If you configure the snmp-server host command on a port that is currently in use, the following message appears:

The UDP port port  is in use by another feature. 
SNMP requests to the device will fail until the snmp-server listen-port 
command is configured to use a different port.

The existing SNMP thread continues to poll every 60 seconds until the port is available, and issues syslog message %ASA-1-212001 if the port is still in use.

If neither [trap | poll ] is specified, both are enabled by default.

To use the Version 3 security model, you must configure an SNMP group first, then an SNMP user, and then an SNMP host. The username must already be configured on the device. When a device is configured as the standby unit of a failover pair, the SNMP engine ID and user configuration are replicated from the active unit. This action allows a transparent switchover from an SNMP Version 3 query perspective. No configuration changes are necessary in the NMS to accommodate a switchover event.

After you have used an encrypted community string, only the encrypted form is visible to all systems (for example, CLI, ASDM, CSM, and so on). The clear text password is not visible.

The encrypted community string is always generated by the ASA; you normally enter the clear text form.

During bootup or upgrade of the ASA, single-digit passwords and passwords starting with a digit followed by a whitespace are no longer supported. For example, 0 pass and 1 are invalid passwords.

Usage Guidelines

You can now add up to 4000 hosts. The number of supported active polling destinations is 128. You can define the hosts using a hostname or a range of IP addresses. You can specify a network object to indicate the individual hosts that you want to add as a host group. You can associate more than one user with one host.

The default is poll if [trap | poll ] is not specified. It is important to note that for this command, both the traps and polling cannot be enabled for the same host group. For a mixed monitoring environment where some hosts are configured for polling while others are configured for traps, we recommend that you use the snmp-server host command. It is important to note that for the snmp-server host command, both the traps and polling cannot be enabled for the same host, and the default is trap .

If you are using SNMP notification version 1 or 2c for sending traps, you may associate a single user with a network object. If you are using SNMP notification version 3 for sending traps, you may associate a single user or a group of users with a network object. Use the snmp-server user-list command to create a group of users. The users may belong to any group configuration.

If you are using SNMP version 3, you must associate a username with the SNMP host.

Supports IPv4 and IPv6.