About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Kemp 7.0.12a Two Arm bug

Update: 14 March 2014

According to Derek Kiely (Kemp), the fix will be in a 7.0-14 firmware release due out this month (see his comment below).


The Issue

Working in my lab making sure I know what I am doing with a two-arm Kemp LoadMaster configuration.  Here is what I am attempting to setup:


I am using a Kemp VM100 (firmware 7.0.12a) with content rules to redirect 443 traffic to various target virtual servers.  Specifically, the LM has one leg in and one leg in  HTTPS comes into a Virtual Service on one single IP ( and uses various rules to redirect traffic to either a network host or a network host.

According to the super-helpful folks at Kemp support, there is a bug in Kemp firmware 7.0.12a that results in abysmal failure on this setup.  Apparently, the traffic is landing on the service correctly, and heading off to the underlying real server correctly, but it is arriving at the (my Lync WAS test case) as a source when it should be showing up as a 1.1.1.x source. 

But what do I do NOW?

The fix is to put a static route into the target real server.  Here is my LyncWAS server ( route table with the fix in place. If you are curious, the command is (from an elevated CMD):

Route add –p

This identifies the traffic from the virtual service on the LM and send responses back to the LM on which knows what to do with the traffic.


Why does this work? 

Well, the traffic shows up on the LyncWAS ( but appears to be originating from the KempLB but from the address (which is correct from one point of view).  But the server thinks that to get to the network, it needs to talk out its’ default route of  And your connection fails because the real server is sending responses out the wrong gateway.  By adding the static route for the expected source IP, and pointing it to the KempLB, we now have a coherent route for the traffic.  A bit clunky for now, but it works.

My thanks to Kemp Tech support for identifying this issue.  Kemp is providing a fix in the next release which is due out shortly.



Unknown said...

Issue has been resolved. Version 7.0-14 is due for release this month.

Unknown said...

Hi John, this issue has been resolved and will be fixed in 7.0-14 that is due for release this month.

Sfb 2019 July 2019 CU

Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...