Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1242
  • Last Modified:

Proxying OWA (Exchange 2000) with Apache 2.0

Hello Experts,

I really need your help here. This is the scenario:
I have a brand new exchange 2000 server with installed OWA behind a firewall in the trusted internal network.
In the DMZ I have linux Red Hat 7.2 + Apache 2.0.40 running as a web server and as proxy server.
To communicate with OWA on the other side of the FW, I use the port 8181 that is mapped to port 80 in the internal side.

I used to be able to proxy OWA 5.5 using just

ProxyPass /
ProxyPassReverse /

but now this seems not working with OWA 2000. When I use apache to access OWA after the successfull authenthication I receive a page with two frames, but the frames are empty. this is anyway part of the page I got back:

<!--Copyright (c) 2000-2001 Microsoft Corporation.  All rights reserved.-->
<!--CURRENT FILE== "IE5" "WIN32" frameset -->
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
     <TITLE>Microsoft Outlook Web Access</TITLE>
          <BASE href="">
... etc. So Why is the port missing?

I hope somebody can help me.
Thanks in Advance.
  • 5
  • 3
  • 2
  • +3
2 Solutions
Do you get the same result in both rich and reach mode? Hm, yes you do, don't you.

Not an answer, but perhaps a workaround: Don't use the 8181 PAT in the FW, but use static 192.168.0.[1,2,3,4]:80 <-> through the FW instead. That way the proxy (reverse) rules don't have to handle aught but the address.

-- Glenn
Correct me if I'm wrong, but shouldn't the
<BASE href=... contain either just "/exchange/User/" or "http://yourproxyipaddress/exchange/User/" for this to work?
Having it read href= wont fix things, right?

Maybe OWA think it lives at IP and this actually comes from the OWA configuration?
(I know that with other web applications it's sometimes possible to alter "base" url in the configuration, just for this purpose)
On the other hand I'd expect to see if that was the case!?

I've never dealt with OWA, though we have it where I work, and it allows to be proxied (I just tried it ;-)).. I think it's an older version though and there are no <base href in the returned html code as far as I've seen.


This might give you some insight:

As I understand it you cannot proxie the OWA by IP, you need to do it by FQDN (Fully Qualified Domain Name).

/Hans - Erik Skyttberg
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

fromano2802Author Commented:
Hi everyone,

thank you for your answers. Here are my comments to you guys.

To Gns:

I can't use port 80 on the firewall to map OWA because that port has already been used for other purposes.

To bummerlord:

In the <BASE href=... tag, I would expect to find "", but the port is missing.
Here another question,
Is it possible to make OWA listen to a port different than 80?

To heskyttberg:

I will give a try to the solution you propose, but I have the feeling that this is not a problem about IP or FQDN.

Thank you again for your help.
fromano2802, are the clients supposed to contact directly??
They will if href= points it out in the HTML code.
The reson for using FQND in the solution mentioned by Erik is that external clients will resolv FQDN to the reverse proxy IP address, and internal clients will resolv it to the Internal IP... thus to avoid having the proxy server query the internal DNS (and route the internal network from DMZ) the FQDN has to appear in the local hosts file as well.

So let say you have owa.yourdomain.net as in external DNS, you'd then "map" this IP to your proxy server (e.g.
In your proxy server you have owa.yourdomain.net as in the local hosts file.

It could also be that OWA assembles the <BASE href= from what ever Host: header the client, the proxy in this case) supplies, in the request (big qestion mark here)
Worth trying though..
At least try adding the OWA FQDN name to your hosts file and wrtie the ProxyPass, and ProxyPassReverse directives with FQDN.

fromano2802Author Commented:
Hi bummerlord,

The problem I see here is that the name of the server hosting OWA is not visible outside my FW, the only FQDNs visible are www.mydomain.com and webmail.mydomain.com.
So, even if I specify a name for my FW (I can't connect directly to my OWA server), this won't be resolved by an external DNS.

> I can't use port 80 on the firewall to map OWA because that port has already been used for other purposes.

And you cannot add a "virtual external interface" with a separate address? webmail and www both point to the same target address, don't they?
You should at least be able to set up and test it without changing the public webmail DNS reference.
Or perhaps you only have one public IP address? In that case ... bummer (:-).

Hans-Eriks suggestion looks really unpalatable (no reflection on him), but workable.
My employer drew approximately the same conclusion as David Marshall and his crew. Personally I detest OWA and would have prefered some simpler IMAP-based solution (especially after IIS lockdown "turned off" the ability to change password "remote"). If you go with a public OWA, use SSL and some SecurID like system (we chose RSA-ACE and SecurID).

I'll try to simulate this ... since we do have a M-Sexchange 2000, I should be able to verify its "workability".

-- glenn
fromano2802, If www.mydomain.com resolvs to the IP maped to the proxy server, then you will have problem knowing what site to proxy for. It's possible that you may have to add another A record to the external DNS (pointing out the same IP as www.mydomain.com, or you could use CNAME) and use that name in /etc/hosts and in your Proxy directives in httpd.conf. (you'll have to use a virtual host for this other name, put the proxypass directives for owa in there only)

As Gns suggests.. use SSL for this site at least.
If you can't, then .... damn! You should! ;-)

(Remember to compile openssl from source, disable SSLv2 etc etc)


IS that a double "/b" .. or am I drunk already?!;-)
fromano2802Author Commented:
Bummerlord, I have just one public IP address and www and webmail are pointing to it.
I didn't have any problem before (when I was using OWA 5.5) and I don't have any problem now to proxy the requests for www and for webmail. Infact I use 2 different Virtual Hosts in my httpd.conf for that.
As you suggest the proxypass directive for owa is only in the webmail VH.
Anyway, I managed to make OWA listening to another port adding a new Exchange HTTP Virual Host, now I have to solve the problem of the host name returned by owa.

SSL... well I am seriously thinking about it... but one step at the time, before I need to make owa running the way I want. :)
ok, webmail.yourdomain.com is for the OWA (or did I get this all wrong?)
If you add webmail.yourdomain.com to the hosts file in your proxy pointing to and use the FQDN in your proxypass directives... does that fix the returned hostname from OWA?
This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
Post your closing recommendations!  No comment means you don't care.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
Split points between Gns and bummerlord
Please leave any comments here within the next seven days.


EE Cleanup Volunteer

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 5
  • 3
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now