Please, see below...
> Some bit of clarification here. "WCCP" is a protocol consisting of two
> packets HERE_I_AM and I_SEE_YOU. The HTTP traffic always goes via GRE
> protocol interface or layer-2 packet routing via Ethernet interface. The
> WCCP protocol configuratino in Squid and Cisco determins whether the layer-1
> or GRE are used as return method.
> I think from your earlier posts you are confusing "WCCP" protocol with the
> name of the interface your config uses (wccp0).
Correct me if I am wrong. I understood that I configured "virtual"
interface called wccp0 through which wccp/gre communication of
http/https protocol is to take place.
The thing to keep in mind is that
1. from squid server to firewall, there is SNAT relationship that
translates .252 WAN ip address. However, http traffic from client to
firewall translates to .254 WAN IP address. It appears the http/https
requests from client are routed by firewall through wccp/gre to and
from squid server. After it goes out via .254 wan ip address. Is
this correct behavior?
If all of this makes sense, how can I troubleshoot this?.
>
> Also, NAT is only ever performed on the first packet of any connnection,
> which will always be an incoming packet arriving from your wccp0 interface
> in PREROUTING. You did not mention a MASQUERADE rule in the POSTROUTING
> chain which is the part handling the return packets to the client.
could you give an example.
>
> Other TCP data packets than that first one seen by NAT table are ESTABLISHED
> or RELATED state and will go out whatever interface your routing setup is
> configured to send them out.
>
> The thing to remember the Squid box is acting as a router for these packets.
>
>
> This means only that Squid acting as forward-proxy works, none of the WCCP
> protocol and interfaces, NAT or HTTP re-interpretation happens. Squid acting
> as interception proxy is a VERY different beast from regular forward proxy.
>
I hit the same problem even with transparent keyword as opposed to intercept.
Received on Tue Jan 15 2013 - 22:51:59 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 16 2013 - 12:00:03 MST