Is my HLB device a Reverse Proxy?

Ever since Microsoft announced that TMG was no longer to be sold, the Exchange and Lync implementers of the world have been somewhat at a loss.  Why?  Because the officially supported stance in the product documentation for both Exchange and Lync still says that the best practice is to abstract the environment from the nastiness in the outside world with a Reverse Proxy.  In other words, bring your outside web traffic in through your firewall, but don’t let it touch your servers.  Land that traffic on a Reverse Proxy (which one is the big question) and keep those baddies away from your internal environment. 

This raises the question of which Reverse Proxy to use.  Most of my projects have included some form of load balancer, and the load balancer product vendors will blithely state that “by definition, a load balancer is a Reverse Proxy.”  I know the fine folks over a Kemp Technologies certainly said that (guess where that quote comes from…) (to be fair, I get the same answer from Barracuda and F5 also)– and assuming that an HLB/VLB from one vendor operates pretty much the same as the next vendor, the purpose of this article is to put the concept to the test. In the immortal words of Ronald Reagan, “…trust but verify…” Let’s dive in.

Scenario

For our test, we will be using the following setup: 

• An external user on IP 10.10.10.104. 
• A firewall (TMG in this case) with an external IP of 10.10.10.58, and an internal IP of 1.1.1.2. 
• A Kemp VLB on the internal net of 1.1.1.0/24; a WAS VIP of 1.1.1.45, and two VIP member servers of 1.1.1.46 and 1.1.1.47. 
• I took the liberty of disabling the 1.1.1.47 node.  This enabled me to know exactly where the traffic would be going – making the network tracing much easier. 
• The firewall is doing a NAT from 10.10.10.58 to the VIP on 1.1.1.45. DNS is setup all the way around so that the workstation is attempting to contact https://lswaspoolext.tsoorad.net which DNS tells it is 10.10.10.58.

Here is a graphical representation:

Here is what the Kemp looks like, just in case you don’t trust me:

Workstation Traffic Analysis

From the workstation the browser saw this:

From the workstation, NetMon saw this:

From the top, the workstation on 10.10.10.104 is talking to the network printer, the domain controller, the network printer (again), (and again), www.google.com, the DNS resolution of 10.10.10.58 (our target URL of lswaspoolext.tsoorad.net), the firewall IP (again), Google (again), my network WAP (10.10.10.16), my DirectTV (10.10.10.103) and this workstation.  The IPV6 traffic is 100% between my work laptop and my Twist (which was my external workstation for this test).

Workstation Conclusion:

The workstation for this test is talking ONLY to the 10.10.10.58 address to get the data from lswaspoolext.tsoorad.net/hosting/discovery.

Firewall Traffic Analysis

Here is the Netmon trace on the Firewall:

Without proving the point again, I can identify all the traffic sources that the firewall is talking to on both interfaces.  At no time during our test did the firewall talk to 1.1.1.46 or 1.1.1.47.  The firewall did trade traffic with 1.1.1.45, the WAS VIP on the Kemp.

Office Web Apps Server Analysis

And finally, to whom was the WAS talking?  Let’s see:

It would appear (to me at least) that the server ls2013was1.tsoorad.net – which is responding to and delivering the content requested by our workstation  - has no knowledge of the workstation, or for that matter, the firewall through which the workstation is connected.  Slick!  Apparently, the techie mavens I talk to regarding using an HLB device as a Reverse Proxy might have known what they were talking about (I will never tell them – their heads are already big enough).

Conclusion

We traced the traffic all the way from the origination workstation through each step in the path.  For each hop, with our interest on who talked to who, we saw that the workstation never communicated directly to our target.  The traffic was definitely PROXIED by the Kemp VLB – to whit, traffic stopped at the HLB, the HLB retrieved the data requested, then returned that to the requestor.  To be fair, the TMG (our firewall) was doing the same thing, but I think you get my point.  Now you can tell your client with all equanimity, yes, the Kemp HLB is also a Reverse Proxy. Can we make the same assumption for other vendors?  I defer to Ronald Reagan.

YMMV