Here is a quick update on the entry I had on a bug identified on the ASA when using WCCP. I have listed the fixed versions below; however I was disappointed by the bug fix limitations. Instead of providing a solution to the problem Cisco basically removed a feature.  Through this bugfix Cisco now only allows an ACL asscoiated linked to WCCP to use source or destination addresses.  You can no longer use an ACL based on protocol.  

Example:

I want to send all http and https traffic to my Web Cache server (proxy) via WCCP for the 10.0.0.0/8 network. However I want the host 10.1.1.10 to send https directly out the firewall but still have WCCP send http to the Web Cache server.  There is no way to accomplish this using ACL's and WCCP now.

This bug was fixed in:
8.2(1.10)
8.2(1.10)
7.2(4.32)
8.0(4.30)
8.1(2.21)
7.2(4.36)
8.0(4.35)
8.1(2.26)

BUG WHEN CONFIGURING WCCP - CISCO ASA

I just completed an upgrade of my ASA from 8.0.4 to 8.2.1. It took me a week to realize logging was broken. My ASA was configured to send any notification events and lower to my syslog server.  I also set notification logging on all ACL's. After the upgrade no ACL hits were being sent to the syslog server.

After opening a ticket with TAC they pointed me to this work around:

logging list mylist level notifications

logging list mylist message 106100

logging trap mylist

Message 106100 are messages from ACL hits. This work around is pretty good because I can add additional informational messages individually.  There are a lot of SSL-VPN informational messages that I like to capture for reporting purposes.

Bug Toolkit info:

access-list logging prints 106100 syslog always at informational level

Symptom:

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 

This is the bug that was driving me crazy during my configuration of WCCP on my ASA. I worked with TAC for weeks on this trying to prove WCCP was broken. TAC helped me for a few weeks trying to identify the problem. After multiple packet captures proving the ASA was sending all traffic to the cache-engine and not just the ports associated with the service-ID a Bug was reported:

Click to read more ...