On 7/6/06, Henrik Nordstrom <henrik@xxxxxxxxxxxxxxxxxxx> 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!
