Feature: WCCPv2 router interception for Squid
Goal: Making Squid communicate with Cisco routers and accept WCCP intercepted HTTP traffic from them.
Status: Completed.
Version: 2.6 and later
Developer: AdrianChadd
Contents
Overview Details
Cisco routers and switches provide a traffic interception method called WCCPv2 which captures HTTP traffic and can redirect it through a properly configured Proxy box.
WCCPv2 implementations by Cisco vary between releases and whether a router or switch is used.
Also WCCPv2 is merely a way of getting packets to a proxy box, receiving the packets into the proxy requires separate configuration which is dependent on the operating system and proxy receiving it.
This means no one config tutorial can be used for a generic config. Instead we are forced to provide snippets of config and stitch them together as appropriate for every network combination.
Cisco box WCCP version 2 configuration for ...
Cisco 3640 router
! ip wccp web-cache ! interface Ethernet1/0 description Public interface ip address X.X.X.X 255.255.255.248 no ip redirects no ip unreachables ip nat outside full-duplex ! interface FastEthernet2/0 no ip address duplex auto speed auto ! interface FastEthernet2/0.1 encapsulation dot1Q 1 native ip address 192.168.1.1 255.255.255.0 no ip redirects no ip unreachables ip wccp web-cache redirect in ip nat inside
Cisco ASA
Bypass the Squid box from re-capture
access-list wccp_redirect extended deny ip host $SQUID-IP any
Note: This shouldn't be required, because the asa would build this rule itself, when adding the squid box.
... while capturing the local /24 network defined by "workstations".
access-list wccp_redirect extended permit tcp workstations 255.255.255.0 any eq www
Intercept everything not prevented by the bypass list:
wccp web-cache redirect-list wccp_redirect password foo wccp interface internal web-cache redirect in
Cisco IOS 12.4(6) T2 router
! ip wccp web-cache ip cef ! interface FastEthernet0/0.2 description Link to internal LAN encapsulation dot1Q 2 ip address 192.168.0.1 255.255.255.0 ip access-group outboundfilters in no ip proxy-arp ip wccp web-cache redirect in ip inspect fw-rules in ip nat inside ip virtual-reassembly no snmp trap link-status !
Cisco PIX
Cisco PIX is very easy to configure. The configuration format is almost identical to a cisco router, which is hardly surprising given many of the features are common to both. Like cisco router's, PIX supports the GRE encapsulation method of traffic redirection.
Merely put this in your global config:
wccp web-cache wccp interface inside web-cache redirect in
There is no interface specific configuration required.
Squid configuration for WCCP version 2
All the squid.conf options beginning with wccp2_* apply to WCCPv2 only
Squid configuration
$IP-OF-ROUTER is used below to represent the IP address of the router sending the WCCP traffic to Squid.
Squid-2.6 to Squid-3.0 require magic numbers...
http_port 3129 transparent wccp2_router $IP-OF-ROUTER wccp2_forwarding_method 1 wccp2_return_method 1 wccp2_service standard 0 password=foo
Squid-3.1 and later accept text names for the tunneling methods
http_port 3129 intercept wccp2_router $IP-OF-ROUTER wccp2_forwarding_method gre wccp2_return_method gre wccp2_service standard 0 password=foo
Squid box OS configuration
modprobe ip_gre ip tunnel add wccp0 mode gre remote $ASA-EXT-IP local $SQUID-IP dev eth0 ifconfig wccp0 $SQUID-IP netmask 255.255.255.255 up
- disable rp_filter, or the packets will be silently discarded
echo 0 >/proc/sys/net/ipv4/conf/wccp0/rp_filter echo 0 >/proc/sys/net/ipv4/conf/eth0/rp_filter
- enable ip-forwarding and redirect packets to squid
echo 1 >/proc/sys/net/ipv4/ip_forward iptables -t nat -A PREROUTING -i wccp0 -p tcp --dport 80 -j REDIRECT --to-port 3129 iptables -t nat -A POSTROUTING -j MASQUERADE
TroubleShooting WCCPv2
IOS 12.4 (6)-(9) T dropping packets
In this release of IOS software that I am running (12.4(6)T2 and 12.4(9)T) you MUST NOT have ip inspect fw-rules in on the same interface as your ip wccp web-cache redirect statement.
I opened a TAC case on this as it is clearly a bug and regression from past behaviour where WCCP did work fine with IP inspection configured on the same interface. This turned out to be confirmed as a bug in IOS, which is documented as CSCse55959.
The cause of this is TCP fragments of traffic being dropped by the ip inspection process - fragments which should not even be inspected in the first place. This bug does not occur on the PIX which works fine with the same network design and configuration. If you would like this bug fixed, please open a cisco TAC case referencing this bug report and encourage cisco to fix it.