“A reverse proxy is not wanted…” This is due to the supposed complexity. I know 2012 R2 has WAP included, and I have suggested that. I don't think it would be complex to setup at all. On a side note, can a reverse proxy handle ActiveSync traffic?
“….and NAT through the firewall to the CAS array is deemed too dangerous. “ I agree - this is the easiest solution, and reasonably secure. Sure they were issues in the past, but things have come a long way. This was the initial idea, until a consultant balked at it. “…for the single CAS in the DMZ.” I should have clarified a bit on this, it would be firewalled off from the world, not a true DMZ Only 443 would be accessible. This is really no differnet from the NAT solution, except there is a firewall between it and AD/the rest of Exchange. I think this gives a feeling of security. Secondary to this, they do not view mobile devices as critical and only a handful of users would use it and OWA remotely - so if the single server dies we will deal with the downtime. On Fri, May 9, 2014 at 10:17 AM, Kennedy, Jim <[email protected]>wrote: > “A reverse proxy is not wanted…” > > > > I have to ask why because in my mind that is the best thing to do in this > situation. If they won’t allow access to 443 from the outside to a specific > location why have an internet connection? > > > > “….and NAT through the firewall to the CAS array is deemed too dangerous. “ > > > > And again why, because that would be the second best solution imho. This > sounds like predisposed beliefs that exposing Exchange OWA to the world is > dangerous. Back in 5.5 days I would have been on that page but I don’t > think that is the case now. > > > > “…for the single CAS in the DMZ.” > > > > And this sounds like the worst idea of them all. You will have lots of > ports open from the CAS to the internal to make that CAS work. So now that > box gets popped out there and the bad guy now has the whole world of all > the AD ports at their disposal to your internal network. > > > > Be interesting to see what my learned colleges here on the list think. But > the above is what I am going with. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Tommy Fudge > *Sent:* Friday, May 9, 2014 11:08 AM > *To:* [email protected] > *Subject:* [Exchange] CAS exposure - Exchange 2013 SP1 > > > > Morning, > > > > My work is concerned about exposing our CAS array to the public internet. > Initial thoughts are to place a single CAS in the DMZ with ports open to > our internal network. I have obvious concerns with this approach, but it > is gaining traction, so I need to know if this will even work. On our > internal network are two AD sites, each site contains 2 CAS and 2 MBX > (single DAG) and each has independent internet connectivity. Varying > thoughts are floating around such as using mail.domain.com for the > internal CAS array, and mobile.domain.com for the single CAS in the DMZ. > Autodiscover will point to "mail" which should allow internal clients to > auto configure. There is no desire for external clients to auto configure > (or even laptops to function out of the office using Outlook Anywhere). > Mobile devices would be statically configured to use the "mobile" namespace > by IT, and external clients would connect to OWA via "mobile" as well. > > > > A reverse proxy is not wanted, and NAT through the firewall to the CAS > array is deemed too dangerous. I know the single CAS is a hole in the > firewall anyway and also unsupported by MS, but would this scenario even > work? Is there any impact to Outlook clients on the internal network > seeing the CAS in the DMZ? Would I need to make the internal CAS array non > internet-facing and the single DMZ based CAS internet-facing? Can a single > AD site support both internet-facing and non facing CAS? > > > > Definitely open to suggestions here. This is not production yet - no > coexistence as we use an old Linux mail server right now. > > > Thanks, > > > Tommy >
