Implementing Cloud-enabled Management behind a load balancer

Products

Management Platform (Formerly known as Notification Server)

Issue/Introduction

CEM and load balancers:

Implementing Cloud-enabled Management (CEM) behind load balancers is a supported configuration with certain considerations:

With http responders turned off
No SSL Off-loading (see 150683 "Is SSL offloading supported by ITMS?")

For ITMS 7.6 and later, please see 178549 "How to configure F5 BIG-IP Local Traffic Manager to work with the ITMS Cloud-enabled Management traffic?" as an example of what to configure (however, it is up to the vendor and customer in configuring their load balancer).

Note: F5 has been the only load balancer that we have tested. We are aware of customers using x, y and z load balancers after they had followed their vendor configuration documentation.

Resolution

Questions regarding using Cloud-Enabled Management behind a load balancer:

It is worth mentioning that some customers have reported that they were able to configure this functionality by trial and error. However, as this is not a supported configuration with the ITMS 7.1 or 7.5 SP1 versions, support is unable to assist with implementation. ITMS 7.6 and later some guidance has been provided under 178549 "How to configure F5 BIG-IP Local Traffic Manager to work with the ITMS Cloud-enabled Management traffic?".

Why won't the load balancer, if it is supported, work with the Internet Gateway?

With regards to CEM any load balancer would act as a certificate proxy. Meaning that any traffic coming in via SSL to our CEM URL would have to first validate at the appliance using a signed machine certificate. The Gateway strictly uses a self-signed certificate and all functionality is built between the agent at the endpoint and the gateway, this would not work. Traffic needs to past through and the handshake will need to be established at the gateway.

How do CEM gateways work?

The Internet Gateway serves SMA connections using the following process:

The SMA establishes a TCP connection to the Gateway.
The SMA and Gateway exchange SSL handshake messages.
The Gateway sends a Client Certificate Request message and validates the received certificate chain.
If certificate validation succeeds, the Gateway opens a TCP connection to the backend Notification Server.
From this point the Gateway act as a proxy(simply forwarding TCP packets between the SMA and NS).
The SMA and NS exchange SSL handshake messages inside the established SSL tunnel.
The NS also sends a Client Certificate Request message and validates the received certificate chain.
If certificate validation succeeds, the SMA is in a fully connected state and can send inventory, receive policies, etc.

This method encrypts TCP traffic twice.

Can we use a proxy between the agent and the gateway?

Currently, starting with ITMS 7.6 and later some guidance has been provided under 178549 "How to configure F5 BIG-IP Local Traffic Manager to work with the ITMS Cloud-enabled Management traffic?".
It is not supported with ITMS 7.5 and 7.5 SP1 releases.

With recent versions, ITMS 8.1 and 8.5, If CEM is not involved, a proxy should be fine between HTTP/HTTPS communication. However, make sure this proxy is not doing SSL Offloading.
If CEM is involved and the client machine is external, a gateway should be the one used. A proxy shouldn't be involved between the CEM client and the Gateway. For HTTPS request it is either proxy or CEM gateway, not both.

If CEM agent is trying to connect to an internet gateway, it will not connect to proxy if a gateway is not visible directly, it will try connecting to the gateway only. If CEM agent is trying to connect directly to SMP then it may try connecting to the proxy if SMP is not visible directly.

But for persistent connections, you can set a proxy before the Internet gateway, although it does not help much now when we still need HTTP/HTTPS requests to get the packages. The persistent connection should be able to handle a proxy in the middle even when there is an Internet gateway handling the requests.