Didn't someone point out a few weeks ago that Cisco only support wccp redirection on the same interface as clients?
the ASA is probably (quite rightly, its a firewall!) dropping the packets coming in from the DMZ as they're spoofed from another interface it knows about. You may be short of luck; you may have to put the proxy on INSIDE. See if that works. I'd offer better advice but I don't have an ASA to actually do testing on.. Adrian On Fri, Dec 21, 2007, Daniel Rose wrote: > Hi everyone, > > I'm trying to get wccp working and I'm nearly there, but I'm missing some > deeper understanding that I need to fix the current problem. > > I have found a strangeness in the following setup: > > CLIENT ---INSIDE--+---------+ > | | > SQUID -----DMZ----+ ASA5520 | > | | > WWWHOST --OUTSIDE-+---------+ > > The ASA has permit ip any any any (or similar) applied to every interface. > > wccp is configured on INSIDE and seems to be working well. ASA's wccp debug > and squid's debug both show Here_I_Am and I_See_You packets. > > When the client connects to WWWHOST with no proxy set, SQUID(the host, not > the cache) sees the GRE tunnel packets arrive, and can open them up ok. I see > the SYN requests from CLIENT to WWWHOST arrive. > > iptables has a redirect to port 3128, and this rule shows hits. > > SQUID (linux kernel 2.6.18.xxx) Sends a spoofed ACK 'from' WWWHOST to CLIENT. > > The spoofed ACK never arrives at the CLIENT. CLIENT just sends 3 SYNs and > times out. I assume it's dropped by the firewall, but I can't get 'debug ip > packet' or similar commands to work on the ASA 5520 to verify this, but it's > pretty clear since it never arrives on the client (I used wireshark). > > The WWWHOST is oblivious to the whole thing; no traffic is present. > > So SQUID never gets a complete TCP handshake, so the squid (2.6 STABLE.xxx) > service logs nothing, as the TCP stuff is all happening in the kernel. > > SQUID is properly configured for this, because the whole thing works if SQUID > is on INSIDE and is set as the routing gateway for CLIENT. > > I have two theories about the best way to fix this, and I would really > appreciate some advice from someone with more understanding than I: > > 1) The firewall needs some sort of configuration change to allow the ACK > back through. > > 2) The Linux squid is sending the reply "in the wrong way". > > For the first instance, I have not got the faintest idea where to start; > since the ASA is stateful and knows it sent the packets down the tunnel, it > should therefore be expecting the response and relay it, but it doesn't. I'm > therefore inclined towards 2. > > To this end I have tried configuring the GRE tunnel with a local loopback as > some documentation suggests (ifconfig wccp0 127.0.0.3 up), but that didn't > work. I even set squid's TCP_outgoing_address to 127.0.0.3 as well but it > didn't help. I see best results with the tunnel set to the IP address of the > host. > > tcpdump on the GRE tunnel shows the packets arriving, but no response > packets, so they are going out on the wire, not through the tunnel. If it is > vital to get the packets down the tunnel then clearly this is the problem, > but I'm at a loss to know how to fix it. wccp2_return and _forwarding > _methods are both unset, defaulting to 1. > > By preference I'd like the ASA not to use GRE for this at all and just use a > layer 2 redirect, but according to Cisco, "the Layer 2 redirect method is not > supported; only GRE encapsulation is supported." It also seems to support > only wccp2, not version 1. > > I can put the proxy on the inside network, but I would prefer it on the DMZ > if at all possible. > > Thanks for any advice! > > > -- > Daniel Rose > National Library of Australia -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
