Patrick Tschackert wrote:
Amos Jeffries wrote:
Did you then have 'accel' on the port where you now have transparent.
And 'originserver' on the cache_peer? That should have prevented clients
going around the proxy as it make squid appear to be the legit data source.
Perhapse this will help somewhat
# force all traffic via OWA source peer
never_direct deny all
cache_peer_access 300.200.80.254 allow all
Hey, thanks a lot for your advice!
It all worked without a hitch and solved a few other problems I was having
besides the http auth situation.
Great!
Sorry, bad joke.
"strange Microsoft design decision for reasons we outsiders don't
understand." "God only knows at this point" etc.
Oh, tell me about it. This is a reason for many frustrations I've had (not just
in this project). Unfortunately the server on which I'm supposed to install the
Proxy runs Windows, company policy :(
Well, I'm very thankful for your advice anyway!
There's another thing I'd like to do with the same squid proxy, maybe you can
also help on this issue (if I haven't tested your patience enough already):
Is there a way to listen on multiple ports and forward the traffic to various
ports on the same originserver?
Here's another stunning example of an ASCII schematic :)
Client request (Port 80) <--> Squidserver:80 <--> 300.200.80.254:80
Client request (Port 11994) <--> Squidserver:11994 <--> 300.200.80.254:11994
Sure, easy enough with squid 2.6 or later.
Just configure multiple http_port lines for the listening side.
Multiple cache_peers on the source side, each with a unique name= option
to tell them apart.
The cache_peer_access will need a little tweaking to use the peer names
and add an ACL of type 'myport' or 'port' to do the port-wise routing as
you want it.
something like this for each peer:
cache_peer 300.200.80.254 parent 80 0 ... name=peer80
acl port80 myport 80
cache_peer_access peer80 allow port80
Amos
