Thanks for your help. It got me closer. My current config looks like this:
http_port 8080 transparent
cache_peer localhost parent 80 0 no-query originserver name=pac
acl pac dstdomain proxy.company.com 192.168.0.10
cache_peer_access pac allow pac
never_direct allow pac
192.168.0.10 is the ip of proxy.company.com. It still does not work.
The webserver hosting the pac file works fine. I checked that by
browsing the pac file.
Am I to stupid?
Thanks,
On Tue, Dec 9, 2008 at 10:53 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> Jan Welker wrote:
>>
>> Here's a situation we're facing and I'm curious if anyone has some
>> insight into how we might approach this problem.
>>
>> We currently have approximately pcs, a very large portion of which
>> are configured in one of two ways.
>>
>> A. Netscape browsers with manual proxy servers set up for http and
>> https as proxy.host.net:8080
>> B. Netscape browsers with automatic proxy configuration with URL setup
>> as proxy.host.net:8080 (note they're the same).
>>
>> This setup runs fine when pointing to the netscape admin-server/proxy
>> server configuration.
>>
>> The problem I'm having is when I point one of the "automatic"
>> configured pcs to one of the boxes running SQUID. At startup, the user
>> receives a message saying the automatic configuration has failed and
>> on the squid server I see the following access.log entry.
>>
>> 10.49.0.145 - - [30/Apr/2001:16:28:40 -0400] "GET / HTTP/0.0" 400 1094
>> NONE:NONE
>
> That is a transparently intercepted request. But your squid.conf does not
> appear to include any "http_port ... transparent".
>
> If you are going the PAC route you will need to remove the NAT capture of
> these requests.
>
>>
>> From the docs, it's clear that I need to provide a proxy.pac file
>> telling the users what their automatic configuration should be. The
>> problem I'm having is how to provide this info and provide
>> filtering/caching all from the same port?
>>
>> Having all the users change their configuration to point to another
>> port or host isn't an attractive option (120+ sites, 6000 pcs likely
>> to be touched). If I must do that, I'd much prefer to cut over to
>> transparent proxying so we don't face this problem again in the future
>> and it's trivial for the end users to reconfigure.
>
> If you take the NAT transparent interception route you WILL face this again
> when migrating away from IPv4. DNS based WPAD/PAC is expected to keep going.
>
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10
> Current Beta Squid 3.1.0.3 or 3.0.STABLE11-RC1
>
Received on Wed Dec 10 2008 - 09:29:28 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 10 2008 - 12:00:02 MST