So - would Windows NLB also be a reasonable alternative to a hardware load balancer to isolate the CAS from direct access? It may make the decision makers feel a little better. Or am I thinking about that wrong since the VIP is on the actual CAS boxes and not a separate device?
I'm of the same sentiment as everyone here, I'm just trying to convince some folks. On Fri, May 9, 2014 at 2:00 PM, Senter, John <[email protected]> wrote: > So we sort of have the same requirements, OWA internally only and > ActiveSync external only. The way we were able to do this is with our load > balancers. We have content management set to only pass through the URL’s > for ActiveSync; any other URL is rejected. The LB’s also protect the CAS > servers from direct access form the internet. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ccollins9 > *Sent:* Friday, May 9, 2014 11:48 AM > *To:* exchange > *Subject:* Re: [Exchange] CAS exposure - Exchange 2013 SP1 > > > > We allow OWA from internally controlled clients only, no external OWA > allowed. It's a long story that goes back in my org longer than I've been > there. So the two internal CAS servers allow all standard connectivity and > the one external CAS only can do ActiveSync. I was going to do two > externally accessible CAS, but our external user footprint is small and we > have fast VM recovery if that server ever tanks. I wanted to just do a > reverse proxy only to the ActiveSync virtual directory on the internal CAS > servers, but we require client certificates on our devices/ActiveSync and > the load balancers aren't able to support decrypting with client certs. It > can do normal SSL decryption/acceleration for or internal clients, but not > for ActiveSync. If anyone has a better solution---im all ears. We are > still in testing with EX2013 and won't be going live for a few more weeks. > > > > On Fri, May 9, 2014 at 11:41 AM, Michael B. Smith <[email protected]> > wrote: > > Yes, that changed in 2013. It is actually one of the recommended > scenarios now, for datacenter DR. > > > > Why do you send all EAS traffic through a single CAS? (You can do what > you’ve done, it’s fine, but I’m just interested in knowing the “why”?) J > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ccollins9 > *Sent:* Friday, May 9, 2014 11:36 AM > *To:* exchange > *Subject:* Re: [Exchange] CAS exposure - Exchange 2013 SP1 > > > > Another thought, I know EX2010 had issues when the CAS server was in one > AD site and the mailbox was in another AD site. It would try to proxy you > to a CAS in the site where the mailbox resided. I think they may have > changed that in EX2013, not sure. > > > > On Fri, May 9, 2014 at 11:33 AM, ccollins9 <[email protected]> wrote: > > With EX2013 CAS, all client connectivity is over port 443, so that's nice > because there is no need to open RPC, etc., all which I'm sure you know. I > would leave the CAS in the internal network and just open port 443 to it. > There is no real security threat unless MS has unpatched vulnerabilities > in IIS/Exchange. The second best option is to use either NAT or a reverse > proxy in front, or in our case, load balancers that can do reverse proxy. > I agree with Jim, it sounds like you have some old school thinking running > around there that any and all internet accessible servers must be in DMZ no > exceptions. Where I am, we have three CAS servers in the same internal AD > site. Two service the internal and one services external connections. In > the load balancer we have mail.domain.com that points to the two internal > CAS and mobile.domain.com that points to the one CAS for external. Our > external CAS does ActiveSync only, so we removed all OWA/ECP/EWS virtual > directories from that one externally accessible CAS server. Maybe someone > can weigh in why this is a bad idea, but we were able to get the security > team to sign off on it. > > > > On Fri, May 9, 2014 at 11: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 > > > > > > >
