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
