So one of the major reasons why organizations choose to use a hardware load balancer to distribute client traffic across the client access servers in an Exchange 2010 Client Access Server (CAS) array is in order to take advantage of the more advanced persistence methods available when using layer 7.
In order to use layer 7 based persistence (such as cookie), the load balancer must inspect the client sessions. When dealing with Exchange 2010 clients connecting to the CAS array from the Internet (or internally for that matter) encrypted HTTP (SSL) is used to connect to the CAS array. Now in order for the load balancer to inspect encrypted HTTP (SSL) client sessions, the sessions must be unencrypted by the load balancer. When the load balancer has inspected the session, they are directed to a CAS server in the CAS array in an encrypted (reverse SSL) or unencrypted (SSL offloading) fashion based on the persistence algorithm in use. To accomplish this, the SSL certificate (that is in use on the CAS servers) must be imported on the load balancer and reverse SSL (aka SSL bridging) or SSL acceleration (aka SSL offloading) must be enabled for the HTTPS virtual service on the load balancer.
SSL acceleration and reverse SSL is illustrated in the following conceptual diagrams (taken from the SSL offloading TechNet wiki article I wrote in the past).
The steps necessary in order to enable reverse SSL (SSL bridging) on a load balancer differs from load balancer to load balancer. It’s no secret, I’ve worked a lot with (and recommended) the LoadMaster devices from KEMP Technologies, but one thing I found a bit clumsy to configure on a LoadMaster was – yes you guessed it right – reverse SSL (SSL bridging). Prior to firmware build 5.1-46 (at the time of this writing 5.1-62 is the latest), you had to first create an HTTPS front-end virtual service listened on port 443. Then you had to create a back-end virtual service for each CAS server in the respective Exchange 2010 site listened on port 80. On the front-end virtual service, you had to point to the back-end services as target servers. Then you had to point each back-end virtual service to a CAS server.
On the front-end HTTPS virtual service, we had to enable SSL acceleration:
And on each back-end HTTPS virtual service, we needed to enabled reverse SSL by ticking “reverse SSL” so that the sessions was re-encrypted:
Well the good news is that with firmware build 5.1-62 this has all changed. No more front-end and back-end virtual services. You simple create an HTTPS virtual service and enable re-encrypt directly on this virtual service:
And voila, you have configured reverse SSL (SSL bridging).
Until later,
Henrik Walther
Technology Architect/Writer/MS Vendor
MCM: Exchange 2007 | MVP: Exchange Architecture
