Apples to Apples - Comparing an APM Deployment to TMG

Okay, okay, I drank the Kool-aid. I’m a big fan of Access Policy Manager, (APM) and, full disclosure, an F5 employee. With that said, being a “Windows guy” and coming from a background of working with Threat Management Gateway, (TMG) I have historically been skeptical with regards to the ease at which one can deploy an application, (MS Exchange for example) behind the F5 Big-IP as opposed to TMG. After all, the Big-IP is a “network device” and can be complex with many knobs to turn and levers to pull. Counter that with TMG; a windows-based product that comes with deployment wizards for two of Microsoft’s most popular applications, Exchange and SharePoint. Of course, TMG is easier to configure! Right?….Well, that was before iApps.

With the advent of iApps, the process of deploying applications behind the Big-IP has gone from hours to minutes. As organizations start looking for suitable replacements for TMG, F5’s Access Policy Manager is an excellent choice. Aside from providing more advanced features, (hardware-based SSL offloading, layer-7 health monitoring utilizing synthetic transactions, multi-factor authentication, endpoint inspection, etc.), publishing and securing applications, (like MS Exchange) are comparatively easy.

So there you have it. Right? No? Okay, so maybe a little convincing is in order. To illustrate my point, let’s take a look at a typical Exchange 2010 deployment process behind TMG as well as the Big-IP with APM. Just a little sip of Kool-Aid, (grape’s my favorite), and away we go.

The Playing Field

For this side-by-side comparison, I’ve deployed a simple Exchange 2010 environment with a single mailbox server and two Client Access Servers, (CAS). We’ll be providing external access to Outlook Web Access, ActiveSync, and Outlook Anywhere, (RPC over HTTP). To keep it simple and allow TMG to use a single listener and external URL, (APM can handle multiple authentication methods on the same VIP), all three of the services have been configured in Exchange for Basic authentication and the public SSL certificate has been imported into both systems. In addition, both the TMG as well as the Big-IP reside in the perimeter and are not domain-joined.

Exchange 2010 Publishing with TMG

The following process utilizes TMG’s Exchange Web Client Access publishing wizard.

Steps 1 through 6 - Select which client access service to publish, (only one service can be published at a time) and configure connectivity, (load balancing, SSL offload, health monitoring, etc.). With regards to health monitoring, you are limited to one of three options, (HTTP GET, PING request, or a TCP connection).

Steps 7 through 12 - Configure the public side of the deployment. This includes the public FQDN, associated IP address(es), and the listener. Since TMG is in the perimeter and not joined to the domain, “LDAP, (Active Directory)” authentication is used.

Steps 13 through 15 – Finish up by configuring SSO and authentication delegation.

The previous steps are followed to publish Outlook Web Access. You’ll notice on the first step, (see above), each service, (OWA, OA, ActiveSync) must be published separately. In our side-by-side comparison the above wizard was ran three times, (once for each of the three web-based client access methods). The three, (3) completed publishing rules are shown below.

Exchange 2010 Publishing with the Big-IP iApp

Rather than presenting a series of configuration screens, the Big-IP iApp, (web-based GUI) presents a list of questions. Where appropriate, instructions and commentary are included. All services, (MAPI, OWA, Outlook Anywhere, ActiveSync, Autodiscover, POP3, and IMAP4) can be deployed quickly and simultaneously from one single form.

Sections 1 through 3 - Select the Big-IP’s role in the deployment, APM pre-authentication settings, SSL offloading, and routing information. In addition, you may select whether to publish all services on one or multiple virtual servers.

Note: The Big-IP VIP, (virtual IPs) and associated virtual servers are equivalent to TMG’s web listener and access rule.

Sections 4 and 5 - Select the published IP address, services to be published, identify the CAS servers, and configure health monitoring. As previously mentioned, the Big-IP has the ability to perform synthetic L7 transactions as a part of it’s health monitoring. This ensures that not only is the service reachable but is functioning as well.

Sections 6 – Finish by selecting the public FQDN for the deployment after which the completed virtual server and all related elements are created, (including an HTTP redirect virtual server).

Final Thoughts

While I am biased, (c’mon I work for F5) it’s not my intent to persuade you the reader to select the Big-IP with APM over TMG. Rather, the goal has been to illustrate the ease at which you can publish applications with the Big-IP. With the recent announcement of TMG’s imminent demise administrators are going to need to identify alternatives; coupled with the fact that the Big-IP is already in many environments, Access Policy Manager, (APM) is an excellent choice. Dare I say it? Yes, I dare; APM is the best choice.