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).
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 184.108.40.206/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 220.127.116.11/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 18.104.22.168 (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 (22.214.171.124) 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 126.96.36.199
This identifies the traffic from the virtual service on the LM and send responses back to the LM on 188.8.131.52 which knows what to do with the traffic.
Why does this work?
Well, the traffic shows up on the LyncWAS (184.108.40.206) 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 220.127.116.11 server thinks that to get to the 10.10.10.0 network, it needs to talk out its’ default route of 18.104.22.168. 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.