RE: [squid-users] Issues with Debian, Squid and WCCP

Andrew,

        This sounds very much like the problem I struggled with for several
weeks. Ha! It's good to be able to contribute positively to this mailing
list for a change!

        Basically - the WCCP modules and GRE modules just don't work with
Cisco / WCCP / Debian. I have no idea why. There is a work around however :
Use a much higher version of Debian (one that has a GRE module built in that
can handle these weird WCCP packets properly) and no extra WCCP modules.
Then use a different kind of IPTables redirection method (DNAT). This DOES
work. Again - I have no idea why. I just kept messing with the different
options until something worked. Brute force - the worst kind of debugging!

Let me point you towards my previous post on the subject:-

        http://www.webservertalk.com/archive254-2006-1-1360989.html

I hope this helps. If someone can explain this phenomenon I'd be most
appreciative!

Regards,

Ben Hathaway
Software Developer
http://www.spidersat.net
<Spidersat Logo>

-----Original Message-----
From: Andrew Yoward [mailto:andrew.yoward@yhgfl.net]
Sent: 13 July 2006 19:17
To: squid-users@squid-cache.org
Subject: [squid-users] Issues with Debian, Squid and WCCP

Greetings,

I am wondering if you could shed some light on a rather tricky issue
that I am having. I have a local education authority who are
experiencing a lot of traffic on their internet pipe and often find that
it is used to the max. We are wanting to introduce a transparent cache
for http and so we thought that Squid and WCCP would be the answer to
our prayers, but I am having great difficulty in getting any traffic to
go through the Squid. Here is what I am trying to do in the lab.
My client has no setting in Firefox for a proxy and is on
192.168.250.1/24 and gw is 192.168.250.254. I have a Cisco 2600 router
with two FE ports. One is configured with 192.168.250.254/24, the other
is configured as 10.3.65.4/24. It is running IOS 12.3(6c). My proxy is
built on Debian Sarge and a 2.6.8 kernel. Squid is version
2.5.9-10sarge2. The proxy has 10.3.65.3/24 and gw is 10.3.65.254. I
have gone through all the FAQs and other literature I can find regarding
what I'm trying to do. I have enabled WCCP version 1 on the 2600. I
have done ip wccp web-cache redirect in on the 192 side and I have
swapped it round to redirect out on the 10 side, during my
troubleshooting. I know that the Squid and the router are communicating
as I get the packet exchange on port 2048 with no trouble. I have
configured the squid.conf as shown in the FAQs, I have also added the
needed prerouting line in firewall.up for IPTables to redirect port 80
traffic to 3128. I have compiled the WCCP module, modprobed it and it
is listed in lsmod. I also did all the GRE tunnelling stuff. When I
try from my client to reach a web page, if I watch the nat on IPTables,
I can see the packets hitting the rule to forward to 3128, but nothing
happens at the client. If I use lynx on the squid, and set it's proxy
to localhost, I can get web pages fine, so I know squid is working
correctly. Having run tcpdump, I can see WCCP packets coming across
from the router, but it seems that either the encapsulation is not being
stripped off when the packet hits, or squid doesn't know what to do with
it when it is passed. There is no entry in the squid access.log to tell
me anything. The syslog is spurious. At first, it identified the
source as 10.3.65.4 and destination of .3 but also complained about
protocol 47. After I enabled protocol 47 and port 1723 in iptables, it
then identified the source as 192.168.250.1 but still I got no joy with
http content being passed back. I am at a loss now as to what I may be
doing wrong. Whether the GRE tunnel isn't right, whether IPtables is
the issue, or the WCCP module. I am hoping that someone may be able to
shed some light.

I would of course be very grateful for any help that you could offer and
if I can answer any questions, or if I have not given enough
information, please let me know.

Best regards,

Andrew Yoward
YHGfL Foundation
www.yhgfl.net
Received on Fri Jul 14 2006 - 00:25:13 MDT