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
Received on Sat Jan 05 2013 - 06:56:00 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 16 2013 - 12:00:03 MST