Reverse Proxy and Lync/S4B server

Recently, I came back to the TecheNet forums to check on the issues people are experiencing with their deployment. To my surprise, I found a lot of questions about the Reverse Proxy - how it works, why we need one and, of course, a lot of question regarding issues with Mobility. While the Reverse Proxy (RP) is rather simple topic, lit appears people have a hard time making the connection between how Lync/S4B is designed to work and the role of the Reverse Proxy in the deployment.

In this series of posts I will try to decode the mystery of the Reverse Proxy and provide detailed instruction on how to configure KEMP’s load balancer (free edition) to act as the Reverse Proxy.

Let’s start with the concept of the Reverse Proxy. The Lync Director and Frond End servers have two web sites - Internal and External.

But, why TWO websites?

Security

The first, and obvious, reason - security. We notice that at least two virtual web sites are "missing" from the external web site - cscp (Control Panel) and OcsPowerShell. This is because accessing the management layer of our environment from the Internet is really bad idea and Microsoft removed the accessibility from the Internet altogether.

This reason alone justifies the fact we have two web sites, but... this is not all.

Location, location, location

Yes, location can cost you, even in the Lync server real estate. Here is why:

Since we have two web sites that bind to the same IP address, each must be configured to use unique ports. The default ports in the topology are 80 and 443 for the Internal, and 8080 and 4443 for the External site.

Client workstation would query DNS depending of its location (LAN or Internet) and will resolve the fully qualified domain names (FQDN) to different IP addresses. “Internal” implies that it will serve requests from the inside, or internal networks (LAN) and “External” implies requests from the Internet.

Now, let's look a meeting invite:

The link in the meeting invite is https://meet.domain.com/user/meeting_id and this invite will be distributed to all participants. When we send out the invite, there is no way of knowing where the invitees will come from - some might come from LAN, some from the Internet. It is very important to "let the server know" the "entry point" of any web request in order to have an appropriate response. We will see this later.

Requests from the LAN would come to the Internal web site (DNS resolved to internal IP), which is listening on port 443 (or the port defined in the topology). Requests from the Internet will land on the External web s... wait a second - the external web site is listening on port 4443, but we don't have a "special" invite for those who are to join from the Internet with a "special" link like https://meet.domain.com:4443/user/meeting_id - after all we just want the invitees to click and join, period. The unified invite implies that all meeting join requests will be made to port 443.

And, here the controversy begins (all good stories have controversy…). The very first thought of any novice (no offense) is - "Ha!! I can do that with port forwarding on my firewall and this will save me some trouble fiddling (sorry, Southern expression, been living in the Bible Belt for too long) with a Reverse Proxy and such". I am not saying it will not work, but it will cost you.

The two web sites are meant to serve SSL traffic and so, a certificate must be assigned to each.

By design, the certificates configured on our Lync Front End servers will be issued from the internal (Private) certificate authority and will be free. If we just use port forwarding, requests from the Internet will be terminated with the Private certificate which will not be trusted from browsers and/or devices. As a result, users will get "This web site cannot be trusted" prompt or some functionality will not work at all.

If we want to provide the desired seamless end user experience, in such cases (port forwarding), we have one option - purchase (unless you are one of the companies that issues public certificates and you likely are not!) Public certificate for your Lync Front End server. Here is the Subject Alternative Name list of FQDN's included in the certificate for my lab:

14 names (this server alone, would have been 16 if I wanted to use one certificate on all three servers in the pool) and this is a lab! Yes, two paired Enterprise Edition pools with three members each and two SIP Domains, but... just saying. Such a certificate will cost you a fortune.

Oh hail Reverse Proxy!

Here comes the Reverse Proxy. There are many "solutions" out there, and not many are certified or qualified:

In essence, the reverse proxy is software that accepts web traffic on port 443, terminates the SSL session with certificate of our choice (from Public Certificate Authority, thus trusted across the platforms), and “proxies” the traffic back to Lync server on port 4443. In other words, the traffic lands on the External Web Site on the Director or Front End Web Services. This public certificate will have a Subject Alternate Name list that is a lot shorter (and cheaper) or, if you already have a Wildcard certificate for your domain, you are all set - you can use it and don't have to purchase one explicitly for your Lync deployment. (For reference – the reverse proxy is one of the only places in all of your Lync Infrastructure where you can safely – and in a supported scenario – use a wildcard certificate.)

Here is visual demonstration of a response from the Lync server based on where the request comes from. We did not literally tell the server but rather the server determined the location and formulated the response based on which web site (Internal or External) was visited.

Response from lyncdiscoverinternal (request come from LAN).

Response from lyncdiscover (request comes from Internet). Note that all referrals are to the External Web Site FQDN as defined in Topology.

Money, efficiency and common sense

Let's talk about port 8080 on the External web site. I often see people neglecting this service - "Why do I need it, clients would always do the "real" work over SSL anyway".

True, if you support a single SIP domain in your environment. What about two, as in my lab, or 20, or thousands (think Office365). After all, each sip domain would require its own "lyncdiscover" record, perhaps its own "meet" and so on. Imagine how such a certificate would look like (besides the native limitation of max number of names in the SAN list). It is not plausible to assume that every time a new tenant is created on the Microsoft cloud, someone goes out and acquires and amended certificate.

skypeuc.com is an online tenant on Microsoft cloud. As such, lyncdiscover.skypeuc.com is configured according to the best practices i.e. pointing to the cloud. If we make an HTTPS GET request to https://lyncdiscover.skypeuc.com, we get a rather unpleasant surprise:

However, if the request is http://lyncdiscover.skypeuc.com, it works

What is going on here? It is a simple answer - http redirect. When the browser visited Microsoft's Reverse Proxy on port 80, the request was forwarded to the External web site (port 8080) of the infrastructure which responded with:

i.e. "Go to this FQDN and use SSL protocol". Browser did exactly that, verified the identity of the web site...

...and proceed further. And, by the way, as I said above, Wildcard certificate will do just fine...

Hopefully by now you all are convinced that Reverse Proxy is an essential piece in the Lync deployment puzzle and serious efforts must be made to understand the concept, evaluate the options,  and configure the Reverse Proxy correctly in order to provide your users with stable, working Lync/S4B environment in a 100% supported configuration.

In the next article, I will explain in details how Mobility works. Issues with Mobility are perhaps #2 on TechNet forums and requires yet another explanation.

Lastly, I will show how to configure KEMP Load Balancer to act as Reverse Proxy in your Lync/S4B deployment.