Link to home
Start Free TrialLog in
Avatar of Graham Hirst
Graham HirstFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Setting up a reverse proxy for Exchange

Hi Experts,

I have been trying to set up a reverse proxy in our DMZ for CAS as per this guide

http://microsoftguru.com.au/2010/08/08/how-to-configure-reverse-proxy-using-forefront-tmg-2010-step-by-step/

However i still cannot get it to work

The forefront server has one nic so i have configured it to listen on all ports. I can also run the test rule against the firewall policy and it passes correctly

Is there anything else that needs to be set up for this to work as this is a brand new server with pretty much nothing else configured
Avatar of Kash
Kash
Flag of United Kingdom of Great Britain and Northern Ireland image

Avatar of Graham Hirst

ASKER

Hi Innocentdevil,

That's the same link I posted?
is your DMZ a "leg" on a single firewall, or do you have "internal" and "external firewalls" ?

are you using public or private addresses in the DMZ ?

you need to ensure that the traffic path in both directions goes via the reverse proxy, otherwise your firewall might block a "reply" that it sees as a "new" connection. this can be "complex" in some scenarios...
Hi ArneLovius

We have two firewalls. One serving as the DMZ firewall, and another acting as an internal one.
The exchange box sits on the external network and the forefront server in the dmz

The DMZ has its own private IP range

What ports would need to be open between the servers? At the moment, since i believed it is only acting as a web portal of sorts, i have only allowed https?
if you are performing SSL offloading on the reverse proxy, you would need to allow inbound HTTP to the Exchange server.

are you able to browse to the Exchange server from the reverse proxy ?
Ok, so i've now opened up http and https both ways but its still not working :(

Nope the reserve proxy cant browse to it. Could it be that another setting in forefront is blocking it, since forefront acts as a firewall itself?
I would try putting a "clean" computer in the DMZ on the same IP address as the Forefront box and confirming that your "internal" and "external" firewall rules are working in the way that you expect, then when these are working, you will know that any other issues are just down to Forefront..
Hi Arne,

I've set up a new machine, which can confirm can access the cas server OWA over https
I'm now going to install Forefront and try and set it up as per the guide and see what happens
To further update, immediately after forefront is installed i can no longer access OWA
can you access "anything" ?
false alarm, one reboot later i can access owa. Just gonna get started with the setup now to confirm
ugh looks like i spoke too soon. it was applying an update. now its back up it wont allow me to access anything even remote onto it
have you added your internal address as internal addresses to forefront ?
I ve added the dmz range as an internal address to forefront, and the adaptor. But not the address range owa sits on?
Right, after opening forefront and going through its wizard, i can now remote on, and browse google.com. But it still will no longer allow access to OWA
Do you have NAT between the DMZ and the internal network ?
No there is no NAT between the DMZ and internal network
Are you able to trace to the exchange server ?

I'm wondering if routing has been affected.
Well, i ve noticed it doesnt seem to be tied to the owa server. i can reach google via http, but if i try the https version it fails. It does this for all other https sites too
Hi Arne,

Right, i ve gotten further. I changed the web access policy from internal network to all networks and this has resolved my https issue, so i can now reach owa

I have configured it as per the guide. However i have also added in against the web publishing rule, under the public name the TMG own ip address (in the hope that if i browse to it, it will push to towards the OWA, and i can test that stage before changing public DNS etc)

However i am greated with the TMG gateway login, which does not recognise my domain credentials

Have i done something wrong? Or is there a better way to test it will redirect before i move to the next step?
Any ideas regarding my last query?
have you added 127.0.0.1 ?
Yea, still no luck though.

It looks like the problem it has now it authentication with the server though as from the event log it looks like its trying to log onto itself rather than the mail server?

What authentication methods should the listener and publishing rule be set to?
ASKER CERTIFIED SOLUTION
Avatar of ArneLovius
ArneLovius
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Arne,

So far one to one, except for in that scenario the TMG server has a network connection to both the DMZ and Domain, hence it can use AD.

Im having to set it up with LDAP as a result. But it does confirm it should be set to basic at least

Im now getting

Error Code 10061: Connection refused
Background: When the gateway or proxy server contacted the upstream (Web) server, the connection was refused. This usually results from trying to connect to a service that is inactive on the upstream server.

When trying to log in
Ignore that last error code, i fixed that. It was from where i recreated the rule and had a type in the ip address.

Im back to the login screen and nothing happening when trying to log in
I'd try from a "client", but to begin with I'd put the "client" in the DMZ
Well at the moment it looks like an LDAP issue. Do you know what port TMG uses port wise? I ve set it to me use an unsecure connection so will it still use 389?
LDAP is port 389, if you enable LDAP over SSL and have a suitable cert, then it's 636.

You could try testing with Softerra LDAP Browser.
At the moment its not using a SSL, and using the ldp.exe tool i can connect via port 389, but still when you try to log in nothing happens

Im not seeing any events though now that tell me whats gone wrong
FINALLY got an error message

The Client Access server "https://SERVER/owa" attempted to proxy Outlook Web App traffic for mailbox "/O=O./OU=OU/cn=Recipients/cn=user". This failed because no Client Access server with an Outlook Web App virtual directory configured for Kerberos authentication could be found in the Active Directory site of the mailbox. The simplest way to configure an Outlook Web App virtual directory for Kerberos authentication is to set it to use Integrated Windows authentication by using the Set-OwaVirtualDirectory cmdlet in the Exchange Management Shell, or by using the Exchange Management Console. If you already have a Client Access server deployed in the target Active Directory site with an Outlook Web App virtual directory configured for Kerberos authentication, the proxying Client Access server may not be finding that target Client Access server because it does not have an internalUrl parameter configured. You can configure the internalUrl parameter for the Outlook Web App virtual directory on the Client Access server in the target Active Directory site by using the Set-OwaVirtualDirectory cmdlet.
The error message is a "valid" error message

http://technet.microsoft.com/en-us/library/ff360714(v=exchg.140).aspx

however I thought that your OWA was working, which makes me think that this is a artefact of Forefront...
Indeed it was/is

I don't understand it? It just seems to not be able to authenticate with the server?
Any ideas?
sorry, I'm out of ideas :-(
Well it looks like the OWA is down on the forefront server

im getting the following when trying to connect directly to it

Outlook Web App didn't initialize. If the problem continues, please contact your helpdesk.
Error message in the event log

The Client Access server "https://192.168.22.101/owa" attempted to proxy Outlook Web App traffic for mailbox "/O=*****./OU=***/cn=Recipients/cn=****". This failed because no Client Access server with an Outlook Web App virtual directory configured for Kerberos authentication could be found in the Active Directory site of the mailbox. The simplest way to configure an Outlook Web App virtual directory for Kerberos authentication is to set it to use Integrated Windows authentication by using the Set-OwaVirtualDirectory cmdlet in the Exchange Management Shell, or by using the Exchange Management Console. If you already have a Client Access server deployed in the target Active Directory site with an Outlook Web App virtual directory configured for Kerberos authentication, the proxying Client Access server may not be finding that target Client Access server because it does not have an internalUrl parameter configured. You can configure the internalUrl parameter for the Outlook Web App virtual directory on the Client Access server in the target Active Directory site by using the Set-OwaVirtualDirectory cmdlet
It's a one-nic TMG! (that makes it effectively nothing but a caching server).  Quit wasting your time with it.  Is it possible to Reverse Proxy with it?...Yes,...but is almost a total waste of time that gains nothing substantive but creating yet another failure point where something can go wrong.  Publish (Reverse-NAT,...instead of Reverse-Proxy) the Exchange using your existing Firewall and forget it.
[from the first post...]
The forefront server has one nic so i have configured it to listen on all ports.

That is impossible.  It cannot be done.  TMG will never "listen on all ports",...besides the fact that it is a One-Nic TMG and will only process HTTP, HTTPS and FTP-Over-HTTP.

Even a full multi-nic, full-function TMG will still never "listen on all ports" because it can never listen on ports that the underlying OS (or the TMG software itself) is already using for its own purposes.   Publishing Rules (any type) will only listen for specific protocols that are either predefined or User-created and those will be assigned to either a single inbound port or a sensible range of ports.
I ve read numerous guides that say it can be done in that manor where forefront exists in a dmz environment, between 2 firewalls, as a posed to a leg on a singular firewall?

A bit of background on why we're doing this.

We are trying to make exchange fully redundant. We have a DAG in place but unfortunately it is worthless without the ability to load balance CAS

We have load balancers that sit in the DMZ for our other web servers, but CAS cannot go into a DMZ, it is not supported by microsoft.

The only solution i could find was to load balance two FFP servers which in turn, published and load balanced the CAS servers, thus removing any single point of failure

If you know of a better way to achieve full exchange redundancy, i ll be happy to try that?
If you know of a better way to achieve full exchange redundancy, i ll be happy to try that?

Two FF-TMG2010 (Enterprise Edition only) operating as Edge Firewalls (no DMZ) configured as a full TMG/NLB array with NLB enabled on both the Internal side and the External side so that "both sides" run a Virtual IP#.

I have no specific guides/documents on doing that,...but it is the direction I think you should go, and I get the impression that you know enough to figure out the details if you have a direction you know to go in.

Also,...full redundancy is a total fantasy,...there is no such thing,...there will always be a vulnerable failure point somewhere,...all you ever really do is shift around where that might be located.
"Two FF-TMG2010 (Enterprise Edition only) operating as Edge Firewalls (no DMZ) configured as a full TMG/NLB array with NLB enabled on both the Internal side and the External side so that "both sides" run a Virtual IP#."

Unfortunately we have to work within the structure of our existing network. As such whatever solution we have has to be in the DMZ between 2 firewalls

As said, i ve seen diagrams of it done, and i ve gotten close. It redirects. But it just seems to have a problem with the authentication side of things
The TMGs should be Domain Members and that can be a hassle if they are in a DMZ.  You may just have to run it without authentication.  It is debatable how much benefit the Auth via the TMG really provides.
You can still authenticate,..I'm just saying the TMGs don't have to be involved with the Auth.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
In the end i resolved the final part of the issue myself