On 5/01/2013 3:01 a.m., Roman Gelfand wrote:
So, the fortigate was configured based on the whitepaper you pointed me to. The unencrypted http traffic works, but what I find is that even though a request from the client arrives on squid via wccp, going back it is routed via standard tcp/ip path. Is that how wccp communication supposed to work with squid or should it come back to the client via wccp?
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).
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.
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.
Also, https traffic is not working. I am not sure if it is ssl bump that is causing it. Can you see why it wouldn't work? Please, note the same squid configuration works for for both http and https proxy is explicitly specified in the browser.
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.
Amos
