HTTPS offloading and network topology



I would like to check that my understanding of https offloading & network topology is correct.

I am currently testing https decryption/offloading with the VLM forwarding the unencrypted http traffic onto the application servers. 

(aside: our application requires transparency since it was designed before load balancing & part of it tracks client connections by source ip.)

At present I have tested successfully with  a 2-armed solution to ensure return traffic flows back through the VLM where it can be re-encrypted. 

Can I confirm that https offloading will effectively *require* a 2-armed approach?

Otherwise it looks to me like the application server will send http traffic directly back to the client (who should reject it)


[aside: I also successfully tested using a single armed solution where the application server has an explicit route for the client subnet(s) configured as the VLM. In effect this is just mimicking a 2-armed solution really & I don't really see any practical use for it, but it helped some testing while I was still building new network infra]  


If https decryption offloading does *not* require the 2-armed approach, please could I have some guidance as to why/how the traffic still gets back to the VLM for re-encryption?





Tony Vaughan

Hi Simon,

your question seems to be about transparency rather than two-armed setup

if transparency is disabled (i.e. the LoadMaster is NATing the traffic),
with a one armed setup and the real servers are non-local, the real server will respond to the LoadMaster via its gateway
with a two armed setup and the real servers are local, the real server will respond to the LoadMaster directly as its on the same network

the big difference is how the traffic is routed back, either directly or via an extra hop

is you are using transparency in this scenario then,
you are correct you need to make sure the real sever is sending the return traffic back to the LoadMaster

please see this link for an overview

2.4 Transparency Requirements



thanks for the link.

Yes, as I am using transparency the issue is (almost) about traffic routing. 

So I was incorrect in considering 2-armed only, and omitted to consider single-armed 2-subnet - thanks for that clarification. 

[by implication 2-armed is 2-subnet which is why I overlooked it]

So I should reword the question to "Can I confirm that https offloading will effectively *require* a 2-subnet approach?" 

(I think I said transparency was a requirement so you are correct in that traffic is required to be routed via back to the loadmaster)

I was really looking for the reasoning behind exactly why the traffic should be routed back that way (mostly just to tidy a couple of loose ends of understanding up)

Your link to the documentation very helpful - the following sentence partly clarifies:

"the client is expecting to see traffic come from the IP address of the Virtual Service, but instead will see traffic coming from the IP address of the Real Server. When that happens, the client system ignores the traffic."

A further page of documentation refers to " in order for a load balancer to do its job, the load balancer must be in the path of both inbound and outbound traffic" but I find that a bit vague.

I was actually interested in https decryption offloading, where the re-encryption step takes place back on the loadmaster & had hoped for a slightly more definitive statement about what would/wouldn't work, but in effect the first reference about traffic drop is probably sufficient.