Patrick Tschackert wrote:
> Amos Jeffries wrote:
>
>> I have a feeling we say you a while earlier. yes?
>
> Yup.
>
>> Does the OWA server really respond to "office-pc39:11994/exchange" normally?
>
> No, the office-pc39 is supposed to listen on port 11994 and redirect everything to the owa server (internal IP: 300.200.80.254) as a transparent reverse proxy.
>
> Henrik Nordstrom wrote:
>
>> Why transparent? I would recomment you to configure the reverse proxy as
>> a reverse proxy... a lot of sanity preserved that way..
>
> I'm using the proxy as a transparent one because otherwise it keeps redirecting the client's requests instead of redirecting all of the data.
> This fails because the outside client isn't allowed to make connections to the owa server (it isn't even supposed to know it's using a proxy for that matter).
>
> Here's a visual:
>
> INTERNET ||| Internal company network
> Browser <------> Squid <---------------------------> OWA server
> (mycompany.dyndns.org) (internal ip: 300.200.80.254)
>
> (Info: when anyone tries to access mycompany.dyndns.org on port 11994, they reach office-pc39 via port forwarding. This is how the it is intended to work when I finally set it up permanently. They are then supposed to reach the owa server through squid without knowing they're being proxied!).
>
> When squid wasn't configured as a transparent proxy, the browser kept trying to bypass the squid proxy.
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.
> After I tried the "transparent" setting, the whole thing worked with a simple html test website (without http auth).
> I managed to narrow the problem down a bit: everything which needs basic HTTP authentication fails with the squid error page I sent in my previous email.
>
> A peek into the squid cache log revealed this:
>
>> WARNING: Forwarding loop detected for: Client: 127.0.0.1 http_port: >127.0.0.1:11994
>> GET http://localhost:11994/authsite HTTP/1.0 Accept: image/gif, >image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, >application/vnd.ms-excel, application/vnd.ms-powerpoint, >application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, >application/x-ms-xbap, application/x-ms-application, */* Accept-Language: >de-ch UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 >(compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR >2.0.50727; .NET CLR 3.0.04506.30) Host: localhost:11994 Authorization: >Basic kzherfbIKKKghdiuegeeE= Via: 1.1 >office-pc39.local.mycompany.com:11994 (squid/2.6.STABLE16), 1.0 >office-pc39.local.mycompany.com:11994 (squid/2.6.STABLE16) >X-Forwarded-For: 127.0.0.1, 127.0.0.1 Cache-Control: max-age=259200 >Connection: keep-alive 2007/11/14 14:29:37| temporary disabling >(Unauthorized) digest from 300.200.80.254
>
> This occurs when trying to access anything which needs authentication.
Strange that it only dies on auth stuff. I usually see this due to a
transparent or DNS miss-configure that catches localhost traffic
outbound from squid and pushes it back in again.
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
and make sure traffic from office-pc39 to 300.200.80.254 is always
accepted out past the FW or whatever is doing the redirect.
>
> Amos Jeffries wrote:
>
>> You have an open proxy. Yaya! free internet for the world.
>
> I was planning to configure security issues once the thing works as it should, don't worry. At the moment it's only running about 5 mins at a time when I am testing it. But thanks for your concern! ;-)
>
>> M$ don't like the color black?
> I'm afraid I don't get it...
Sorry, bad joke.
"strange Microsoft design decision for reasons we outsiders don't
understand." "God only knows at this point" etc.
>
> I'm sorry if I appear a bit stupid with resolving this issue, it's really giving me a hard time as I haven't worked a lot with proxies before...
>
> Regards (and thx for trying to help),
> -Patrick
Amos
Received on Thu Nov 15 2007 - 02:53:02 MST
This archive was generated by hypermail pre-2.1.9 : Sat Dec 01 2007 - 12:00:02 MST