Re: [squid-users] TCP_MISS/503 with Squid-3 in transparent mode

On Tue, 28 Sep 2004, Andreas Pettersson wrote:

>> Is there anything at all in cache.log which may be relevant?
>
> Earlier the following occured, but I'm not sure exactly what configuration I was running at the time (I have tested a LOT of different configurations.. I might have run some stupid conf..)
>
> 2004/09/28 11:36:37| Failed to select source for 'http://www.domain.se/'
> 2004/09/28 11:36:37| always_direct = 0
> 2004/09/28 11:36:37| never_direct = 0
> 2004/09/28 11:36:37| timedout = 0

This is a new one... never seen that before.

> Another thing I have noticed in cache.log was before I recompiled my
> kernel with IPFIREWALL and IPFIREWALL_FORWARD. I loaded ipfw manually
> after boot instead (kldload ipfw) but that wouldn't do it for squid,
> which complained with this:
>
> parseHttpRequest: NAT open failed: (2) No such file or directory

If you see this then transparent interception won't work as Squid won't
have a clue on how to resolve the intercepted connections correctly.

You can still configure Squid-3 as an accelerator for all domains of the
whole Internet using the vhost directive, much like Squid-2 worked. The
main difference is that Squid-3 automatically enables never_direct on
accelerated requests (but not on transparently intercepted requests) and
you would need to counter this by using the always_direct directive.

> All google hits stated that /dev/nat was missing on my system. But after
> kernel recompilation /dev/nat is still missing. The nat device is called
> /dev/ipnat.

Squid knows both.

> However the error message does no longer appear in cache.log. I don't
> know if it has anything to do with my problem, but I think it's worth
> mentioning.

It is probably a good time to run a "squid -k debug" dump to verify that
your Squid is properly identifying the connection as intercepted and
resolving the original destination IP.

Regards
Henrik
Received on Tue Sep 28 2004 - 10:27:22 MDT