Implementing Cloud-enabled Management (CEM) behind a load balancer
search cancel

Implementing Cloud-enabled Management (CEM) behind a load balancer

book

Article ID: 181705

calendar_today

Updated On: 06-20-2025

Products

IT Management Suite

Issue/Introduction

CEM and load balancers:

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

  1. With http responders turned off
  2. No SSL Off-loading (see SSL offloading is not supported by ITMS)

For ITMS 8.x, please see Configure F5 BIG-IP Local Traffic Manager to work with the ITMS Cloud-enabled Management traffic as an example of what to configure.  NOTE: It is up to the vendor and customer to correctly configure their load balancer.

NOTE: F5 is the only load balancer that has been tested. Symantec/Broadcome is aware of customers using x, y and z load balancers after they followed their vendor configuration documentation many of these were able to work properly.

Environment

ITMS 8.x

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 8.x, Symantec/Broadcom Support is unable to assist with implementation. Some guidance has been provided under 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 the CEM URL would have to first validate at the appliance using a signed machine certificate. The Internet Gateway strictly uses a self-signed certificate and all functionality is built between the agent at the endpoint and the Internet Gateway, and this should not work. Traffic needs to pass through and the handshake will need to be established at the Internet Gateway.

How do CEM gateways work?

The Internet Gateway serves Symantec Management Agent (SMA) connections using the following process:

  1. The SMA establishes a TCP connection to the Internet Gateway.
  2. The SMA and Internet Gateway exchange SSL handshake messages.
  3. The Internet Gateway sends a Client Certificate Request message and validates the received certificate chain.
  4. If certificate validation succeeds, the Internet Gateway opens a TCP connection to the backend Notification Server (NS).
  5. From this point the Internet Gateway acts as a proxy - simply forwarding TCP packets between the SMA and the NS.
  6. The SMA and NS exchange SSL handshake messages inside the established SSL tunnel.
  7. The NS also sends a Client Certificate Request message and validates the received certificate chain.
  8. 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 Configure F5 BIG-IP Local Traffic Manager to work with the ITMS Cloud-enabled Management traffic.

With the ITMS 8.x versions, 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, an Internet Gateway should be used. A proxy shouldn't be involved between the CEM client and the Internet Gateway. For HTTPS requests it is either proxy or the CEM Internet Gateway, but not both.

If CEM agent is trying to connect to an Internet Gateway, it will not connect to proxy if the Internet Gateway is not visible directly, but it will try connecting to the Internet Gateway only. If the CEM agent is trying to connect directly to NS then it may try connecting to the proxy if the NS is not visible directly.

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