[squid-users] wccp transparent proxy; returned spoofed packets are dropped!

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