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
