Solved

OWA on DMZ not redirecting to Exchange 2003 on local Network

Posted on 2010-08-13
11
951 Views
Last Modified: 2012-05-10
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.


0
Comment
Question by:handgunowner
  • 8
  • 3
11 Comments
 
LVL 3

Expert Comment

by:ssparks827
ID: 33434764
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
0
 

Author Comment

by:handgunowner
ID: 33434848
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.
0
 
LVL 3

Expert Comment

by:ssparks827
ID: 33434912
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.





Thanks
0
 

Author Comment

by:handgunowner
ID: 33435109
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.
0
 

Author Comment

by:handgunowner
ID: 33435439
Well I found another problem.

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

That doesn't help.
0
Are your AD admin tools letting you down?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

 

Author Comment

by:handgunowner
ID: 33435538
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.
0
 
LVL 3

Expert Comment

by:ssparks827
ID: 33436670
I'm going to lead you this recommendation:

http://blog.sembee.co.uk/post/Why-you-shouldnt-put-Exchange-2003-in-a-DMZ.aspx

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,

Scott
0
 

Author Comment

by:handgunowner
ID: 33438067
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
0
 

Author Comment

by:handgunowner
ID: 33441977
Ports Confirmed
0
 

Author Comment

by:handgunowner
ID: 33458589
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?
0
 

Accepted Solution

by:
handgunowner earned 0 total points
ID: 33468294
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.
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Utilizing an array to gracefully append to a list of EmailAddresses
Following basic email etiquette rules will help you write a professional email and achieve a good, lasting impression with your contacts.
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…

895 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now