WCCP Configuration: Redirect Web Traffic to a Cache Engine - 夜莺博客

WCCP Configuration: Redirect Web Traffic to a Cache Engine

WCCP is how you transparently insert a caching or filtering appliance into a traffic path without re-addressing clients or touching their configuration. The router or firewall intercepts selected traffic and redirects it to a cache engine; the engine either serves the request from cache or fetches it and returns it, optionally spoofing the original source so the client never knows anything happened. It is still the standard mechanism behind transparent proxies, and it is either trivially easy or maddening to configure depending on whether the service group, the redirect list and the return path line up.

The Pieces

  • Service group — the standard web-cache service (TCP port 80) or a numbered dynamic service (0–254), for example service 60 for FTP.
  • Redirect list — the ACL controlling which traffic gets redirected.
  • Group list — the ACL determining which cache engine IPs may join the group.
  • Password — MD5 authentication of messages from the group; messages failing authentication are discarded.
  • Forwarding method — GRE encapsulation (the common default) or Layer 2 rewrite on platforms that support it.

Configure the Service Group (Cisco CLI)

ip wccp web-cache redirect-list 120 group-list 10 password S3cret
!
ip access-list standard 10
 permit 10.80.2.187
!
ip access-list extended 120
 permit tcp 10.10.0.0 0.0.255.255 any eq 80
 permit tcp 10.10.0.0 0.0.255.255 any eq 443
!
interface GigabitEthernet0/0
 description LAN
 ip wccp web-cache redirect in

Two details decide whether this works. First, redirection is applied on the ingress interface facing the clients — the interfaces where traffic enters. Second, the router selects its highest interface IP as the WCCP router ID and uses it as the GRE tunnel source, so that address must be reachable from the cache engine.

On an ASA

wccp web-cache redirect-list 120 group-list 10 password S3cret
wccp interface inside web-cache redirect in

The ASA supports WCCPv2 only. It does redirect multiple TCP and UDP ports, authenticate cache engines, and support multiple engines in one group with GRE encapsulation. It does not support multiple routers in a service group, multicast WCCP, Layer 2 redirect, source-address spoofing or WAAS devices. If your design depends on any of those, terminate on a router instead.

Numbers Worth Knowing

  • Maximum services, including dynamic identifiers, is 256.
  • Dynamic service numbers are 0–254 and are used as the group name.
  • The password is short — up to seven characters on some platforms. Do not treat it as a strong secret; treat it as a protocol guard.
  • On ASA, when the device decides a packet needs redirecting it skips TCP state tracking, sequence number randomisation and NAT for those flows.

Verify

show ip wccp
show ip wccp web-cache detail
show ip wccp web-cache service
show ip wccp web-cache view
show ip interface GigabitEthernet0/0 | include WCCP

Read the output in this order: does the router see the cache engine (show ip wccp lists cache engine IPs), does the service show up as Enabled, and do the redirect counters increment while clients browse. A service that is registered but has zero redirected packets means the redirect list is not matching, not that WCCP is broken.

The Return Path Is Half the Battle

In the classic topology the cache engine sits behind the same interface as the clients and can send the response directly to the client, bypassing the router. That is efficient and easy to get wrong: if the engine's default gateway points somewhere that routes back through the redirecting device, you build a loop where the response is redirected again. Confirm the engine's routing before blaming the router.

Common Failure Modes

Symptom Likely cause
Service registered, no redirection Redirect list is an ACL that does not match, or redirection was applied on the wrong interface or direction
Clients lose connectivity entirely Cache engine down while redirection stays enabled — plan a fail-open strategy and monitor engine health
Engine never joins the group Given group-list does not include its IP, or MD5 password mismatch
Redirect works for HTTP but not HTTPS Port 443 was added to the redirect list without the engine being able to transparently handle CONNECT — caching HTTPS is a different conversation
Asymmetric path breaks reply Engine routes responses back through the redirecting device

Do You Still Need It?

WCCP's original motivation — saving WAN bandwidth by caching web objects — has been largely replaced by CDNs and by explicit forward proxies. Where it remains genuinely useful is transparent redirection to security appliances: web filtering, DLP and TLS-inspecting proxies, where you want the appliance inline in the path without changing client settings or routing. If that is your use case, WCCP still does the job it was designed for — and a fail-open policy plus engine health monitoring is non-negotiable.

Related Reading

Deeper dives on the same topics from our archive:

原文链接:https://cisco.com/c/en/us/td/docs/security/asa/asa92/asdm72/general/asa-general-asdm/basic-wccp.html