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 10.10.10.0./24 and one leg in 1.1.1.0/24.  HTTPS comes into a Virtual Service on one single IP (10.10.10.58) and uses various rules to redirect traffic to either a 10.10.10.0/24 network host or a 1.1.1.0/24 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 10.10.10.58 service correctly, and heading off to the underlying real server correctly, but it is arriving at the 1.1.1.73 (my Lync WAS test case) as a 10.10.10.58 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 (1.1.1.73) route table with the fix in place. If you are curious, the command is (from an elevated CMD):

Route add –p 10.10.10.58/32 1.1.1.5

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

Why does this work? 

Well, the traffic shows up on the LyncWAS (1.1.1.73) but appears to be originating from the KempLB but from the 10.10.10.58 address (which is correct from one point of view).  But the 1.1.1.73 server thinks that to get to the 10.10.10.0 network, it needs to talk out its’ default route of 1.1.1.2.  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.

YMMV