<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"> 
  <channel>
  <title>Adaptive Security Appliance Hot Issues from Cisco TAC</title>
  <link>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</link>
  <description>Hot Issues from Cisco TAC.  Please click the link for complete details.</description>
  <language>en-us</language>

  <managingEditor>wsisk@cisco.com (Wes Sisk)</managingEditor>
  <webMaster>news-at-cisco-rss@cisco.com (Cisco Newsroom)</webMaster>
  <pubDate>Mon, 8 Feb 2010 12:44:17 EST</pubDate>
  <lastBuildDate>Mon, 8 Feb 2010 12:44:17 EST</lastBuildDate>
  <generator>PERL</generator>

  <docs>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</docs>
  <ttl>10080</ttl>

<item>
<title>Duplicate ASP crypto table entry causes firewall to not encrypt traffic , Fixed CSCtb53186</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb53186</link>
<description>Symptom:
When testing 100 site to site vpn connections on  an ASA running 8.2.1 one or two tunnels would not encrypt traffic.

The connections were established and dropped multiple times before seeing this issue.
&lt;br&gt;
Conditions:
&quot;sho asp table vpn-context detail &quot; shows duplicate crypto table entries. Two current and one left over from previous connection.

This creates the problem of the traffic not being encrypted.
&lt;br&gt;
Workaround:
Reload ASA.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb53186</guid>
</item>
<item>
<title>, Open CSCsw48786</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsw48786</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
When enabling URL filtering on the Cisco ASA 5500 Series Content Security and Control Security Services Module (CSC-SSM), web browsing may be unreasonably slow. This is usually due to a misconfiguration or issue within the network that is time consuming to diagnose from a TAC perspective. This bug is a request to add some troubleshooting tools to the CSC interface to assist TAC in supporting the end user..
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

This covers all versions of CSC code.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
N/A

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsw48786</guid>
</item>
<item>
<title>, Open CSCtd36473</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd36473</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
Outbound encryption traffic in an IPsec tunnel may fail, even if inbound decryption traffic is working.






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This issue has been observed on an IPsec connection after multiple rekeys, but the trigger condition is not clear. The presence of this issue can be established by checking the output of &quot;show asp drop&quot; and verifying that the Expired VPN context counter is increasing for each outbound packet sent.




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None.



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd36473</guid>
</item>
<item>
<title>ASA 8.0(5) - &quot;LU allocate connection failed&quot; , Open CSCte80027</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte80027</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
%ASA-3-210005: LU allocate connection failed error messages on standby unit caused by failed replication of IPSec connections. In debugs message &quot;Failed to create flow (dropped)&quot; can be seen 
for subnet which is actually pool created for IPSec connections...and it seems that the reason for flow replication failure was because of acl-drop...
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA in failover mode running 8.0(5)
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Downgrade to 8.0(4) code


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte80027</guid>
</item>
<item>
<title>ASA5580 traceback in thread DATAPATH-2-476, eip rt_timer_cancel_callback , Open CSCte43903</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte43903</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
ASA5580 traceback on thread name DATAPATH-2-476
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Observed on 8.2.1.11
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
No known workaround


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte43903</guid>
</item>
<item>
<title>ASA fails to redirect traffic to WCCP cache server , Fixed CSCsy82260</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy82260</link>
<description>At certain occasions after a failure the ASA fails to redirect traffic on TCP ports 80 and
443 to the WCCP cache servers. This problem occurs at any time during the day. We have
observed that the problem always happens after a failure in the network that causes the
ASA to momentarily lose communicate with the WCCP servers. This can be a failure initiated on
the WCCP servers themselves or any connection devices between the ASA and the WCCP
servers.  We have two (2) WCCP cache servers, if any one of these servers is brought down
for maintenance, we experience the problem as well. Traffic will not be redirected to the
remaining online server.  The 1st thing we see on the ASA is log messages indicating
communication with web-cache server has been lost, as shown below:
 
Mar 06 2009 08:52:03: %ASA-1-332004: Web Cache 172.20.143.11/90 lost
Mar 06 2009 08:52:03: %ASA-1-332004: Web Cache 172.20.143.11/91 lost
Mar 06 2009 08:52:03: %ASA-1-332004: Web Cache 172.20.143.11/92 lost

The IP addresses for our web-cache servers are 172.20.143.11 and 172.20.143.12. When the
connection failure caused by what ever reason (outside of the ASA itself) is restore, no
traffic is redirected by the ASA. The show WCCP commands show everything is normal, it is
able to talk with the web-cache servers. The symptoms that were observed in
troubleshooting were that &quot;show wccp 90 detail&quot; on the ASA displayed redirected packet
counters that were not incrementing. All other WCCP diagnostics appeared normal
(Here I Am &amp; I See You heartbeat packets were incrementing) on both the ASAs and the Blue
Coat proxies, and &quot;show wccp 90&quot; on the ASA indicated 1 WCCP router (the ASA) and 2 WCCP
caches (the Blue Coat proxies), as expected. User traffic will be reaching the internet
directly without redirection. We did not notice this problem until after upgrading the ASA
code to 8.1.2(11) code on 02/02/2009. The previous code were running prior to that was
8.1.2(7). The problem could have been there on the previous code but we just did not
notice it until we were running 8.1.2(11). Please note we do not see this problem at all
when the ASA itself fails or is reloaded. It always occurs when there is any other failure
which causes web-cache communication to be lost
 

Work around

The steps outlined below show how we resolve this issue when it happens.
 
 
1.  Disable WCCP on Blue Coat proxy 1 and proxy 2.
 
2.  Remove the WCCP commands on the ASA:

no wccp interface inside 90 redirect in
no wccp 90 redirect-list 101 password Bluecoat
no wccp 91 redirect-list 133 password Bluecoat
no wccp 92 redirect-list 134 password Bluecoat
no wccp 93 redirect-list 135 password Bluecoat
no wccp 94 redirect-list 136 password Bluecoat
no wccp 95 redirect-list 137 password Bluecoat
no wccp 96 redirect-list 138 password Bluecoat
no wccp 97 redirect-list 139 password Bluecoat
 
3.  Reconfigure WCCP commands on the ASA:

wccp 90 redirect-list 101 password Bluecoat
wccp 91 redirect-list 133 password Bluecoat
wccp 92 redirect-list 134 password Bluecoat
wccp 93 redirect-list 135 password Bluecoat
wccp 94 redirect-list 136 password Bluecoat
wccp 95 redirect-list 137 password Bluecoat
wccp 96 redirect-list 138 password Bluecoat
wccp 97 redirect-list 139 password Bluecoat
wccp interface inside 90 redirect in
 
 
4.  Enable WCCP on Blue Coat proxy 1 and proxy 2.
 
 
5.  Observe that Here I Am &amp; I See You heartbeat packets were incrementing on both the
ASAs and the Blue Coat proxies.
 
 
6.  Observe that redirected packet counters were incrementing on the ASA.
 
 
7.  Confirm from our PCs that web traffic was being redirected from the ASA to the Blue
Coat proxies for authentication and filtering.
 


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy82260</guid>
</item>
<item>
<title>ASA traceback in Thread Name: Dispatch Unit, Abort: Assert Failure , Fixed CSCta55072</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta55072</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

ASA intermittent crash at Thread Name: Dispatch Unit, Abort: Assert Failure
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Running 8.2.1version.
The ASA5505 box has a basic license with Inside hosts limit. When the total number of inside hosts exceeds the limit, it may trigger the crash. 
If there is no limit for inside hosts with the license, the crash won&#39;t be triggered.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

No workaround
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta55072</guid>
</item>
<item>
<title>ASA dropping the packet instead of encrypting it. , Open CSCso50996</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso50996</link>
<description>
Symptom:
ASA/PIX stops encrypting data to a remote IPSec peer (either L2L or Remote
Access).  
&lt;br&gt;  
Conditions:
The problem is that after an IPSec SA goes down and comes back up (including
phase 2 rekeys), it&#39;s possible that a duplicate vpn-context and classifier
entry are created and added to the ASA&#39;s ASP classifier table for crypto.  The
ASA should only have a single ASP classifier/vpn-context per IPSec flow (ie.
inbound vs. outbound) in its database.
&lt;br&gt; 
  
Workaround:
Reload the ASA.
  
 
 



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso50996</guid>
</item>
<item>
<title>CSC 6.3 kernel&#39;s TCP stack conn closing can cause corrupt http pages , Fixed CSCtd04067</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd04067</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;
When browsing pages through the CSC module, sometimes some pages might not fully load, or load half, or corrupt, or with scrambled content.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Only running CSC 6.3 and browsing using IE.
Note that this is not a common case. In other words, in case there are corrupt pages or loading issues, that should not always be attributed to the CSC module.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Downgrade to CSC 6.2.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;
This behavior is only noticed when the browser sends an extra TCP ACK, Window Update packet after ACKing the 200_OK with FIN flag set. If the browser sends a FIN after the ACK to the 200_OK FIN the pages shows properly. It was noticed in some corner cases only using IE. Firefox worked ok. Packet captures on the browsing client show RSTs coming from the server when the client does not send a FIN after ACKing the final 200_OK with FIN flag set from the server.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd04067</guid>
</item>
<item>
<title>, Fixed CSCtb17498</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb17498</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

ASA traceback in &#39;Thread Name: ssh&#39; when working with captures
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Captures configured on ASA.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb17498</guid>
</item>
<item>
<title>Traceback in scheduler , Fixed CSCsk85428</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsk85428</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Traceback in scheduler.  This traceback could happen in any thread.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Cisco ASA/PIX running some versions of 7.0, 7.1, and 7.2. This condition is a very rare timing condition .  It is not induced or affected by any configuration on the box or any external stimulus.  It could happen in any release after the following releases:

007.000(006.037) 007.001(002.058) 007.002(002.027)
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsk85428</guid>
</item>
<item>
<title>CSC does not recover by itself from auto update corruption , Open CSCtc37947</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc37947</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

Some signatures may fail to update even though a newer version of signatures is available in TrendMicro repository.






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Sporadic, during normal operation. 




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

From root account on CSC remove the temporary files created for auto update.
Restart the services.



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc37947</guid>
</item>
<item>
<title>ASDM fails to load due to out of DMA memory when logging is configured , Fixed CSCtb58989</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb58989</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;
 ASDM fails to load on ASA 8.2, due to no available DMA memory.
 This issue occurs if logging is enabled along with crypto tunnels.
&lt;br&gt; 
 
 &lt;B&gt;Conditions:&lt;/B&gt;
 Logging is enabled.
 Crypto (IPSec, SSL) is also enabled.
&lt;br&gt; 
 
 &lt;B&gt;Workaround:&lt;/B&gt;
 Downgrade ASA to 8.0.x or configure the logging queue to a value of 512. After
restoring the logging queue to default, need to reload the box to reclaim DMA
memory.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb58989</guid>
</item>
<item>
<title>, Fixed CSCsx99960</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx99960</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;

Secondary ASA 5580 running in active/active failover mode having group 2 as active crashed in CP Processing thread   --&gt;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA running 8.1.1.12 with normal work load.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None--&gt;
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx99960</guid>
</item>
<item>
<title>access-list logging prints 106100 syslog always at informational level , Fixed CSCsz73284</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz73284</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Logging message 106100 always prints at level informational. As a result, logging message 106100 is not printed when logging level is set to lower than informational for both access-list and logging configuration 
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
Syslog level set to lower than informational (level 6) for both access-list and logging
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
configure the following:
logging list mylist level notifications
logging list mylist message 106100
logging trap mylist

This will allow only notification level syslogs and 106100 to be logged.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz73284</guid>
</item>
<item>
<title>WebVPN: Implement Split Tunneling w Smart Tunnels , Open CSCsi40901</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsi40901</link>
<description>Symptom:

Currently, WebVPN Smart-Tunnel configuration will not support Split Tunneling with Smart Tunnels

This bug is an enhancement request to have smart-tunnel configuration working with Split Tunneling 
&lt;br&gt;
Conditions:

ASA 8.0.2 or 8.0.3 code with Clientless WEBVPN and Smart-Tunnel configured
&lt;br&gt;
Workaround:

If you connect with IE all subsequent IE processes will be ST if SmartTunnel lists are used. Therefore, to be able to reach a site and not  through the ST launch and use a different browsers, such as FireFox. Same principal applies if the WebVPN and SmartTunnel was launched in FireFox then Internet Explorer (IE) will not be tunneled, thus achieving the split tunnel effect until this feature is implemented.

FYI:
Ensure no add-ons in FireFox prevent the SmartTunnel from launching and allow the ASA to be ALLOWED in the FF add-ons under Tools &gt; Options &gt; Security &gt; enable &#39;Warn me if sites try to install add-ons&#39; &gt; Exceptions then add the ASA FQDN or IP address in the Allow Site list.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsi40901</guid>
</item>
<item>
<title>PP: One way audio between out-phones when they are behind a Nat router , Fixed CSCsz49463</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz49463</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;

There is one way audio between 2 outside phones if they are behind a NAT router and the ASA is configured with Interface MTA. 
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;

The work around for this issue is to configure Global MTA instead of interface MTA on ASA. 


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz49463</guid>
</item>
<item>
<title>coredump.cfg file gets rewritten every time show run is executed , Fixed CSCsz85597</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz85597</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Each time you issue a &quot;show running-config&quot; on an ASA, the coredumpinfo/coredump.cfg on the flash gets rewritten.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

&quot;show running-config&quot; is issued on an ASA running 8.2(1) or later
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz85597</guid>
</item>
<item>
<title>, Fixed CSCtb42871</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb42871</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

ASA 8.2.1 crashes in Thread Name: PIX Garbage Collector







&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

software 8.2.1




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb42871</guid>
</item>
<item>
<title>the procedure of copying a file from ramfs to flash should be atomic , Fixed CSCsy77628</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy77628</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
&quot;%ERROR: copying &#39;disk0:/csco_config/97/customization/index.ini&#39; to a
temporary ramfs file failed&quot; or similar message






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
During WebVPN customization configuration (while pushing config files)




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Issue &quot;revert webvpn all&quot; to clear all WebVPN config and reconfigure from scratch.



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;
n/a














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy77628</guid>
</item>
<item>
<title>CSC module to support https requests in URL filtering , Open CSCsh18404</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsh18404</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

When users access web pages via &quot;https&quot; URLs, those requests are not
being sent to the URL filter server for lookup.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

CSC module running any code version.  URL blocking and/or
filtering enabled.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None known.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

This is an enhancement request to be considered for implementation
by Trend Micro.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsh18404</guid>
</item>
<item>
<title>IMPORTANT TLS/SSL SECURITY UPDATE , Fixed CSCtd00697</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd00697</link>
<description>Summary:
An industry-wide vulnerability exists in the Transport Layer Security (TLS) protocol that could impact any Cisco product that uses any version of TLS  and SSL. The vulnerability exists in how the protocol handles session renegotiation and exposes users to a potential man-in-the-middle attack.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml




</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd00697</guid>
</item>
<item>
<title>, Fixed CSCsy71401</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy71401</link>
<description>Symptom:

The ASA will crash if changes are made to an object group. The crash thread will be whatever process was used for connecting to the ASA (ssh, telnet, ci console, etc).

The crash dump will indicate that CPU and Memory were at 99% utilization.
&lt;br&gt;
Conditions:

Object groups must be used by the ASA in the ACL.
&lt;br&gt;
Workaround:

None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy71401</guid>
</item>
<item>
<title>show memory in a context shows incorrect memory usage , Open CSCsx64778</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx64778</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Some contexts in a PIX/ASA may show excessively high memory consumption when
issuing the &quot;show memory&quot; command. The issue is purely cosmetic.

In the system mode, the memory use looks normal:
########
show mem detail
Free memory:                     402674352 bytes (75%)
Used memory:
     Allocated memory in use:    111063456 bytes (21%)
     Reserved memory:             23133104 bytes ( 4%)
-----------------------------   ----------------
Total memory:                    536870912 bytes (100%)
###################

However in a context, it may not look normal:

#########
------------------ Context ------------------


show mem detail
Used memory:       377256744 bytes (70%)
-------------     ----------------
Total memory:      536870912 bytes (100%)

Most used memory: 4294967088 bytes (800%)

RVAPstm03/IMB# show mem detail
Used memory:       377367216 bytes (70%)
-------------     ----------------
Total memory:      536870912 bytes (100%)

Most used memory: 4294967088 bytes (800%)
###########################################
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

This issue is purely cosmetic and does not appear to have any performance impact.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

There is no known workaround at this time.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx64778</guid>
</item>
<item>
<title>, Fixed CSCta03382</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta03382</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
With SQLNET inspection Oracle database connection drops errors with
-ORA-12569 TNS packet checksum failure
-ORA-03106 fatal two-task communication protocol error
if a specific query sent.

Also, the following syslog may be printed:
%ASA-4-507003: tcp flow from dmz:172.20.1.1/65000 to inside:172.16.1.1/1521 terminated by inspection engine, reason - proxy inspector drop reset.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
ASA with SQLNET inspection
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disabling SQLNET inspection is an option as long as they are not doing NAT.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta03382</guid>
</item>
<item>
<title>Double authentication broken in 8.2.2 when use-primary-username is conf. , Open CSCte66568</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte66568</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
ASA 8.2.2 might cause authentication issues on WebVPN portal while AnyConnect works still great.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Double authentication is configured under tunnel group in use.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Removing the &quot;use-primary-username&quot; option from the config will allow the connection to proceed.  The user will have to type their user name in twice though.
Disabling the double authentication or downgrading to 8.2.1 acts as only workaround for now.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte66568</guid>
</item>
<item>
<title>Traceback in Thread Name: Unicorn Admin Handler , Open CSCta02170</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta02170</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

ASA reloads due to block corruption.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA5550 or ASA with 4GE I/O module running 8.2.1 code and using interfaces in slot 0 and slot 1. 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Do not use interfaces in slot 1 since this triggers the problem.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta02170</guid>
</item>
<item>
<title>H323 inspection fails when multiple TPKT messages in IP packet , Fixed CSCta62631</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta62631</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
When H323 traffic is traversing the ASA, and if that H323 traffic has IP packets that contain multiple TPKT messages, the firewall might fail to correctly process the H323 information and perform the necessary inspections. One symptom might be that internal IP addresses in the payload of the TCP packets are not correctly &quot;fixed-up&quot; by the firewall if they are subjected to address translation on the firewall.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
All of the following conditions must be met to hit this problem:
1) H323 traffic must traverse the firewall, and the IP packets in these flows must contain more than one TPKT message per IP packet.
2) The H323 inspection must be enabled on the firewall. 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Remove the H323 inspection with the command &#39;no inspect h323&#39; in the policy applied to the firewall,  open the access-lists to allow the necessary audio streams, and ensure the H323 endpoints are not subjected to NAT by the firewall.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta62631</guid>
</item>
<item>
<title>WEBVPN: page fault in thread name dispath unit, eip udpmod_user_put , Fixed CSCtb64913</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb64913</link>
<description>&amp;lt;B&amp;gt;Symptom:&amp;lt;/B&amp;gt;

ASA crashes in Thread Name: Dispatch Unit

&amp;lt;B&amp;gt;Conditions:&amp;lt;/B&amp;gt;

Experienced in interim releases 8.0.4.29 &amp;amp; 8.0.4.32

&amp;lt;B&amp;gt;Workaround:&amp;lt;/B&amp;gt;

none at this time

&amp;lt;B&amp;gt;Further Problem Description:&amp;lt;/B&amp;gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb64913</guid>
</item>
<item>
<title>ASA not displaying pictures on the portal page , Open CSCtd28327</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd28327</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

ASA not displaying some pictures on the login/portal page. Instead a &quot;Logo&quot; text is shown
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA running 8.0(5) image and image size has to be above 17K
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Downgrade to any 8.0(4) interims or upgrade to 8.2(1) which is unaffected.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd28327</guid>
</item>
<item>
<title>, Fixed CSCsy75345</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy75345</link>
<description>

 &lt;B&gt;Symptom:&lt;/B&gt;
 
 In certain condition (mainly in failover mode) the standby address cannot be
pinged and show failover show the interface flapping or in Normal (Waiting) state
&lt;br&gt; 
 &lt;B&gt;Conditions:&lt;/B&gt;
 - you use 4ge-ssm
 - you have configured on some port &lt;8 subinterface and in some others &gt;8
subinterface:
 example:
 
 context blah1
   allocate-interface GigabitEthernet0/3 
   allocate-interface GigabitEthernet0/3.1 
   allocate-interface GigabitEthernet0/3.10-GigabitEthernet0/3.11 
   allocate-interface GigabitEthernet1/0.10 
   allocate-interface GigabitEthernet1/1.10-GigabitEthernet1/1.21
 &lt;---------- (&gt; 8 subint)
   allocate-interface GigabitEthernet1/1.44 visible
   allocate-interface GigabitEthernet1/2.10-GigabitEthernet1/2.15
 &lt;-----------  (&lt; 8 subint)
&lt;br&gt; 
 &lt;B&gt;Workaround:&lt;/B&gt;
 
 can be to set ALL the ports to have &gt;8 subinterface
&lt;br&gt; 
 &lt;B&gt;Further Problem Description:&lt;/B&gt;
 
 


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy75345</guid>
</item>
<item>
<title>Page fault in IP thread under high traffic load , Open CSCsr25122</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr25122</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Tracebacks with Thread name : IP Thread
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Usually when the device is under heavy load with both through and to-the-box traffic.
Note: The problem is present only on ASA 8.0 and later releases.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none at this time
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

Tracebacks on active failover PIX with Thread name : IP Thread
Also could occur on standalone PIX.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr25122</guid>
</item>
<item>
<title>ASA :: VPN-Session incorrectly shows 100% Load for sslvpn , Open CSCsz23972</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz23972</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
vpn-sessiondb will incorrectly show 100% load when no users are connected. This will prohibit new sessions from being created.  
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
seen in 8.0.4.28 after 12 days of uptime.  ASAs in failover pair
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

reload ASA
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz23972</guid>
</item>
<item>
<title>ASA traceback in thread IPsec message handler , Terminated CSCtd99335</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd99335</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

ASA may reload with the thread in IPsec message handler 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA running 8.2.1.12 release.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Upgrade to 8.2.2

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd99335</guid>
</item>
<item>
<title>IKE FSM for AM responder gets into bad state + error loop , Fixed CSCsq91271</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsq91271</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
IKE FSM in error loop for a deleted user (not in the config anymore), no actual IKE exchange taking place.

[IKEv1]: Group = group, Username = username, IP = 10.1.1.1, Reaper overriding refCnt [0] and tunnelCnt [0] -- deleting SA!
[IKEv1]: Group = group, Username = username, IP = 10.1.1.1, SA lock refCnt = 0, bitmask = 00000080, p1_decrypt_cb = 0, qm_decrypt_cb = 0, qm_hash_cb = 0, qm_spi_ok_cb = 0, qm_dh_cb = 0, qm_secret_key_cb = 0, qm_encrypt_cb = 0
[IKEv1 DEBUG]: Group = group, Username = username, IP = 10.1.1.1, IKE AM Responder FSM error history (struct &amp;0x4e41b20)  &lt;state&gt;, &lt;event&gt;:  NullState, EV_RCV_DELETE--&gt;NullState, NullEvent--&gt;NullState, EV_START_TM--&gt;AM_STANDBY_REKEY, EV_START_TM--&gt;AM_TM_INIT_XAUTH_V6H, EV_RESEND_MSG--&gt;AM_TM_INIT_XAUTH_V6H, NullEvent--&gt;AM_TM_INIT_XAUTH_V6H, EV_ACTIVATE_NEW_SA--&gt;AM_TM_INIT_XAUTH_V6H, NullEvent
[IKEv1]: fsmDriver returned error






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
7.2.4, cause unclear




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none (reboot would most likely solve the issue)



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;
none so far














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsq91271</guid>
</item>
<item>
<title>ASA 8.0.5 snmp-server re-configuration can cause socket used messages , Fixed CSCte18319</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte18319</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
As of ASA 8.0.5 following messages can be seen when snmp-server is reconfigured:
--------------
UDP: ERROR - socket &lt;unknown&gt; 41216 in used
--------------
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
Not seen in ASA before 8.0.5
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Not known at the moment.
&lt;br&gt;
&lt;B&gt;Further description&lt;/B&gt;
This is not related to CSCsy69368 but related to minor bug CSCta09453.

A possible sequence that can lead to this behavior is:
- configure snmp-server
- clear whole configuration for snmp-server (clear configure snmp-server)
- re-reconfigure snmp-server



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte18319</guid>
</item>
<item>
<title>SSH resource exhausted preventing further sessions , Fixed CSCsm68097</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsm68097</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Under a rare occurance, SSH sessions for management access can become locked preventing further SSH connections to be established to the ASA.  
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
ASA 8.0(2), 8.0(3)
SSH enabled
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
A reload will clear the hanged SSH sessions.
-other types of connections still function (telnet,console)
-downgrade to 7.x code

&lt;B&gt;Other Notes:&lt;/B&gt;
Following best practices, its always advisable to only accept SSH from trusted hosts.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsm68097</guid>
</item>
<item>
<title>Fuzzing testbed, traceback in the javascript parser , Open CSCta06013</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta06013</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

ASA running 8.0.5 may reload in Unicorn Proxy Thread.






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA running 8.0.5 code.




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none.



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

Issue seems to be related to javascript parser.














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta06013</guid>
</item>
<item>
<title>&quot;possible channel leak&quot; when loading with large configuration , Open CSCte55194</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte55194</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
CLI access to the ASA may hang with one of the following messages when processing an extremely large configuration:

release: possible channel leak in fover_parse

release: possible channel leak in pix_flash_config_thread.

release: possible channel leak in ssh
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Downgrade to 8.2(1)


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte55194</guid>
</item>
<item>
<title>Traceback when using packet tracer , Terminated CSCsi21609</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsi21609</link>
<description>&lt;br&gt;Condition:  PIX or ASA reloads when injecting a packet via the packet-tracer tool

Symptom:  PIX or ASA running 7.2.2 or later.  
&lt;br&gt;
Workaround:  Don&#39;t use the packet tracer.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsi21609</guid>
</item>
<item>
<title>Traceback:: IKE daemon - Traversing MIB Logged-in User Database , Fixed CSCsz55540</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz55540</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

ASA crashes in Dispath Unit or Checkheaps or Ike daemon
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Has been seen on 7.2.4.31

Involve large use of vpn clients or l2tp over ipsec clients

SNMP monitoring of the session manager MIB such as

session_count = &quot;1.3.6.1.4.1.9.9.392.1.3.3.0&quot;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

This issue is not occurring on the latest 8.0 release.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz55540</guid>
</item>
<item>
<title>Traceback in Thread Name: Dispatch Unit with inspect h323 , Fixed CSCsk96804</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsk96804</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

PIX/ASA may crash while running 7.2(3) on Thread Name Dispatch Unit
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
- Software versions 7.2(3.12) and 8.0(3)
H.323 inspection
Lot of H323 setup requests.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None available.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsk96804</guid>
</item>
<item>
<title>Assert in access_list.c when viewing v4 ACL with v6 addresses configured , Open CSCte41930</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte41930</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
When trying to view an IPv4 access-list that contains IPv6 addresses the ASA crashes and issues the following message: 
&lt;i&gt;assertion &quot;hp-&gt;ip_version == IP_VERSION_4&quot; failed: file &quot;access_list.c&quot;, line 6249 &lt;/i&gt;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This is technically a misconfiguration.
The misconfiguration is accomplished by nesting object groups within each other

&lt;blockquote&gt;
object-group network v4-address
 network-object 10.10.10.0 255.255.255.252
!
object-group network v6-address
 network-object fd70:415f:59b0:946b::/64
!
object-group network v4-v6-group
 group-object v4-address
 group-object v6-address

access-list crash permit tcp object-group  v4-v6-group any eq ftp 
&lt;/blockquote&gt;

This configuration will be accepted by the command line without any errors, but once &lt;b&gt;write mem&lt;/b&gt; or &lt;b&gt;show run&lt;/b&gt; is issued the device will crash.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
This is due to a misconfiguration. Do not configure IPv6 addresses in IPv4 access-lists. 


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte41930</guid>
</item>
<item>
<title>ASA may reload with traceback in thread name CTM message handler , Terminated CSCtc32031</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc32031</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;

ASA may reload with traceback in thread name CTM Message Handler. 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

ASA running 8.x code.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc32031</guid>
</item>
<item>
<title>Unable to SSH over remote access VPN (telnet, asdm working) , Fixed CSCsy57872</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy57872</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;

Unable to SSH over a remote access vpn connection. Connection attempt fails immediately (no username or password). 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Problem found on 8.0.4(21). The interface is pingable. You can telnet and ASDM to the interface. You can also SSH through the ASA to other internal routers. You can also SSH to the ASA interface sitting internal to the network.  The only part that is not working is SSH to the interface on the ASA itself over the VPN. 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

unapply the SSH command and reapply:

no ssh &lt;ip&gt; &lt;mask&gt; &lt;interface name&gt;
ssh &lt;ip&gt; &lt;mask&gt; &lt;interface name&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy57872</guid>
</item>
<item>
<title>, Fixed CSCsx64741</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx64741</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

system crashed sometimes when rate limiter is configured and packets in the flow contains multiple different value of dscp.
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;

system crashed sometimes when rate limiter is configured and packets in the flow contains multiple different value of dscp.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

remove rate limiting (police) from configuration
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx64741</guid>
</item>
<item>
<title>watchdog failure in sqlnet inspection engine , Fixed CSCsr06900</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr06900</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
A PIX or ASA firewall running 8.0.x code may crash and reload citing the Dispatch Unit thread as the crashing thread.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This occurs on versions of ASA and PIX firewall code prior to 8.0.3.25.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None at this time.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr06900</guid>
</item>
<item>
<title>threat-detection not releasing cached memory after being disabled , Fixed CSCsm21719</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsm21719</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
After disabling Threat-detection, it is still caching a large amount of RAM
which is not freed back to the system.
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
Threat-detection needs to be enabled, and then disabled.
Typically, the default &#39;basic-threat&#39; and &#39;statistics access-list&#39; 
would not cause this condition.
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
Disable threat-detection, and then reboot the appliance to reclaim 
the memory.
&lt;br&gt;

&lt;B&gt;Further Problem Description:&lt;/B&gt;
The output of &quot;show memory detail&quot; will show most of the memory 
is consumed by the 698880 size fragment.  Investigating the consumer
of this fragment size will reveal chunk_create as the largest consumer.
Then the &#39;show chunkstat&#39; output will show that &quot;SNP Host statistics chunk&quot;
is consuming most of the memory.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsm21719</guid>
</item>
<item>
<title>Traceback on secondary with SIP connection replication , Fixed CSCtd43241</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd43241</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

ASA may reload with the traceback in the thread Dispatch Unit.






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

The traceback happens upon SIP connection replication in a rare corner case.




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

Issue is similar to CSCtc30413 in a sense that it has the same traceback, however the underlying logic is differen, as the root cause here is SIP connection replication.














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtd43241</guid>
</item>
<item>
<title>Traceback in ci/console after sh crypto ipsec sa , Fixed CSCsz01314</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz01314</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
ASA crashes in  ci/console  with a vector page fault
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Lots&#39;s of phase II are present and phase I and Phase II got rekeyed

&#39;show crypto ipsec sa&#39; has been issued
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none. Do not use that command
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz01314</guid>
</item>
<item>
<title>Traceback in Thread Name: Dispatch Unit with ESMTP Inspect enabled , Fixed CSCse47150</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCse47150</link>
<description>Symptom:
Traceback in PIX/ASA 7.2.1
&lt;br&gt;
Conditions:
When processing segmented SMTP/ESMTP packets.
&lt;br&gt;
Workaround:
Disable inspect ESMTP
upgrade past 7.2.1.17 




</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCse47150</guid>
</item>
<item>
<title>, Fixed CSCsu45313</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsu45313</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
- The ASA crashes after entering the command &quot;show capture&quot;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
- ASA 5580 running 8.1(1)5
- Capturing packets on a busy interface using circular buffer
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
- Avoid using the &quot;show capture&quot; command for packet capture with circular-buffer

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsu45313</guid>
</item>
   
</channel>
</rss>
