On 7/6/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:

>> For proper transparent operation you need one of these configure
>> options..

>
> Sorry?
>
> he said
>> I only use ipfw ...
>
> are you sure?


To clarify my answer:

For proper opertation of transparent interception proxying your method of
interception needs to be supported by Squid and enabled with the proper
configure argument.

If your method of interception is not supported by Squid then support must
first be added before it can work proper.

However, in real life transparent interception does not need full support
very often as most clients do send Host headers which Squid can use.
However, a Squid configured for transparent interception will be somewhat
upset if support is not available as Squid knows it won't always work. If
a client sends a request without a Host header Squid won't be able to know
what to do with the request without proper support enabled as the
information about the intended destination is then lost.

FWIW, I was able to get the subj going by applying the
following patch:

http://people.freebsd.org/~sat/diffs/patch-src-client_side.c

I'm sure there might be a better way, but the thing is ipfw
doesn't change packet headers when forwarding packets.
So we just need a placeholder clientNatLookup function that
returns a success. I tested it with simple 'GET /' requests
and it works.

We've had squid 2.6STABLE1 working in production with
minimum functionality for a few hours on end. Apart from
three fatal errors, it's okay, and we're glad to have NTLM
auth working on remote webservers.

Thanks!

Reply via email to