Table Of Contents
Release Notes for the Catalyst 6500 Series and Cisco 7600 Series Firewall Services Module, Software Release 2.3(x)
This document contains release information for the following FWSM Releases:
Note The FWSM 2.3(3.2) and later releases passed Cisco Safe Harbor testing in single routed firewall mode and in single transparent firewall mode.
This document includes the following sections:
See the following important notes for configuring the FWSM:
•In some circumstances, when you configure a limit on TCP connections as well as a limit on embryonic connections in a nat or static statement, a denial of service (DoS) condition might occur. We recommend that you configure only one of these limits at a time for a given nat or static statement, and leave the other at the default of 0 (unlimited, up to the maximum for the system). The UDP connection limits are not affected. See caveat CSCee47998 for more information.
•When you configure the embryonic limit for an inside static statement, and you also configure dynamic PAT for an outside interface, then a SYN attack from the outside to the inside static address causes a large number of PAT translations with associated connections, even though the connections are not established. These PAT translations do not time out within the default 30-second interval for translations without the associated connections because the FWSM thinks that there are valid connections associated. The pool of addresses and ports for the outside addresses gets used up, and no additional clients can connect. We recommend that you do not configure outside PAT in this situation. See caveat CSCee48769 for more information.
Chassis System Requirements
The switch models that support the FWSM include the following platforms:
•Catalyst 6500 series switches, with the following required components:
–Supervisor engine with Cisco IOS software or Catalyst operating system (OS). See Table 1 for supported supervisor engine and software releases.
–Multilayer Switch Feature Card (MSFC 2) with Cisco IOS software. See Table 1 for supported Cisco IOS releases.
•Cisco 7600 series routers, with the following required components:
–Supervisor engine with Cisco IOS software. See Table 1 for supported supervisor engine and software releases.
–MSFC 2 with Cisco IOS software. See Table 1 for supported Cisco IOS releases.
Table 1 shows the supervisor engine version, software, and supported FWSM features.
Table 1 Support for FWSM 2.3 Features
FWSM Features: Supervisor Engines 1 Multiple SVIs 2 Transparent Firewall with Failover 3 Cisco IOS
12.1(22)E and higher
12.2(14)SY and higher
12.2(17d)SXB and higher
32, 2, 720
Catalyst OS 4
7.6(1) through 7.6(4)
7.6(5) and higher
1 The FWSM does not support Supervisor Engine 1 or 1A.
2 Supports multiple switched VLAN interfaces (SVIs) between the MSFC and FWSM. An SVI is a VLAN interface that is routed on the MSFC.
3 Supports transparent firewall mode when you use failover. Failover requires BPDU forwarding to the FWSM, or else you can have a loop. Other releases that do not support BPDU forwarding only support transparent mode without failover.
4 When you use Catalyst OS on the supervisor engine, you can use any of the supported Cisco IOS releases above on the MSFC. (When you use Cisco IOS software on the supervisor engine, you use the same release on the MSFC.) The supervisor engine software determines the FWSM feature support. For example, if you use Catalyst software release 7.6(1) on the supervisor engine and Cisco IOS Release 12.1(13)E on the MSFC, then the switch does support multiple SVIs, because Catalyst software release 7.6(1) supports multiple SVIs.
The FWSM supports the following management methods:
•Cisco ASDM—Software Release 4.1 supports FWSM software release 2.3 features. PDM is a browser-based configuration tool that resides on the FWSM. The system administrator can configure multiple security contexts. If desired, individual context administrators can configure only their contexts.
•Cisco Firewall MC—Software release 1.3.1 supports FWSM software release 2.3 features. For multiple context mode, software release 1.3.1 supports management of each context separately but does not support system-level operations, such as adding or deleting contexts, or the provisioning of failover in multiple mode.
•Command-line interface (CLI)—Access the CLI by sessioning from the switch or by connecting to the FWSM over the network using Telnet or SSH. The FWSM does not have its own external console port.
Table 2 lists the new features for FWSM software release 2.3(1).
Upgrading the Software
The following command allows you to upgrade from FWSM software release 1.1 (or pre-release versions of 2.x) to FWSM software release 2.3. For other upgrade options for upgrading from Release 2.x, such as upgrading to a different application partition or from a different type of server, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide.
To upgrade the application software to the current application partition, enter the following command. For multiple context mode, you must be in the system execution space.hostname# copy tftp://server[/path]/filename flash:
For example, enter the following command:hostname# copy tftp://18.104.22.168/cisco/c6svc-fwm-k9.2-1-1.bin flash:
Software License Information
FWSM software release 2.2 introduced a software license for multiple security context support. With the basic license, the FWSM supports two contexts plus the special admin context. You can buy a license for additional security context support, up to 100 contexts. See the Cisco.com website for more information about licensing options. See the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide for more information about entering a license activation key.
Limitations and Restrictions
This section lists the limitations and restrictions for the following operating systems:
Limitations and Restrictions on the FWSM
See the following limitations and restrictions on the FWSM:
•Multiple context mode does not support dynamic routing protocols such as RIP and OSPF. Use static routing instead.
•Transparent firewall mode supports a maximum of two interfaces per context.
•For transparent firewall mode, you must configure a management IP address.
•The outbound connections (from a higher security interface to a lower security interface) from an interface that is shared between the contexts can only be classified and directed through the correct context if you configure a static translation for the destination IP address. This limitation makes cascading contexts unsupported, because configuring the static translations for all the outside hosts is not feasible.
•The CPU-intensive commands, such as copy running-config startup-config (and the write memory command, which performs the same task), might affect system performance, including reducing the successful rate of inspection and AAA connections. When a CPU-intensive action completes, the FWSM might produce a burst of traffic to catch up. If you limit the resource rates for a context, the burst might unexpectedly reach the maximum rate. We recommend using these commands during low traffic periods. Other CPU-intensive actions include the show arp command, polling the FWSM with SNMP, loading a large configuration, and compiling a large access list.
Limitations and Restrictions in Cisco IOS Software
See the following limitations and restrictions in Cisco IOS software for interoperating with the FWSM. See also the "Chassis System Requirements" section for the FWSM feature support in Cisco IOS software.
•Although the FWSM can handle jumbo Ethernet frames, the switch does not handle jumbo frames through the FWSM. See caveat CSCee03625 for more information.
•For some releases of Cisco IOS software, you cannot install the FWSM in slot 13. This problem occurs with all service modules. See caveat CSCed82263 for more information.
•For some releases of Cisco IOS software, if the supervisor engine fails over, the FWSM switching mode might change from crossbar mode to bus mode. This change causes FWSM traffic to be disrupted until the switching mode returns to crossbar mode (see the show fabric switching-mode command to view the FWSM switching mode). You can restore the crossbar mode by bringing the failed supervisor engine online again by inserting a new crossbar module or by reloading the FWSM. See caveat CSCee62630 for more information.
Limitations and Restrictions in the Catalyst Operating System
See the following limitations and restrictions in the Catalyst operating system for interoperating with the FWSM. See also the "Chassis System Requirements" section for FWSM feature support.
•Although the FWSM can handle jumbo Ethernet frames, the switch does not handle jumbo frames through the FWSM. See caveat CSCee03625 for more information.
•If you reload the switch or the FWSM, the switch might lose the configuration that assigns the VLANs to the FWSM. You need to reenter the set vlan firewall-vlan command after the reload. See caveat CSCed69941 for more information. This problem is resolved in release 8.3(1) and might be resolved in earlier versions.
•If you reload the switch, the switch might lose the configuration for the SVIs on the MSFC. You need to reenter the interface vlan command on the MSFC after the reload. See caveat CSCed69931 for more information. This problem was found in software release 7.6(5) and might exist in later releases.
Open Caveats in Software Release 2.3
This section contains open caveats in the latest maintenance release.
If you are running an older release, and you need to determine the open caveats for your release, then add the caveats in this section to the resolved caveats from later releases. For example, if you are running Release 2.3(2), then you need to add the caveats in this section to the resolved caveats from 2.3(3) and later to determine the complete list of open caveats.
If you are a registered cisco.com user, view Bug Toolkit on Cisco.com at the following website:
To become a registered Cisco.com user, go to the following website:
Because the FWSM does not allow Telnet to the lowest security interface, if you configure a context with only one interface, you cannot Telnet to it because it is inherently the lowest security interface.
Workaround: Configure a second interface at a lower security level, and then delete the interface; the FWSM now allows Telnet to the one remaining interface.
If you change any crypto map commands, the changes are made in the configuration, but the FWSM still uses the old settings.
Workaround: Reapply the crypto map to the interface by entering the no crypto map interface command to remove it, and then reapply the crypto map.
When you set the fragment command to 1, the show fragment command displays the value as 0. The FWSM uses the correct value of 1 even though the display is incorrect.
When you use Reflection X as an XDMCP client, the connection gets reset after 2 hours.
Workaround: Enter the timeout conn command to set the TCP connection timeout to 4 hours on the FWSM instead of the default of 1 hour.
When a duplicate route with a lower metric cost through a different interface is configured the show route command displays the incorrect interface.
Workaround: Remove the initial route that is going to be replaced and then configure the new route.
When a Smurf attack occurs against the FWSM, the FWSM correctly drops the traffic, but does not generate a system message or SNMP trap about the Smurf attack.
In manual commit mode for access lists, the show access-list command shows the standard (OSPF) access lists as not being committed. The display is incorrect, and the standard access lists behave as expected.
In multiple context mode, the system execution space cannot send system messages to an external syslog server through the admin context; you can only view these system messages from the buffer or on your session monitor.
When you use Cisco VPN client Release 3.6.3 for management access in routed firewall mode, you cannot use the local database for user authentication.
Workaround: Use RADIUS or TACACS+ for authentication.
The CPU goes to 99 percent of capacity when there is a large number of SCCP sessions suddenly being handled. This situation negatively impacts IP routing updates.
Performance monitoring values do not match the statistics that the resource manager collects.
Workaround: Use the show resource usage command to obtain accurate statistics.
The duration value in the translation teardown syslog messages does not correspond to the real duration of the connection.
The problem occurs when an FWSM has several interfaces with the same security level and IP phones in a different VLAN than the Cisco CallManager and the phones register but when they go off hook, they do not get a dial tone and they reset.
Workaround: Move the IP phones to the same VLAN that Cisco CallManager is on.
When you enter the show processes command, the run-time values in the output are not accurate. During high CPU usage on the FWSM, the run-time values are used to determine which processes are using the CPU. Currently, the values are incremented only if the time that the process spends on the CPU is 1 millisecond (ms) or longer. Therefore, an active process that runs frequently on the CPU, but spends less than 1 ms each time, would show a run-time of 0.
During heavy traffic load, the number of hit counts that are shown from the show ethertype acl output is incorrect.
The problem occurs with the following topology: an FWSM configured in routed mode with two networks, one inside and one outside, one Skinny phone a Cisco CallManager on the inside network, and an H323 gateway on the outside network.
When a call is placed between two skinny phones through the H323 gateway and one Skinny phone places the call on hold, the Cisco CallManager sends a music-on-hold (MOH) signal. This MOH signal is denied by the FWSM.
Workaround: Explicitly allow all UDP traffic from the Cisco Call Manager to the H.323 gateway.
An OSPF route and a static route are configured with a higher administrative distance for the same prefix. Upon deletion of the OSPF route, the statically configured route for the same subnet does not operate.
Workaround: If possible, configure the supernet of the OSPF route as a static route so that the normal routing rules can operate correctly.
The transparent firewall cannot learn the MAC addresses for forwarding packets when failover is enabled and mis-configured without having the failover VLAN mapped to the FWSM.
Workaround: Verify that the failover VLAN is mapped to FWSM when configuring failover settings.
If two telnet sessions are directed to the same FWSM and both sessions cause the display to present the "more" prompt, one session will remain frozen until the other session enters a character.
Workaround: Use the no pager command so the display does not stop at the "More" prompt.
When you enable URL caching, all HTTP traffic stops. The server is up, and as soon as caching is disabled normal traffic flow resumes.
Workaround: Disable URL caching.
FWSM crashed at doorbell_poll due to an assert in the slow path (NP3).
OSPF convergence is not happening properly when OSPF authentication is configured between neighbors. When you first configure OSPF authentication on the FWSM and its neighbors, the convergence happens properly. If you then make the authentication fail by making the key mismatched, then changing the key to match again, then the convergence does not happen properly.
System log message 313004 shows the following; the interface name is not shown for the source IP address.Jan 6 07:16:08 172.16.197.100 %FWSM-4-313004: Denied ICMP type=11, from laddr192.168.248.57 on interface to 10.109.230.127: no matching session
A PDM Configuration Refresh hangs when another session is stopped at the <--- More ---> prompt. The PDM displays a window "Please wait while the PDM is loading the current configuration from your firewall." It has a progress bar and the bar hangs at 27%. Only if the first session finishes their display and gets past the <--- More ---> prompt will the progress bar finish out to 100%.
Workaround: Clear the <--- More ---> prompt from the user session.
Conditional OSPF Default Route Advertisement does not work (the default-information originate route-map command); the FWSM does not conditionally advertise a default route based on the presence of another route on an FWSM.
Workaround: Configure a static recursive default route for a route learned via OSPF.
In multiple context mode, when contexts include large access lists and established statements, then the compilation of access lists might fail, even if the maximum number of access lists is not reached for the memory partition the context is assigned to.
Workaround: Decrease the number of memory partitions to increase their size. See the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Software Configuration Guide for information about how to perform this change.
The FWSM crashed with Thread Name: fast_fixup. The crash occurred when the FWSM was inspecting FTP traffic.
Workaround: Disable the FTP inspection by entering the no fixup ftp command.
The write net command fails in a context, even though the context can ping the TFTP server.
When using manual commit to access list changes, changes made to access lists related to authentication match statements are not effective after the commitment.
Workaround: Use auto commit (the default). The workaround once the access list has become ineffective is to remove and re-insert the authentication match statement.
When the FWSM CPU usage is high (due to a large access list compilation or other reasons), the SSL connection between the FWSM and CSM fails. The corresponding defect in CSM is CSCsd35974.
In the show np 3 acl count output, the NP 3 ACL Uncommitted Add display increments when you add and remove the same access list in manual commit mode.
AAA is configured for HTTP inbound traffic. FTP or ICMP traffic goes through fine without asking for authentication. But if the host is already authenticated through HTTP, FTP or ICMP traffic is denied. Per-user-override is not configured and dynamic access list permits HTTP. The interface access list permits all traffic.
Under rare circumstances in multiple context routed mode with shared interfaces, some traffic flows might fail through the FWSM while others flow fine.
Workaround: Fail over to the standby FWSM if possible, and reload the failed FWSM.
After removing a name command that is applied to router ospf, The area ID still shows the name. After entering write standby on the active FWSM, the standby FWSM keeps rebooting.
The DNS fixup translates a DNS response without the dns keyword configured in the static command.
For example, a reflector is configured with the following A Record:
The FWSM with the DNS fixup enabled has the following static command:static (DMZ2,outside) 192.168.1.104 192.168.2.104 netmask 255.255.255.254
A client makes a DNS request to 192.168.1.104 for www.cisco.com and receives an answer of 192.168.1.104 when the answer should be 192.168.2.104.
Workaround: If fixup protocol dns is disabled, the correct response is received by the client.
Zero downtime upgrades fail to work on the FWSM, resulting in both units in an Active state. For example, if one unit is upgraded to another 2.x release, during the version check process the existing Active unit will go into a Disabled state, but continue to pass traffic. The Standby unit will detect that the peer is not Active, and will become Active. At this point, both units are now attempting to pass traffic with the Active IPs.
Workaround: Install the new software on both units, and reboot them both at the same time, resulting in minimal down time.
The FWSM unexpectedly stops passing traffic and reloads. This typically occurs at the moment a change is made to an object group.
When a previous configuration on the FWSM is erased and the FWSM is rebooted, after the FWSM starts up, access-list deny flows are not created.
The following system log message is displayed on the console:%FWSM-1-106101: Number of cached deny-flows for ACL log has reached limit (0)
Workaround: Reenter the access-list deny-flow-max command or save the current configuration and reboot the FWSM.
If you connect to the switch console and session to the FWSM, if you enter the show running-config command and hold the space bar pressed, then the FWSM stops responding to keepalives from the switch; the switch then power cycles the FWSM.
Workaround: Do not hold the spacebar pressed down.
Resolved Caveats in Software Release 2.3(5)
This section describes caveats closed in FWSM Release 2.3(5).
The FWSM does not reboot after you force a watchdog crash. After the forced crash, a message displays stating that the module will restart but it will not restart.
FWSM may crash in response to a doorbell_poll, which causes the supervisor to reset each FWSM when there is traffic passing through the switch.
In single routed mode with fixup dns configured, an FWSM might silently drop a DNS self-query when the client and DNS server are on separate VLANs. No system log message is produced by the FWSM.
Workaround: Remove DNS inspection by entering the no fixup dns command.
In some instances, an access list blocks traffic that is supposed to be explicitly allowed.
Workaround: Reload the FWSM.
An inbound TCP connection was established through the FWSM. At some point something happens to the network path, and packets are unable to get through. The endpoints know that the connection is down, but the FWSM does not. When the network is restored, the endpoints try to create a new connection but the FWSM thinks this connection is part of the previous one and tries to reset its connection timers. It should RST the previous flow and allow a new one.
When an external authentication server is configured, and that server connectivity is somehow interrupted on the FWSM during SSH authentication attempts, then the SSH management connections to the FWSM are being refused or denied.
The show resource usage command indicates all SSH resources are being occupied:Resource Current Peak Limit Denied ContextTelnet 1 2 5 0 SystemSSH 5 5 5 501 System
A system log message is generated for the denied SSH session:%FWSM-4-315005: SSH session limit exceeded. Connection request from X on interface outside
Workaround: There is no workaround to clear out these SSH sessions without doing a reload of the FWSM. If you have a failover unit, you can fail over to the standby unit and reload the active unit having the issues. If this problem continually reoccurs, use local authentication until a fix is available.
The following caveats were fixed between Release 2.3(4) and 2.3(5), and were not previously documented.
For your convenience in locating caveats in the Cisco Bug Toolkit, the caveat titles listed in this section are drawn directly from the Bug Toolkit database. These caveat titles are not intended to be read as complete sentences because the title field length is limited. In the caveat titles, some truncation of wording or punctuation may be necessary to provide the most complete and concise description.
If you are a registered cisco.com user, view Bug Toolkit on cisco.com at the following website:
To become a registered cisco.com user, go to the following website:
Resolved Caveats in Software Release 2.3(4)
This section describes caveats closed in FWSM Release 2.3(4).
When using the same-security-traffic-feature and an access list applied for outbound traffic, the source IP address in the access list displayed by system log message 106023 may not be correct.
With the sqlnet fixup enabled, the SQL connection is closed after 3 hours from the last SQL query even if the TCP keepalive of the Oracle server is sent.
Workaround: Disable the sqlnet fixup.
With an FWSM failover pair, if one FWSM is configured with a named area ID, the other FWSM unit keeps rebooting when trying to replicate the OSPF network configuration.
Workaround: Before syncing the two failover units, remove the line "name ip_address name-A" and change the line "network name-A mask area name-A" to "network name-A mask area ip_address."
The dhcp_daemon may crash randomly and the following error message appears on the console: An internal error occurred. Specifically, a programming assertion was violated. If this occurs, save the output of the show version command and the contents of the configuration file and contact Cisco TAC.
When memory usage exceeds 90%, the clear xlate command may cause an unexpected FWSM reload.
The following caveats were found and fixed between Release 2.3(3.2) and 2.3(4), and were not previously documented:
Resolved Caveats in Software Release 2.3(3.2)
This section describes caveats closed in FWSM Release 2.3(3.2).
The FWSM in transparent firewall mode drops the first 200 OK message in response to an MGCP MDCX message. The message is retransmitted successfully.
Workaround: Disable the MGCP fixup using the no fixup protocol mgcp 2427 command.
The RPC fixup does not always correctly open holes for certain RPC connections using TCP.
Workaround: Configure the server to use static ports for the affected service(s). Modify the access list of the FWSM to allow traffic to these static ports.
An FWSM with long-lived FTP sessions may not see connections replicated back to the primary FWSM after a failover event. The primary (active) FWSM will have the connection in its connection table, and the secondary (standby) FWSM will also have the connection. Upon failover, the primary unit will clear the connection table and replicate the connections from the secondary (active) unit. Some of these connections may not be replicated.
To check for this condition, enter the show conn command on both units before and after the failover event. The primary (standby) unit should replicate the connections within a couple of minutes.
Workaround: None. However, the problem will be cleared as connections terminate, and new connections will be properly replicated.
When the standby FWSM syncs its config with the active FWSM, the first command it issues is the clear configure all command. This command results in the following two commands being inserted into the standby FWSM configuration:sysopt nodnsalias inboundsysopt nodnsalias outbound
Thus, the configurations will not be completely in sync. If a failover occurs from active to standby, then these commands will now be in effect on the newly active FWSM.
Workaround: Manually remove the commands on the standby FWSM.
If you configure a dynamic access list using the Cisco ACS RADIUS server for AAA authentication or authorization, authentication or authorization fails. The FWSM sends two RADIUS access requests with the same ID number (packet ID). The time gap between these two requests is very small, and the RADIUS server ignores the second request that requests the dynamic access list causing authentication or authorization to fail. The FWSM then marks the RADIUS server as being down.
Resolved Caveats in Software Release 2.3(3)
This section describes caveats closed in FWSM Release 2.3(3) and includes the following topics:
The per-user-acl override feature is configured for FTP and multiple FTP users log in from the same ip address. Sometimes when using this configuration, the per-user-acl override functionality does not work as expected when multiple FTP users connect from the same host. For example, if user_1 is allowed FTP network access through the module and user_2 is not, it is possible that user_2 may have unhindered access even when per-user-acl applied to the user_2 profile has strict network access restrictions.
Workaround: None, unless a restriction is in place to limit FTP users to one per host.
On an FWSM in single transparent mode with the TACACS+ authentication configured, when a client passes the AAA authentication, it is denied by the int acl command. The log shows that the AAA authentication is denied by the wrong interface access list.
Adding more than 5,017 access control entries to an access-list tied to AAA using the AAA match access-list command causes the original AAA configuration statement to be removed and disables the related AAA operation. Also, upload over the network may keep the CPU utilization close to 100% for a long time.
FWSM does not support the aaa accounting commands, but the parser still accepts these commands.
Workaround: Do not use the deprecated aaa accounting commands.
This applies when per-user override is enabled, TACACS+ is used for AAA authentication and authorization, and the source and destination are permitted by the AAA access list, but are denied by the inbound access list. In this configuration, during AAA authentication and authorization, the inbound access list is bypassed. After the user is authenticated and authorized, the inbound access list blocks the new session.
Configuring an AAA policy and making use of an access list with more than 20K access control entries the FWSM may crash.
Workaround: None. Only a few thousand AAA configurations are supported, so do not configure an access list with more than a few thousand elements as in AAA configuration.
User authentication fails when SSH to the FWSM device is enabled and users are authenticated through TACACS+.
Access List Caveats
After 16K access lists with the log keyword are configured on the FWSM, the message "ERROR: Unable to add access-list (rc=0xc014)" is seen on the FWSM when trying to add another access list rule containing the log keyword.
Override functionality does not work if a named access list is configured on a RADIUS server. When a user is authenticated, the dynamic access list name is displayed in the Uauth information but access the access list is not applied to traffic. Instead, the interface access takes effect and traffic is passed/denied accordingly.
When using an access list with access groups and using Internet Explorer to send HTTP SYN packets from a lower security interface to a higher security interface, the hit count against a deny access control entry is not accurate.
In access list manual commit mode, adding new members to object groups used in access lists that expand to a lot of new access control entries can result in dangling object group access control entries with an "uncommitted deletion" qualifier.
Workaround: Remove the object group access control entries and add them again.
Compilations in auto mode can be slow after changes have been made to large object groups tied to access lists. This may happen when back-to-back compilation is triggered.
When one or more ACEs in a file are copied using the tftp:/disk: command to the running configuration, the last line in the file is missed and does not get copied over.
Workaround: Add a dummy access control entry to the file.
After committing a large set of access lists, the FWSM may hang.
When using AAA authentication, authentication intermittently completely stops working without producing any traces or logs.
Workaround: Reload FWSM.
UDP packets with the source port set to 0 bypass the access rule when a destination port is also specified. An attack is possible, given an access list with a deny udp any any eq port dest followed by permit any any or deny udp any any eq port dest followed by permit host attacker any. If the attacker uses SRC port zero then the attacker can bypass the access list and reach any host on any port, including the port explicitly denied in the first access control entry. For this attack to work, there has to be a permit statement for UDP that does not specify any source or destination port (wildcarded).
Workaround: Use the lt 1 port range in the access list.
On FWSM Release 2.3(x), under high load conditions (more than 4000 users with downloadable access lists, the FWSM will display the following errors:
•May 02 2005 12:08:44: %FWSM-3-109018: Downloaded ACL "username@companyname" is empty
•May 02 2005 12:08:44: %FWSM-4-109005: Authentication succeeded for user 'username@companyname' from 10.10.10.10/4298 to 192.168.2.2/443 on interface production
At this point, all downloadable access lists appear empty. This issue is observed until the user traffic is decreased. This is the result of a hard-coded limit of approximately 4000 downloadable access lists (the exact number depends on the structure of the access list).
Workaround: Use the show np3 acl count to determine if the system is approaching the access list limit. Avoid use of repetitive downloadable access lists. Instead, used named downloadable access. Change the infrastructure so that there are fewer downloadable access lists per FWSM.
When FWSM Release 2.3.3 is running in single or multimode using translation or authentication rules that require access lists to define interesting traffic, the hit count in the corresponding access lists for certain functions does not increase from 0. The affected functions include NAT 0 access-list, policy NAT, policy static, crypto map match address, and AAA.
The set of access list configurations on the FWSM does not fit in the FWSM access list memory. The device tries to compile the access lists but runs out of memory while doing so. FWSM deletes all the rules added in that step automatically but the PDM/MC does not report the error and it appears as if the access list has been successfully committed.
Workaround: None. To monitor the access list memory usage, use the show np 3 acl stats command.
The problem occurs when you perform the following steps:
1. The access list is in manual mode.
2. You configure suspend-config-sync between the active and the standby FWSM.
3. You change the access list.
4. Suspend-config-sync is then disabled.
Following the previous steps causes the access list configuration to not be synchronized between the active and standby FWSM. The access list configuration should be synchronized.
If you continue sending the access-list commit command, this action causes the access list to be totally out of synchronization between the active and standby modules.
When an RSH (remote shell) connection has been made to two FWSMs, the RST (reset) packet is dropped between the FWSMs. This problem can be seen when traffic must pass through multiple FWSMs.
When PDM sessions hang or are disconnected abnormally, or when simultaneous multiple access attempts occur to PDM, the following error may be seen: FWSM, 1550 blocks getting depleted, the low counter is reaching 0.
Workaround: none, except for reloading FWSM.
After a DHCPINFORM broadcast, when a server sends a unicast reply to a client, the DHCPACK response to DHCPINFORM might get dropped by FWSM acting as a DHCP relay.
Workaround: Explicitly permit the communication from server (udp/67) to client (udp/68).
Routing Protocol Caveats
When the Cisco Anamoly Guard is used with an FWSM so that the Guard sits in front of the FWSM and scrubs all incoming traffic before forwarding it to the FWSM, TCP sessions that are intercepted by the FWSM may not work. This is because the FWSM, after intercepting the SYN, sends the SYN-ACK to the Guard instead of sending it to the next hop router.
Workaround: Do not enable TCP Intercept on the FWSM when using it with a Cisco Anamoly Guard.
With an FWSM with multiple contexts that share a common VLAN interface, TCP RST packets do not pass two FWSM contexts. The first context receives it and correctly tears down the connection in its connection table, but the RST is not forwarded to the second context where the connection will stay idle until it times out.
Workaround: Change the configuration so that VLAN interfaces are not shared. In other words, route all traffic between contexts using the MSFC or an external router.
FWSM may ignore the ARP reply from certain IP address if it has a static route to the host address.
If FWSM has route pointed to its interface, it does not route the packet.
When there are multiple routes learned off a single interface, the network processor may fail to be updated with those routes. This prevents packets from being routed properly. Route addition (for a new next hop) may be followed by deletion of the old route.
Workaround: Instead of add then delete, first delete then add.
With proper DSCP trust configured on the incoming physical ports and on the interface VLANs attached to the FWSM, DSCP is not being preserved when packets traverse the FWSM on a Sup720 system. This problem does not occur on a Sup2 system. This is a duplicate of CSCef71768.
Workaround: Configure no mls qos rewrite ip dscp in global configuration mode to retain the DSCP value through the FWSM.
System Message and SNMP Caveats
When using SNMP to retrieve monitoring information, a management session cannot be established to the FWSM device.
Workaround: Issue SNMP queries for the interface group at least once a minute to prevent the statistics cleaner thread from expiring all entries and terminating.
Voice Over IP Caveats
The alternative Address field does not get processed by H.323 application inspection (fixup) and the address does not get translated.
SIP calls that are passing through an FWSM may fail for certain values of the CSeq number used for the call. Before Release 2.3.3, FWSM uses a signed integer for the CSeq number when tracking SIP calls. However according to RFC 3261, this value should be an unsigned integer. A message similar to the following may be seen: SIP::Error - CSeq value 12345678917 is too big.
Traffic that is using application inspection intermittently fails. The host initiating the traffic that is subject to application inspection is also accepting the connections for the traffic that is subject to the application inspection.
Workaround: Disable the fixups in the configuration, or change the configuration to not use the same-security.
When issuing a command and then piping the output with the -v option without a subsequent parameter, the FWSM may spontaneously reload.
Workaround: This does not occur when a parameter is provided after the -v option.
If the show xlate command is issued with the interface option, incorrect information is displayed.
An FWSM in multi-context, transparent mode may drop packets to certain hosts when the traffic passes through two contexts inline. This happens when traffic goes from a higher to a lower security interface through one context and then from a higher to lower security interface in another context within the same FWSM.
Workaround: If failover is available, fail over to the standby FWSM then fail back to the active. This resets everything and traffic will flow again. If failover is not available, a reset of the FWSM will fix the problem.
FWSM may reload unexpectedly when the command debug packet interface_name ip_address netmask is issued.
This problem occurs with two Cisco Catalyst 6000s, each with an FWSM, with one configured as the active failover unit and the other as standby. FWSM is configured with two contexts on the active unit. The first context has higher security and lower security interfaces, while the second has only a lower security interface. To reach the second context on the standby unit, the packets has to go through the first context on the active unit.
Under these circumstances, if you configure AAA authentication for SSH, when you SSH to the lower security interface on the second context, packets to the first context on the active unit are denied.
When PAT is configured, the ICMP checksum for ping packets is not adjusted correctly.
When using FWMC to deploy a configuration that contains a line beginning with "FWSM," the device may crash.
Workaround: Remove any lines in the configuration that begin with "FWSM," or comment these lines out with an exclamation point (!).
When a client on one side of a FWSM initiates a connection by sending a SYN to a server on the other side, and the server replies with an RST, the RST is silently dropped by the FWSM. The result is that the client keeps retransmitting the SYN until it times out.
Given an FWSM with a stateful failover, multi-context configuration, the active FWSM in a failover pair reloads randomly and produces crash information (crashinfo) where the "Thread Name" indicated is fast_fixup. The problem occurs randomly after 2 hours and up to a few days of normal operation.
Using FWSM with nested object-groups (access lists) policies when memory utilization is approximately 25% will cause high CPU utilization and reloading of FWSM.
Workaround: Do not use the nested object-group policy. Use normal sequential network numbers (access lists) instead
When graphing in PDM with PDM history enabled, PDM fetches any historical data stored on the FWSM. The historical data stored on the FWSM has incorrect timestamps leading PDM to graph data points with incorrect times.
This problem occurs when failover is enabled between two FWSM blades on the same Cisco Catalyst 6000, and FWMC is using bulk deploy and manual access list commit. FWSM closes the connection without sending any response back, which causes FWMC to fail.
To clear IP address configurations for all configured interfaces on FWSM, the clear ip command can be used. However, if a command of form clear ip address int xxx is entered, the system ignores everything after clear ip and goes on to delete IP address configuration for all interfaces without any warning or error message.
Workaround: Do not enter the clear ip address int xxx command, which is not a valid command.
With overlapping networks on a FWSM, the static (high_security_interface,low_security_interface) global_IP local_IP mask dns command does not convert the DNS address if the route for the overlapping network is directed to the lower security interface.
Workaround: Use the deprecated alias command to convert the DNS IP address and the lower security static (without DNS) to make the xlate work.
FWSM crashes with doorbell_poll error. Not the same as CSCeg67681, even though the system network processor is hitting a hard assert in the fast path.
In a failover pair, configured for intra-chassis failover or inter-chassis failover, the active FWSM stops forwarding packets for a few seconds when the standby unit is reloaded if logging host is enabled.
Workaround: Disable logging host or remove logging host and write memory on the standby unit before reloading the standby FWSM.
When receiving numerous interface-related parameters simultaneously, the FWSM may exhibit high CPU utilization or unexpectedly reload when polling for the interface-related parameters.
After applying the fix for CSCef82739, the uptime of the FWSM will not display correctly after the system has been operational for more than 49 days, 17 hours.
Resolved Caveats in Software Release 2.3(2)
Pressing Ctrl-z while editing an item name (for example, when the cursor is in the middle of the name of the access list) causes this item to be stored together with Ctrl-z. This action will cause an incomplete configuration when booting up.
Workaround: Ensure that you only use Ctrl-z on an empty line. If you encounter an incomplete configuration, copy the startup configuration to a TFTP server, inspect the configuration for the presence of the Ctrl-z characters (ASCII code 26) with the appropriate editor (one capable of showing the non-printable characters), and remove them. After correcting the problem, copy the configuration back from the TFTP server to the startup configuration and reboot the FWSM.
When the OSPF access lists are added in manual mode, the entries are shown as uncommitted additions and deletions, even after the commit. The access lists are not added to the Network Processor.
Workaround: Use auto-mode for making any changes to the OSPF access lists.
After the standby FWSM reloads, it loses its SSH key.
The system message FWSM-6-302016 does not have the byte count, duration, or interfaces associated with the connection.
The system message FWSM-6-109025 is being erroneously displayed for secure HTTP and HTTPS users with downloadable access lists.
When moving from single to multiple context mode on the FWSM, the object-group descriptions may not convert correctly.
Workaround: Reconfigure the descriptions after enabling multiple context mode.
If a device is attached to the physical console port on the FWSM, there is a possibility that the FWSM will hang if certain characters are sent to the console port. The console port is an internal port on the module, and it is not accessible from the front of the module. You should not use this port without specific directions from the Cisco TAC.
Workaround: Do not attach anything to the physical console port.
After changing the administration distance of a static route to be higher than the OSPF default administration distance, the FWSM still takes the static route. The show route command displays both routes.
The expected result is after changing the static administration distance, the OSPF administration distance should take over as the preferred route. The higher administration distance static route should not display in the show command route table.
Workaround: Pass the correct flag to account for a static route addition.
On a host running the FWSM device manager in transparent mode, if you configure the IP address and enter the setup command, the following error is displayed:
The HTTP address is not set on the FWSM and the FWSM device manager is unable to communicate with the module.
Workaround: When the setup is complete, you must enter the http ip_addr_of_FWSM_Device_MGR mask interface command.
When a policy NAT is configured and a static statement already exists with the same address, the traffic goes through without a problem the first time but it will not go through a second time.
Workaround: Remove the static statement.
The clear local command clears the authenticated user for the traffic that has fixup enabled.
With the fix for CSCef02740, the FWSM no longer displays the "I" or "O" flags in the output of the show conn command. These flags are used to determine if the inside host has sent a data packet (I), or if the outside host has sent a data packet (O). Without these flags, you cannot determine if a TCP data packet has been sent from either the client or server. Traffic flowing through the module is not affected.
The system message FWSM-3-210007 has the incorrect recommended action in the documentation.
The system message FWSM-6-302013 and FWSM-6-302014 do not contain the interface information as described in the documentation.
If AAA is configured and a DOS text-based FTP program is used to FTP files, blocked files are denied by WebSense and the FWSM, but the FWSM fails to print msg 550, "550 Requested file is prohibited by URL filtering policy," and the FTP program hangs until it times out.
Workaround: Do not to use an FTP text-based program.
In transparent firewall mode, if you enter the virtual http or virtual telnet command, there is a delay in establishing a connection to the virtual IP address on the FWSM.
Resolved Caveats in Software Release 2.3(1)
When upgrading from FWSM software release 1.1(3) to release 2.3(1), the failover link statements may not carry over as part of the conversion of the failover statements to a newer format. The stateful failover information number is not passed to the standby device.
Workaround: Remove the nameif statement for the failover link, re-configure with the correct VLAN number, and configure the failover ip command for the failover link.
The FWSM fails to respond after receiving invalid characters embedded in an email address contained in the SMTP inbound traffic when SMTP fixup is enabled.
Workaround: Disable SMTP fixup.
Two FWSMs configured as a failover bundle and running OSPF may experience problems establishing OSPF adjacencies after sequential failover sequences. This problem is diagnosed by looking at the DR/BDR status on the peer interfaces. When this situation exists, there is usually a discrepancy between the FWSM and the neighbor.
Workaround: Set the OSPF priority to zero or clear the IP OSPF process on the FWSM.
If a user authenticates with RADIUS for a management connection to the FWSM, and you configure a downloadable access list on the RADIUS server for the user, then the FWSM downloads the access list but fails to bind it to the user authentication session. If the user sends traffic through the FWSM while this authentication session is active, the access list will not be in effect, and the user will have unrestricted access (according to the access list associated with the interface). Also, because the access list is not bound to the session, when the session times out, the access list is not removed from the running configuration. This access list uses up the memory on the FWSM.
Workaround: You cannot remove this access list alone because it has a special name. You can either remove all access lists using the clear access-list command or reload the FWSM. To ensure authorization for users who have administrative access, we suggest that you use a TACACS+ server for authorization instead of downloadable access lists, or use the local database for CLI authentication so the RADIUS authentication is not triggered.
Virtual Telnet and virtual HTTP IP addresses are not being passed down into network processor (NP) 3. This situation causes the FWSM to not respond to ARP requests for the virtual IP addresses, and the packets directed to the virtual IP addresses are dropped.
For user authorization in single context mode, the FWSM does not support the downloadable access lists from a RADIUS server.
Workaround: Configure the access lists on the FWSM and then download the access list name from the RADIUS server.
If you configure outside NAT for a host, a SQL*Net session through the FWSM for the host fails. The FWSM sends the local untranslated IP address of the outside host to the inside host, and eventually the session times out.
Workaround: Use static NAT for the outside hosts that use SQL*Net.
The resource manager does not count more than one FTP data channel per FTP control channel, and therefore does not count any additional data channel connections toward the connection limit. Also, the show resource usage command does not display these connections.
In some circumstances, when you configure a limit on the TCP connections as well as a limit on embryonic connections in a nat or static statement, a denial of service (DoS) condition might occur. The UDP connection limits are not affected.
Workaround: We recommend that you configure only one of these limits at a time for a given nat or static statement, and leave the other at the default of 0 (unlimited, up to the maximum for the system). If you configure both limits, and the show local-host command indicates that the maximum number of TCP connections has been reached, then enter the clear local-host command to clear the condition.
After a unit fails over, the connections that are not actively exchanging data are not replicated back to the original active unit. As a result, if the current active unit fails over, the state of the connection is lost.
If you configure the active unit for manual access list commitment (the access-list mode manual-commit command), when the active unit replicates the configuration to the standby unit, none of the access lists on the standby unit are committed, even when they are committed on the active unit.
Workaround: Do not use manual commitment (set the access-list mode auto-commit command) on the active unit, at least while the standby unit is synchronizing the configuration. Or, after the standby unit synchronizes, enter the access-list commit command on the standby unit to commit all access lists.
In single context mode, the standby unit might reboot if you attempt to copy a configuration to the running configuration on the standby unit, and simultaneously enter the copy running-config startup-config (or write memory) command on the active unit.
Workaround: Do not configure the standby unit while you are configuring the active unit; the standby unit should get all its configuration through the replication process. Configuring the standby unit causes the units to get out of synchronization.
If you configure the failover poll and hold times (failover polltime unit) to be less than the default, and enable manual commitment of access lists (the access-list mode manual-commit command), when you commit a large access list on the active unit using the access-list commit command, then the failover communication is disrupted and the active unit fails over to the standby unit.
Workaround: Increase the failover unit poll and hold times to greater values (for example, the default of 1 second for the polltime and 15 seconds for the holdtime).
If you configure a static command using the interface keyword to specify the interface address, and if you change the interface IP address, the change is not reflected in the static translation.
When you configure the same security interfaces, the NAT exemption statements (nat 0 access-list) are ignored. You might use the NAT exemption statements to set the connection limits when you do not want to perform address translation.
Workaround: Use identity NAT (nat 0) or static identity NAT.
When you configure the embryonic limit for an inside static statement, and you also configure dynamic PAT for an outside interface, then a SYN attack from the outside to the inside static address causes a large number of PAT translations with the associated connections, even though the connections are not established. These PAT translations do not time out within the default 30-second interval for translations without the associated connections because the FWSM thinks there are valid connections associated. The pool of addresses and ports for the outside addresses is depleted, and no additional clients can connect.
Workaround: Do not configure outside PAT if you want to protect the inside address from a SYN attack using an embryonic limit.
All access lists have an implicit deny at the end consisting of deny ip any any. When a packet is dropped because of the implicit deny, the FWSM does not generate the system message 106023 that indicates when a packet is dropped by an access list.
Workaround: Add an ACE consisting of deny ip any any at the end of the access list. When you have an explicit ACE, you can set additional logging options as well.
When the maximum number of deny flows is reached for ACE logging, the FWSM generates system message 10601. However, if you set the alert interval for this message to be greater than the default 300 seconds, then the FWSM does not generate the message.
Workaround: Set the access-list alert-interval command to be 300 seconds or less.
Inter-cluster Cisco CallManager (3.3) trunks, connected without the use of Gatekeepers (one Cisco CallManager connected directly to another Cisco CallManager), often experience delayed or disrupted call setup and voice path connections. The majority of calls are successful.
Workaround: Use either Gatekeeper-controlled inter-cluster trunks, or use Cisco CallManagers on two FWSM interfaces of the same security level.
See the following sections for related documentation:
See the following related hardware documentation:
•Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Installation Note
•Catalyst 6500 Series Switch Installation Guide
•Catalyst 6500 Series Switch Module Installation Guide
See the following related software documentation:
•Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide
•Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference
•Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Logging Configuration and System Log Messages
•Catalyst 6500 Series Cisco IOS Software Configuration Guide
•Catalyst 6500 Series Cisco IOS Command Reference
Obtaining Documentation and Submitting a Service Request
For information about obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)