Microsoft Lync Server 2010 : Planning for Deploying External Services - Reverse Proxy

A critical piece in planning for Edge services is the reverse proxy. Unfortunately, this tends to be overlooked or considered a secondary task, even though it provides some important functionality to a deployment. Without a reverse proxy, the following features will not work:

• Address book download

• Distribution group expansion

• Web conferencing content such as whiteboards, uploaded presentations, and document sharing.

• Device updates

• Dial-in conferencing page

• Simple meet conferencing pages

As you can see, almost every deployment with Edge services has some feature in the previous list. If a reverse proxy does not exist today in the organization, one should be deployed with Lync Server if external access is provisioned.

The concept of a reverse proxy is simple to understand when considering it as an extra hop or barrier between external clients and an internal resource. What a reverse proxy offers is the capability to inspect the traffic a client sends for any malicious requests, or possibly even pre-authenticates the user before being allowed to reach an internal client. In the overall scheme of external services, the reverse proxy fits in as depicted in Figure 1.

Figure 1. Reverse Proxy for Web Services

SSL Pass Through, Offloading, Termination, and Bridging

After understanding the functionality of a reverse proxy, it’s important to comprehend the different methods a reverse proxy can use to publish internal services. Three main methods are used and not all of them are available depending on the reverse proxy used. Starting with Microsoft Internet Security and Acceleration Server (ISA) 2006 or higher, which includes the Microsoft Forefront Threat Management Gateway and Microsoft Forefront Unified Access Gateway, any of the methodologies can be used. The preferred method for publishing Lync Server is to use SSL Bridging, which encrypts the traffic from end to end.

The easiest way to understand the differences is through diagrams. The most basic method is SSL pass through. This means that the traffic from Internet clients runs through the reverse proxy and can be inspected, but the SSL connection exists from the client all the way to the internal resource like shown in Figure 2.

Figure 2. SSL Pass Through

SSL Offloading

The next most common methodology in reverse proxy scenarios is to use SSL offloading. In this scenario, the client’s SSL tunnel terminates at the reverse proxy, which then initiates a clear-text, HTTP request to the internal resource. Many hardware load balancers offer this functionality and advertise it can improve performance of servers by “offloading” the SSL encryption and decryption duties from the internal server.

This is a valuable feature when a server is CPU-constrained, but with modern hardware, this is rarely necessary. Any hardware used for Lync Server probably far exceeds the CPU capabilities of most load-balancing devices. Furthermore, Lync Server is designed to operate in a secure manner end-to-end and does not actually support SSL offloading. Figure 3 shows how the SSL tunnel is terminated at the reverse proxy which then communicates over port 80 to the Front-End pool.

SSL Bridging

The final methodology, which is the preferred scenario, is to use SSL Bridging. In this case, the client’s SSL tunnels at the reverse proxy like in an offloading scenario, but the reverse proxy then opens a second HTTPS connection back to the internal resource. This ensures the entire transmission is encrypted from end to end.

There is also some added flexibility in this case where a reverse proxy can redirect that second connection to a port other than 443 back on the internal resource without the client knowing. As far as the client knows, it still has a connection on port 443 to the internal resource, even though the reverse proxy might bridge this connection to port 4443 on the internal Front-End pool. Figure 4 shows where the reverse proxy bridges a port 443 connection from the client to port 4443 on the Front-End pool, but still secures the traffic.

So, to summarize the options, the preferred method for Lync Server is SSL Bridging to ensure an end-to-end encryption of the traffic with the most flexibility. SSL offloading is not supported, so if bridging is not an option, the reverse proxy deployment should use SSL pass through.

Placement and Configuration

Where to place the reverse proxy server follows a similar idea as the Edge Server. It usually makes sense to place one close to any Front-End pools that have external access allowed. This becomes especially important when users leverage web conferencing because the display of content comes through the reverse proxy. So, like the Edge Server, optimizing that traffic path results in a better user experience.

Setting up the reverse proxy is similar to an Edge Server. Generally the reverse proxy is placed in a perimeter network and has two network adapters: one internal facing and one external facing. To reach internal server subnets, route statements must also be configured.

The reverse proxy server does not have to be a part of the domain, but can be joined for the same reasons as an Edge Server. Additionally, if a reverse proxy such as Microsoft Forefront Threat Management Gateway is domain-joined, it can easily pre-authenticate user requests.

Another valid configuration for reverse proxy scenarios with Forefront Threat Management Gateway is to use a single network adapter. Most modern hardware has plenty of adapters by default, but using only a single network adapter can simplify the deployment.

Reverse Proxy Load Balancing

As far as load balancing the reverse proxy goes, there are a few options, which might vary depending on which reverse product is used. With Microsoft Forefront Threat Management Gateway or Microsoft Forefront Unified Access Gateway, a hardware load balancer or Windows Network Load Balancing (NLB) can be used. Windows Network Load Balancing comes at no additional cost, so it might be more attractive for organizations without a hardware load balancer and those that want to leverage DNS load balancing.

The only port required for load balancing the reverse proxy is TCP 443. Organizations might also want to load balance TCP 80, but only so that the reverse proxy can redirect that traffic automatically to TCP 443 instead.

Pre-Authentication

Pre-authentication of network clients is a feature found in both Microsoft Forefront Threat Management Gateway and Microsoft Forefront Unified Access Gateway, which lets the reverse proxy authenticate a user before completing the SSL bridge back to an internal server. This way, unauthenticated traffic is not allowed to communicate with internal services, which makes the deployment more secure. Without pre-authentication, the SSL traffic is authenticated by the internal pool server. It is still inspected and filtered for malicious code by the reverse proxy, but pass-through authentication requires the internal servers to handle authentication of the requests.

Not all features of Lync Server support pre-authentication and whether pre-authentication can be leveraged depends greatly on business requirements. Specifically, if anonymous remote access is required for web conferences or dial-in conferencing, there must be some form of anonymous access allowed through the reverse proxy without authentication. In those situations, simple URLs can be used to split the traffic so pre-authentication can be used for all traffic, except the traffic destined for the meeting and dial-in conferencing URLs. Figure 5 shows how a separate web listener and IP address can present different authentication options depending on the service.

Figure 5. Pre-authentication with Unique Simple URLs

The reason why subdomains are required is because reverse proxy rules are generally configured based on a destination URL. As an example, consider the external web services URL being https://lyncexternal.companyabc.com/ and the simple URL for meetings being https://lyncexternal.companyabc.com/meet. Microsoft Forefront Threat Management Gateway pre-authentication is configured at the web listener level and web listeners are bound to a specific IP address.

Although it is possible to specify unique paths on each rule, such as /meet or /*, those URLs share the same base URL, so they must share a listener. Because the listener can have only one authentication method, a choice must be made between pass-through or pre-authentication. Conversely, using the simple URL https://meet.companyabc.com enables resolving that name to a separate IP address, web listener, and pre-authentication setting.

As discussed previously, using subdomain simple URLs grants some additional flexibility, but comes at additional cost because more subject alternative names are required. Instead of having a certificate just with lyncexternal.companyabc.com, an additional name, meet.companyabc.com, must be secured either with a subject alternative name entry or another certificate.