Home » Archive » Configuring Loadbalancer.org appliances as Reverse Proxy for Skype for Business

Configuring Loadbalancer.org appliances as Reverse Proxy for Skype for Business

I wanted to share this configuration guide with you as I have never come across these load balancers before. A customer of mine had already purchased licences for these load balancers and wanted to leverage their capabilities as a reverse proxy for Skype for Business. Firstly, a quick search on technet revealed that these are not certified reverse proxy appliances, so I was a bit dubious as to whether these would actually do the job. In fact even KEMPs have been taken off the list. Currently there are only 2 reverse proxies that have gone through the certification process and these are; Big IP’s F5 and of course Microsoft Web Application Proxy (reference: https://technet.microsoft.com/en-us/office/dn947483). Looking through the history of Skype for Business, knowing it is almost an R2 of Lync 2013, I looked up ync 2013 certified hardware. Loadbalancer.org appliances are certified for Load Balancing of Lync 2013, but not for reverse proxy (reference: https://technet.microsoft.com/en-us/office/dn788945.aspx).

Armed with this, I promised the customer nothing, and made them aware that it may work, and if not then we have to perhaps consider KEMP’s free VLM instead. Anyway, it appears that these appliances can be used for reverse proxy requests for Skype for Business.

Firstly you need to configure the networking of the Load Balancers, with eth0 as the interface on the external DMZ subnet and eth1 as the interface on the internal DMZ subnet. In my lab I must confess, I do not have an internal DMZ, so the internal eth1 NIC sits on the lab network. My bad – but it works for me J

  1. Under Local Configuration > Network Interface Configuration, configure eth1 with you internal DMZ IP. Eth0 will already be configured with the static IP you assigned in the console during setup.

2. Next, Under Local Configuration > Routing. Add in the static routes for your subnet that the Skype for Business Front-End server sit on. (I didn’t need it, but for sake of clarity)

  1. Now we have the basic administration out of the way, we can start to build our virtual services.
  2. Under Cluster Configuration > Layer 7 – Virtual Services, select “Add a new Virtual Service”
  3. In the Label field, give this service a name eg. LB-To-Skype. In the virtual service IP address, enter an IP address on the external DMZ subnet that is not in use. (This is not the NATted IP address of Skype for Business Web Services!). Enter the listening port as 443, although this can be anything you want to be honest. Make sure the Layer 7 protocol selected is set to HTTP mode if you are using Skype for Business Enterprise FE Pools. Then press Update
  4. Once the configuration has been saved into memory, click on the “Modify” link associated with the Virtual Service you have just created.
  5. Ensure that the persistence mode is set to HTTP Cookie to ensure that initiated web requests go to the same back end server and change the Health Checks to “No Checks, always On” and press Update. (You can health check the FE’s if you like using your own scripts etc)
  6. Next, Under Layer 7 – Real Servers, using the link “Add a new Real Server” associated with your virtual service, we want to add the Skype for Business Front End servers. This is so the virtual service knows where to send HTTPs requests.
  7. In the Label Field, give this a name you can associate the relevant FE with e.g. The hostname of the FE server. In the Real Server IP address field enter the IP address of the FE server. In the real server port, enter 4443 and press Update. Repeat process for other Fes in pool.
  8. Once added, click on the “Modify” link associated with each Real Server
  9. Tick the box to “Re-encrypt to Backend” and press Update. Repeat for all Real Servers
  10. Next, under SSL Termination, click on “Add a new Virtual Service”
  11. In here, give the label a name. This will represent external connections coming in from the internet. In the Virtual Service IP enter the private IP address in the external DMZ subnet that you have NATted a public IP address used for exposing your web service URLs. In the Virtual Service Port, enter the port number to listen on, 443. In the Backend Service IP address field, Enter the IP Address of the virtual service you created in Layer-7 Virtual Service and the port it listens on. Leave all other settings as default and click Update.
    Essentially, what is happening here is, A HTTPS request comes in from the public internet, hits the SSL Termination VIP address, which then looks to send the request to the Layer-7 VIP address, which has real servers in the backend (SFB FE) listening on 4443. The Load Balancer will decrypt the public certificate at the SSL Termination VIP layer and then re-encrypt when the packet leaves the Layer-7 VIP to the SFB FE.
  12. Once the SSL Termination VIP has been created, click on the “Certificate” link associated. This is where you will upload your public web services certificate. I haven’t got one, so I am using an Internal CA signed cert.
  13. As I already have this certificate as a PFX, I will upload it here. Alternatively, you can request the certificate directly from the load balancer in this same window. Upload the PFX.
  14. Next, we need to commit our changes to bring the service live. I found the best way to do this is to use the Restart Services feature under Maintenance. Sometimes the commit changes box (blue) doesn’t take effect. First clear the HA Proxy Stick Table, restart the HA Proxy service and then restart the STunnel Service. Once restarted, go to System Overview to check the Virtual service has come online.
  15. If you have configured your load balancer correctly, and your firewall and routing is done properly, then the service should be green. Any other colour, you have issues.
  16. All that is left to do now is test the web URLs for Skype for Business from an external device. All being well, you should see the web pages presented

As I said, the Cert warning for me is because I am using an internal CA for my certificate, not public and I haven’t installed the root cert of the CA to this machine.


  1. Why are you using two IP addresses? Surely you could get away with one IP address by having the SSL endpoint listening on 443, then forwarding to the HAPROXY/Layer 7 virtual service listening on 4433 for example…
    At least this is how I have my LoadBalancer.org appliances set up.

    • Hi
      The reason why I chose to create a 443 virtual service to forward to another is because the customer wanted to use 443 load balancing for multiple back end services. If I followed the way you described it was my understanding that this would mean I could not use the LB for other 443 services. To be honest, I usually use KEMP LBs but the customer used these. Never seen them before or after, so this is how I got it work for multiple 443 services such as Lync, Exchange, Office Web Apps etc. I may be wrong, and that’s fine. I take on board your point and if you believe the information is incorrect then I am happy to discuss and edit where valid. I did consult with LB.org support when setting this up and they confirmed that the configuration was correct.

      Personally I like to separate services where possible for ease of management and understanding.

      Thank you for your input and time to comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: