Solved

OWA on DMZ not redirecting to Exchange 2003 on local Network

Posted on 2010-08-13
11
950 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
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

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

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

"Migrate" an SMTP relay receive connector to a new server using info from an old server.
Following basic email etiquette rules will help you write a professional email and achieve a good, lasting impression with your contacts.
To show how to generate a certificate request in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Servers >> Certificates…
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…

747 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