OWA on DMZ not redirecting to Exchange 2003 on local Network

I have created an OWA exchange 2003 on a STD SP1 2003 server.

Initially I created it on the inside network and tested connections.  It was redirecting as it should to the internal exchange server.  I would hit the https:// DMZBOXFQDN/exchange on the new server and get redirected to OWA on the main exchange box.

I created a DMZ on their Firebox and moved the OWA machine to the DMZ network adjusting the IPs at need.

I created the holes I needed on the Firebox.

I can ping and RDP to the OWA box on the DMZ by IP and by FDQN.
From the physical OWA box on the DMZ I can hit the outside world and internal resources on the internal network.

They have not purchased an SSL cert yet, but I can hit the OWA box (from the outside) on the DMZ by IP for a 'under construction' message.   My outside to DMZ IP redirect is working.

I can also hit the OWA box (from the outside)  with an http:/DMZBOX_IP /oma tag to get the standard OMA errror message.  So I am hitting the DMZ from the outside.  Ports look good.

I can RDP to the new OWA box on the DMZ (thru citrix to the inside network), open a browser on DMZOWA, and get to OWA on the inside Exchange box by using the inside exchange's https:/MXBOXFQDN/exchange.  Ports look good.

I can hit the http://DMZBOXFQDN/oma tag on the DMZ box from the inside network for testing.  I get the standard OMA error message.

I can telnet (to inside ip) 25 and 80 to the DMZBOX from the inside and get the proper response. 443 fails.
I can telnet (to outside IP) to 25 and 80 from the outside and get the proper response (443 is not live yet)

All of that seems to tell me ports and connections are shiny.

What I can't do is now get redirection back to the inside Exchange box when I hit the https://DMZBOXFQDN/exchange from anywhere.

Not even on the physical box itself.

This company is using a new WatchGuard Firebox.  I'm a Cisco guy, but the ports seem right because I can hit the DMZ from the outside (for testing, even without an SSL) and I can get to the inside Exchange Server OWA directly from the DMZ OWA box itself.  That would tell me the ports from outside to DMZ and from DMZ to inside are correct.

To sum up:

From Outside
To http://DMZ_IP/exchange :500 error
To https://DMZ_IP/exchange :  Cannot Display Web Page
To http://DMZ_IP/oma : Get OMA default error page off of server

From Inside
To http://DMZ_URL/exchange :Cannot Display Web Page
To https://DMZ_URL/exchange : Cannot Display Web Page
to https://MX_URL/exchange (inside MX server):  Connect

From Physical DMZ OWA box
To http://itself/exchange :Cannot Display
To https://itself/exchange : Cannot Display
To https://MX_URL/exchange (inside MX Server) :  Connect

This was all working fine when I built the box.  I was just hoping the last part was just to wait for them to buy an SSL cert.  I'm not concerned about outside errors until the cert gets installed.  I need to know internal redirection works.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

So there are two exchange servers then?

One is backend server and the other is frontend server?

the frontend server doesnt' need to be in a dmz....put both server behind the firewall and just open up port 80 , 443 and 25 on the frontend server.

Let me know
handgunownerAuthor Commented:
Yes. A backend and a frontend.  OWA Needs to be on the DMZ per customer requirement.  Access via SSL when they buy a cert.  IP on external port of Firewall mapping to OWA IP on DMZ.  Pretty standard stuff except I cant get the OWA to redirect.

I built and OWA on a DMZ in Exchange 2007 for someone else on Wed and it worked instantly.
You are going to need some other ports opened.
I would open your logs and check to see what other ports owa is trying to communicate back to the exchange backend server.  135 comes to mind 139 and a few others.  Of course if you are going to use rpc over https you will need the three 600x ports opened as well.

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

handgunownerAuthor Commented:
135, 137, 138, and 139 are open.

I am accessing the backend properly from the OWA server on the DMZ.

That is, I can open a browser on the DMZ, type in the internal URL/exchange of the MX box, and get attached (including login) to OWA.  That would suggest to me that all the proper ports are open from the DMZ to the internal network.

If, from the DMZ again, I type in the DMZ URL/exchange do not redirect to the URL of the internal MX box like I did during testing of both on the inside network.
handgunownerAuthor Commented:
Well I found another problem.

Exchange System Attendant service is failing with a 0x8007077f error - cannot find topology.

That doesn't help.
handgunownerAuthor Commented:
OK.  Fixed that error by adding the IP range of the DMZ to AD Sites, and added the Domain Controllers manually in the Exchange System Manager.  No change to redirection.
I'm going to lead you this recommendation:


I agree with this guy fully and don't really support the idea if putting a domain member into a DMZ.

Sorry I wasn't able to help fix your issue.  This has got my mind working backwards from what I normally do.  I've literally have setup thousands of frontend servers behind the firewall and not once have I had a security breach.  I've rescued several servers that were in the DMZ from hackers though.

To give my last bit of help - I thiink you are having some sort of port problems because this server can't communicate to the domain correctly.  There are possilbe DNS, AD ports that might be necassary for it to communicate right.

Last thoughts - I would strongly recommend putting that server behind the firewall and set some policies up that would protect it and letting the customer know that a DMZ for domain member is not the place for their server.

If you need some troubleshooting help I can still help I just wanted to let you know - I'm getting stumped due to this isn't my normal practice.

Let me know,

handgunownerAuthor Commented:
I have a long list of ports that need to be opened depending on your config...
DMZ to Internal
•      80 for HTTP
•      143 for IMAP
•      110 for POP
•      25 for SMTP
•      691 for Link State Algorithm routing protocol
Open ports for Active Directory Communication:
•      TCP port 389 for LDAP to Directory Service
•      UDP port 389 for LDAP to Directory Service
•      TCP port 3268 for LDAP to Global Catalog Server
•      TCP port 88 for Kerberos authentication
•      UDP port 88 for Kerberos authentication
Open the ports required for access to the DNS server:
•      TCP port 53
•      UDP port 53
Open the appropriate ports for RPC communication:
•      TCP port 135 - RPC endpoint mapper
•      TCP ports 1024+ - random RPC service ports
(Optional) To limit RPCs across the intranet firewall, edit the registry on servers in the intranet to specify RPC traffic to a specific non random port. Then, open the appropriate ports on the internal firewall:
•      TCP port 135 – RPC endpoint mapper
•      TCP port 1600 (example) – RPC service port
If you use IPSec between the front-end and back-end, open the appropriate ports. If the policy you configure only uses AH, you do not need to allow ESP, and vice versa.
•      UDP port 500 – IKE
•      IP protocol 51 – AH
•      IP protocol 50 – ESP
•      UDP port 88 and TCP port 88 – Kerberos
DMZ to External
443 for HTTPS
993 for SSL-enabled IMAP
995 for SSL-enabled POP
25 for SMTP (including TLS)

This evening I will go over the firewall with a fine tooth'd comb and confirm each port
handgunownerAuthor Commented:
Ports Confirmed
handgunownerAuthor Commented:
I think I'm hosed on this one.

I went into the customer and found his BackEnd Exchange server is also running citrix with a cert on the BackEnd server for Citrix.

When I put a cert on the OWA server, it tries to redirect and then tells my I need to run https://  even tho that is what I have in the URL.

Any work-around?
handgunownerAuthor Commented:
I got it working by disabling the cert on the Default Site and Exchange Virtual Directories, and leaving the cert enabled on the Citrix Virtual Directories.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.