Tuesday, June 30, 2015

KEMP LoadMaster as Reverse Proxy for Lync/Skype4B Server



In this articleI will show how to configure KEMP LoadMaster HLB to act as Reverse Proxy for Lync  / Skype for Business server.

The topic of Reverse Proxy always have been the “weakest links” in the entire Lync/Skype4B installation journey for two reasons. First, people have a hard time grasping the basic concept why Reverse Proxy is necessary and second – what solution to use. Let’s take on each topic.

Reverse Proxy


Lync (Front End and Director role) have two web sites – Internal and External.


In Topology, the two web sites are bind to different ports


There is good reason for that – a request for web service might come from Inside (LAN) or Outside (Internet) and the server must respond accordingly. Think about meeting join – when we click Join Lync/Skype meeting link, a DNS query for meet.contoso.com will be made, and an IP address will be returned – either internal or public depending of which DNS we query. Based on our location, the server will “answer” with internal or external pool web services FQDN where the meeting will be hosted and we will join the meeting. So, the only way to “let” the server know where we are coming from is to… land on the appropriate web site. We cannot “choose” where to make the request (to the internal site if we are on LAN or the External site, if we were on Internet). Since in Meeting Invite we see only one web link https://meet.contoso.com/user/meeting (and HTTPS implies use of port 443), the only way we “land” on port 4443 (where the external site is bind) is to “flip” the traffic arriving on port 443 to port 4443.

One might say – but we can do that on our firewall with port forwarding. While true, it is not recommended for many reasons. To state one – certificates. Think about it – internal web services are bind to certificate issued by Internal CA. If we just do port forwarding, the HTTP request will be terminated with this internal certificate and unless the workstation have the Internal CA Trusted Root, and eventually internal Intermediate certificate(s), the SSL request will fail. In this case, how someone can join meeting from non-corporate laptop? Simple answer – it cannot.

So, to recoup - Reverse Proxy is the place where we terminate the SSL request with Public certificate, “flip” the port from 443 to 4443 and “proxy” the connection to Lync server. Server replies to RP on port 4443, RP “flips” the port again to 443 and replies to our request.

What software to use as Reverse Proxy


There are many "solutions" out there. I must emphasize on one thing – always use product from this list: https://technet.microsoft.com/en-us/office/dn788945. Only qualified products are thoroughly tested and any future Lync/S4B Cumulative Update and/or Product update will be aligned and validate prior to release. I have seen many cases where non-qualified product is updated and some or all  functionality is no broken, causing grief with both users and administrators.


Kemp LoadMaster



As I said in the beginning, this article is about KEMP. The primary reason – as of now, Kemp Technologies offers free LoadMaster: http://freeloadbalancer.com. Be not confused by the name “loadbalancer” – every HLB can act as reverse proxy and this is what we will do today.

First, of course, we need to register for KEMP ID. We will use this ID later to license the appliance and unlock the features. Once done, we are taken to the Download page.



Here, for this exercise I will use VMware OVF, but KEMP offers Virtual Alliance for many different platforms.


While deploying the OVF template, make sure the network adapter mapped to your DMZ subnet..


Here is the original settings after the VM was added. Note that both network adapters are on DMZ


We want the second network adapter on our server network


We are now ready to power the VM


As we see, the VM is configured with default IP 192.168.1.101, user name - bal and password - 1fourall.


Before we access the appliance via web browser, let's do some initial configuration. Login to the console with the default credentials. Change the IP address (if you wish to do so). I will use 192.168.1.111


Configure default gateway


and DNS



We are now ready to complete the configuration via web browser.



Accept the EULA, on the next screen select “Free LoadMaster”and click Allow.



Now we are taken to the licensing screen. Here we will use our KEMP ID.





We must change the password.


...and now our KEMP is licensed and features are unlocked.

Configuration


There are three steps involved – Install Templates (for automatic configuration), Install public certificate (to provide connectivity to non-corporate devices) and configure Virtual Service (the actual Reverse ProxyP)

KEMP Templates

When comes to Lync web services and HLB/RP, we have very specific requirements that must fulfill. The list can be found here: https://technet.microsoft.com/en-us/library/jj656815%28v=ocs.15%29.aspx?f=255&MSPPError=-2147217396

From my past experience, I can tell you that 99% of the issues were around missing/misconfigured parameters. Luckily for us, KEMP does offers the so called Templates: http://kemptechnologies.com/loadmaster-documentation/#c7842 – which, when used, will configure your new Virtual Service with all parameters as per TechNet. We will see this in the next step.

Download Lync 2013 Templates http://kemptechnologies.com/files/assets/templates/Lync2013.tmpl to your computer. In KEMP GUI, navigate to Virtual Services -> Manage Templates





Browse to the file we downloaded on the previous step and click Add New Template




As we can see, we have templates for all possible scenarios this Virtual Appliance can be used in our Lync environment.

Certificates


As I mention above, we will configure Reverse Proxy to serve request from Internet and so, we need to configure KEMP with Public certificate in order Mobile devices to trust. I will use Wild Card certificate for my domain issued by DigiCert. I already have the certificate exported in .pfx format (private key included).

In KEMP, navigate to Certificates -> SSL Certificates



Click Import Certificate



Browse to the .pfx file, enter password and make sure Certificate Identifier is one word (KEMP does not like white spaces) and Save.



***Next step is very important. Since this certificate is issued by Public Authority, we must also import any intermediate certificates that could be in the certificate chain. To do so, open the certificate in MMC and go to Certification Path tab. Here we see one Intermediate and one root – both must be imported.



I will find the root and the intermediate in my Local Computer Certificate store and export them in Base-64 encoded format (DER will not work on KENP). Then I will import those by clicking Add Intermediate button. Here is the final result




Configuring Virtual Service

In the initial configuration steps I have configured the appliance with IP address from DMZ. However, the Virtual Service must be able to connect to our Real Servers and so, I must configure the second virtual NIC with IP from the server subnet.

Go to System Configuration, Interfaces, eth1 and configure IP address/Subnet (don't forget to click Set Address)



Now we can create new virtual service using Template. Navigate to Virtual Service, Add New. Give it an IP address, select Lync Reverse Proxy 2013 from the “Use template” drop-down menu and click “Add this Virtual Service”. The IP address is any available IP on our DMZ network. At the end, this DMZ VS IP wil be mapped 1:1 to Public IP address.




You will be taken to the configuration screen for the 443 service (there was one more for port 80 which we don’t see right now) where we will complete the configuration.



What’s left is to configure the service with certificate and add the Lync servers. Expand SSL Properties, highlight the certificate you want to assign and move it to the “Assigned Certificates”. Don’t forget to click Set Certificates button or the change will not be applied.



Expand “Real Servers”



Click “Add New” and enter the IP address of the Lync server, make sure the Port is set to 4443 (remember, we have to hit the External web site which runs on 4443) and click “Add This Real Server” button.



 Repeat for all servers in your pool if you have EE pool.

Now click View/Modify Services on left...


...and you should see the Status as Up (green.) This indicates the the Virtual Service connected to the Lync servers and it is ready to go.


The service for port 80 is Down (red) because we have not added "real Servers" yet. Click Modify under Action column, Add New under Real Servers...



...add the IP addresses of the Lync servers again (make sure Port is set to 8080)


and the final result should be - all Green.


That's all, folks. Really! Configure your NAT, Firewall and DNS and test your new Reverse Proxy. I guarantee it will work.

If or when time permits, I will show you how you can use KEMP to serve multiple services with one  IP address. In my lab I use for Exchange, two EE pools and one SE Lync pools, ADFS and more with one single IP address.

5 comments:

CP said...

Thanks for writing this, however it seems most RP deployments keep both legs in a public/private DMZ instead of DMZ/Internal. I think this post would be more beneficial if you showed how to configure the KEMP for that scenario. Additionally doesn't the KEMP need the internal private CA root cert loaded at some point since the internal Lync web services use a private cert? These are all steps we had to do for TMG, and am interested in seeing it done in Kemp as well.

Drago said...

On the certificate - because we use public cert, the (real) servers trust this cert natively. Furthermore the VS does not decrypt and re-encrypt the traffic (no longer required for 2013/Skype4B).

Yes, I did a mistake showing the IP address of the Virtual Service as LAN IP (should be DMZ IP) and will correct this right now. Thanks for catching that!

As for both legs on Public/DMZ... KEMP do require that an interface is configured with IP on the same subnet as the real servers. Not sure why is that.

CP said...

Found a previous article that applies. I would think most security teams will require the RP to not "dog-leg" into the LAN. I know mine does. The article below is the only KEMP-Lync post I've seen about how to do this with KEMP. Hope it helps!

Excerpt from this article: http://unifiedme.co.uk/2014/03/configuring-kemp-reverse-proxy-lync-exchange-server/

"In developing the KEMP VLM to support a reverse proxy configuration, KEMP did not anticipate a network topology in which the KEMP is positioned between two perimeter networks (e.g. ‘DMZ-External’ and ‘DMZ-Internal’). Instead, the KEMP assumes a ‘dog leg’ topology in which the internal adapter is directly connected to the internal LAN (or, more accurately, the same subnet that published servers are hosted on – typically the LAN). However, working directly with KEMP technical support we were able to arrive at a configuration that supports an ‘external’ (Internet-facing) and ‘internal’ (LAN-facing) perimeter network, although this is not documented. Such a configuration allows traffic to be subject to separate inspection from the Internet to the KEMP and from the KEMP to the LAN (and vice-versa) and from a security perspective this is much preferred to the ‘dog leg’ short-circuit topology. To support two perimeter networks, the following configuration must be created on the KEMP:

a. VS definitions must be created that operate on the external adapter (e.g. eth0). These must be configured to simply forward all traffic to corresponding VSs defined on the internal adapter (e.g. eth1). In this way, the KEMP is configured to proxy traffic from its external adapter to its own internal adapter. A corresponding VS configured on the internal adapter is then configured to receive the traffic and perform SSL bridging, Edge Security Pack (ESP) filtering etc. to and from the published server(s) on the internal LAN. This configuration is necessary to ensure that the KEMP sends traffic to internal servers from its internal interface IP address (e.g. eth1). By default, if a VS is defined only on the external adapter (per the KEMP documentation), the KEMP will indeed send traffic from its internal adapter but the source IP address will be that of the external VS (i.e. from the external perimeter network – eth0). This will cause the firewall to drop the traffic as IP address spoofing will be detected. You can see how the KEMP engineering team did not anticipate a ‘dual perimeter network’ topology.

b. ‘Enable non-local real servers’ must be enabled under Network Configuration if the KEMP is located between two perimeter networks and the published Web servers exist on a remote subnet. If this option is not ticked, it will not be possible to select the option ‘Non-local Real Server’ when subsequently specifying a Real Server under Virtual Server configuration settings. Again, you can see how the KEMP assumes the device will be connected to the published server LAN in most scenarios (just like load usually balancers are… :) ).

c. The VS must be configured with transparency disabled. This is also necessary to allow a non-local Real Server IP to be specified."

Drago said...

Another excellent find!. Frankly, what prompted me to write this article is "quick and dirty" on getting lab up and running.

Anu said...


Really nice information you had posted. Its very informative and definitely it will be useful for many people
iOS Training in Chennai
Android Training in Chennai
php Training in Chennai