- How It Works
- Common Misconceptions
Web Cache Communication Protocol (WCCP) is a technology developed by Cisco that allows transparent re-direction of network traffic in real-time. This re-direction can be to a cache engine or to a proxy, such as the Web Gateway.
How It Works
WCCP works by placing a WCCP capable router/switch in between users and the internet, either in the path or as the default gateway. The WCCP device will then transparently redirect traffic on the ports that are configured over to the Web Gateway for filtering and proxying. The user has no idea that the Web Gateway is in place as all traffic is sent from the Web Gateway directly back to the user while spoofing the server's IP address. WCCP v1 only supports redirection of port 80 while WCCP v2 supports redirection of multiples ports.
Load Balancing / High Availability
WCCP has built in capabilities that greatly enhance your redundancy and fault tolerance.
Multiple McAfee Web Gateways can connect to the same router to support load balancing and failover. Configure the Gateways with Central Management and make sure that all McAfee Web Gateways have the same value in the “WCCP Router Definition” field. The first McAfee Web Gateway to come up and establish contact with the router will “assign buckets". Buckets control how load is distributed when using more than one Web Gateway. When a McAfee Web Gateway comes on or off line, buckets will be automatically reassigned. If the “bucket assigner” goes off line another McAfee Web Gateway will take over bucket assignment.
If WCCP is configured on the router and no peer (McAfee Web Gateway) is active in the service group, the router will just let the requests through, without redirection. This behavior is called fail open.
If fail open is desired in a McAfee Web Gateway deployment, you have to configure your firewall to allow web traffic from any IP so clients can go out directly in case the web gateways are not reachable.
If fail close is desired in a McAfee Web Gateway deployment, configure the firewall to only allow web traffic from McAfee Web Gateway IPs. This way, clients will get blocked if they do not go through Web Gateway.
Some Cisco IOS versions also allow “fail-open” or “fail closed” to be configured on the router or switch.
We do not recommend using WCCP when the router, clients, and/or McAfee Web Gateway are separated by anything that will do source NATing of client traffic as this will limit your ability to perform load balancing and will restrict you from using Time/IP based authentication sessions.
WCCP works by having the Web Gateway subscribe to the router. The router is not aware of the proxy until it subscribes. There are no settings that need to be configured on the router to tell it about the proxy. It is also possible to have the Web Gateway subscribed to many routers in the same configuration using the same service ID or to many routers with different service IDs.
Here I Am & I See You (with Example)
WCCP uses 'Here I Am' and 'I See You' packets to subscribe and negotiate settings and also as a health check every 10 seconds. The 'Here I Am' is sent from the Web Gateway to the WCCP device to subscribe to the router and tell it the settings that it is configured for. This includes the ports that can be redirected, the assignment weight, service ID, assignment method, redirect method, and the IP that traffic should be redirected to. The 'I See You' is the acknowledgement from the router to the Web Gateway to inform it that the subscription is successful and includes the Router ID which is highest interface IP on the router. If a router does not receive a HereIAm packet for 25 seconds, it will unicast a Removal Query message to the proxy to request that it respond immediately. If no response is received within 5 seconds (30 seconds total), the the proxy is considered offline and removed from the WCCP pool. You may configure your network to fail open or closed depending on your policies.
Here I Am:
I See You:
After setting up your Router for WCCP, you need to configure your Web Gateways and enable WCCP so they can subscribe to the router.
There are a few things to consider when configuring WCCP
WCCP is a Transparent Setup!
There are some considerations that need to be made in regards to authentication due to WCCP being a transparent deployment method. Please see Support Doc: Authentication Examples by Deployment Method. You may also reference Transparent vs. Direct Proxy for additional considerations and recommendations..
Fallback / Mixed Mode
WCCP can be your sole deployment method where you rely on it to handler all of your traffic or it can be useful in a few other situations. Some common uses include using it as a fallback in a direct proxy environment to catch applications that don't honor proxy settings or in a WiFi network segment where users can bring their own devices. As a best practice, we recommend configuring two proxy ports for mixed environments - one for Direct Proxy and one for WCCP. This allows you to easily use 'Proxy.Port' as criteria for distinguishing rules, such as authentication methods.
Proxy Listener Port
For WCCP redirection to work correctly, it is required that you bind your proxy listener port to 0.0.0.0 (For example the default 0.0.0.0:9090). You must not bind your port to any specific interface IP or localhost as otherwise the redirection will not work and traffic will not be answered. You can find the proxy listener port config under Configuration > [[ Appliance Name ]] > Proxies > HTTP Proxy
Switching from Proxy HA, Transparent Router or Transparent Bridge to WCCP
It is important to reboot your appliance once when switching from Proxy HA, Transparent Bridge or Transparent Router mode in order to unload the network driver that handles the transparent interception and redirection of the traffic. This is only required once. Later on you can enable and disable WCCP without any reboots.
All Settings are entered on one screen under Configuration > [[ Appliance Name ]] >> Proxies >> Transparent Proxy >> WCCP
Add or modify a WCCP service definition:
Service ID: The service ID must match the router config and it is highly recommended to only use a value from 51-98. Service IDs 0-50 are static and reserved for “well known services” with predefined configurations. Service IDs 51-255 are dynamic and involve negotiation between the WCCP peers. This configuration shows 51 for the service ID. “Web-cache” is a Cisco reserved keyword that refers to well-known Service ID 0 and will only redirect port 80 regardless of port settings in the MWG GUI. See also: http://www.ciscopress.com/articles/article.asp?p=1192686&seqNum=2 this article focuses on WAAS but includes useful information about WCCP.
WCCP Router Definition: Multiple routers can be listed in the Router field or a multicast address can be used. Note that if a multicast address is used, “group-address” and “group-listen” must be used in the router or switch configuration
Ports to be redirected: Keep in mind that the Web Gateway is primarily an HTTP proxy so any ports redirected to the HTTP proxy port must be used for valid HTTP traffic or tunneled SSL traffic. Redirection of FTP traffic or other protocols is not supported. Any ports that need to be filtered and treated as SSL, other than 443, must also be added under Configuration > Proxies > HTTP Proxy > Edit Proxy Listener > Ports treated as SSL. If WCCP v1, is used, there are no configuration options available on McAfee Web Gateway and only port 80 traffic will be filtered.
Proxy Listener Address: This the physical IP address for the local NIC that you wish to have traffic redirected to.
Assignment Method: The bucket assignment method is the method used by WCCP to determine which McAfee Web Gateway to use for the redirection. Certain Cisco switches and routers will only support MASK assignment. See the documentation for the software revision and hardware model of the switch or router. ASA and PIX firewalls currently support only HASH assignment.
Assignment Weight: Controls how much of the total load can be re-directed to the proxy. This only needs to be adjusted if you have different types of Web Gateway appliances participating in the same WCCP pool and you need to divert more traffic to a stronger appliance. Otherwise, it is recommended to leave it at the default value of 1000.
Input for load distribution: When running multiple appliances, load distribution can be configured for the proxies on them. Data packets can be distributed to these proxies based on the masking of source or destination IP addresses and port numbers or on a hash algorithm. We recommend, as a best practice, to select Source IP as the Input for load distribution. This ensures that a user always hits the same proxy to avoid breaking sessions.
GRE - encapsulation: Generic Routing Encapsulation (GRE) works by encapsulating the original packet inside a new packet with additional headers and sending it over the GRE tunnel from the router to the proxy. This method has more overhead, but has the benefit of being able to work across subnets.
L2-rewrite: L2-rewrite means Layer 2 rewrite. This method works by re-writing the packet's target MAC address to the MAC address of the proxy. This method works only if the router and the proxy are on the same subnet.
L2 Redirect Target: The local NIC that you wish to handle the redirected traffic.
WCCP is used to send Traffic back to the clients / WCCP Return Method
WCCP is only used when traffic is intercepted and redirected to(!) the web gateway. All traffic from the Web Gateway to the client will be sent directly to the client which requires proper routing and firewall rules.
The WCCP return method is part of the WCCP spec and is designed to be used in error conditions so that caches or proxies can reject traffic and send it back to the router. The return method is not used for "returning" traffic back to clients!
The Web Gateway does not use the return method and the Web Gateway will never send any traffic back to the router. That is why there is no configuration option for it.
The WCCP router needs to be configured with the Web Gateway IPs
WCCP is a subscription protocol. The Web gateways need to subscribe to the router and that is how the router "learns" the Web Gateway IPs.
All you need on the router side is the configuration for the WCCP service ID and the correct interface to apply it to. After that you can have as many Web Gateways subscribe to that router as you want.
The dashboard, found under Dashboard > Charts and Tables > System Summary, is useful to verify the subscription status and statistics at a glance. It will show you the current subscribed Service ID, router IP, forwarding & return methods and assigned buckets. More importantly, it shows the last HereIAm and ISeeYou times so that you can verify that the health check is working as long as these values are current.
- You can verify that the redirect on the proxy (from 80,443 to the proxy port) is configured correctly from the command line by entering: iptables -t mangle -L
- Check that appliance sends “Here-I-Am” and receives "I-See-You"-Packets (UDP 2048). You can use the following tcpdump string: tcpdump –npi eth0 port 2048
- Make sure that the Web Cache ID is the same as the IP of configured McAfee Web Gateway(s)
- Make sure that the bucket assignment method matches what is configured on McAfee Web Gateway
- Make sure the redirect method is the same as what is configured on McAfee Web Gateway
- Check that the encapsulated or L2 rewritten packets are reaching the McAfee Web Gateway
- For GRE: tcpdump –npi eth0 ip proto 47
- For L2: tcpdump –npi eth0 not host <McAfee Web Gateway IP>
- Verify that GRE packets are sourced from the IP configured for the router in McAfee Web Gateway
- Verify that L2 packets are source from the client IP
- Check that redirected packets are received by McAfee Web Gateway (#ifconfig and watch packets/bytes received by gre0 device)
- Note that filtered content is returned directly from McAfee Web Gateway to the client, it is not encapsulated.
- The following commands are useful for troubleshooting from the router side:
- show ip wccp detail
- show ip wccp 51 detail
- show sdm prefer (3750 and some other low end switches)
- debug ip wccp packets
- debug ip wccp events
- Things you might find when running a network capture on the Web Gateway
- SYN + No SYN/ACK
- Check that the proxy listener is not bound to a specific IP address
- If you switched from any network drive mode, make sure you rebooted
- SYN + SYN/ACK + nothing after (or repeated SYN)
- The Web Gateway is likely not able to contact the clients directly. Need to determine what is in the path between client & MWG.
- Packets getting lost due to size when using GRE
- We've seen a few instances where GRE encapsulation can cause packets to become to large to be forwarded on and are subsequently dropped by the router. Lowering the MSS (ex: 1432) on the Proxy Listener defintion on the Web Gateway may solve this. This link may also help if there is a fragmentation problem on the router side and adjusting the Web Gateway MSS does not help: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d 6979.shtml#t5
- SYN + No SYN/ACK