A reverse proxy (a service that retrieves information on behalf of a client from servers usually located in a corporate network) is a required part of any Lync Server 2013 deployment that we want to make available to external users (as shown at http://technet.microsoft.com/en-us/library/gg398069.aspx). There are many reverse proxy solutions offered by vendors and a couple of free solutions available as part of the Windows OS. The first one is the Web Application Proxy (WAP) that is part of the Remote Access Server role in Windows Server 2012 R2. However, WAP is a relatively new technology, and there have been some issues related to using it as a reverse proxy solution for Lync Server 2013. The other solution is the IIS Application Request Routing (ARR) that enables a Windows server to act as a reverse proxy. We will talk about the setup required for the latter scenario.
The latest available version of IIS ARR is 3.0. A prerequirement for ARR 3.0 is to have IIS enabled on the server (we can use the default settings). ARR is available using the Microsoft Web Platform Installer (MWPI) at http://www.microsoft.com/web/gallery/install.aspx?appid=ARRv3_0. There is also a standalone version (ARR 3.0 standalone package) at http://www.microsoft.com/en-us/download/details.aspx?id=40813, which does not require the Web Platform Installer and could be a good solution for a server with a high level of segregation. We will use the first option (with MWPI). The FQDN of the server we are going to use is dormouse, the Lync 2013 Standard Edition Front End server is madhatter.absoluteuc.corp
, and the AD DS server (that includes a certification authority) is alice.absoluteuc.corp
. The frontend has a public name madhatter.absoluteuc.org
, as shown in the following screenshot:
The configuration of a reverse proxy for Lync Server 2013 requires a digital certificate (usually issued from a public CA) that must include at least the Lync Pool FQDN and the Lync simple URLs for Lync (meet and dial-in). The admin simple URL is optional, and for internal use only (http://technet.microsoft.com/en-us/library/gg425874.aspx).
Some reference material on this topic is available in the See also section of this recipe. A reverse proxy is usually deployed in a Demilitarized Zone (DMZ) network and will require two different network interfaces (NICs), one behind the Internet-facing firewall (external NIC) and one behind the backend firewall, used to connect to our internal Lync deployment (internal NIC). The reverse proxy will be reachable from the Internet using a Network Address Translation (NAT), a process performed by the firewall that converts an internal network address into a different address that is public on the Internet.
wonderland.lab
), so we have to populate the local HOSTS
file on our server.LyncCert
).madhatter.absoluteuc.org
). Leave the online flag selected. Click on Next.8080
and 4443
, if we haven't customized them in the topology design). In the server name field, type the name of our internal server (or load balancer) and click on Add. The configuration is shown in the screen capture. The steps are shown in the following screenshot:input= {HTTPS}, Type=Matches the Pattern, Pattern=on input={HTTP_HOST}, type=Matches the pattern, Pattern=madhatter.*
The reverse proxy will receive requests on standard ports (TCP 80
for HTTP and TCP 443
for HTTPS) and redirect them to ports 8080
and 4443
of our Lync Server deployment. The "public" Lync 2013 site that is listening on these ports has rewrite rules to handle all the SIP domains we have deployed. For more information, see the Lync 2013 Internal and External Web Sites post at http://tsoorad.blogspot.it/2013/04/lync-2013-internal-and-external-web.html by John Weber.
To plan Lync certificates, the following are some useful resources:
3.147.75.221