License Hub fails to download license bundles when configured behind an HTTP Forward Proxy Server in Connected Mode

Products

VMware vDefend Firewall VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

License Hub does not have a direct connectivity to Avi Cloud Console. Hence the admin goes to License Hub and configures a proxy server.

License Hub is able to register with Avi Cloud Console successfully via the proxy server but it fails to download the license file.
Alarm is seen on the License Hub saying License processing failed.

License processing failed: The License Hub could not process or save one or more licenses from the presented license bundle.

Environment

License Hub 5.1.2

Cause

The http client that fetches the license file from Avi Cloud Console is not configured to use the proxy server and hence the license file download fails.

This results in an alarm being generated on the License Hub.

Resolution

Resolution (Standard HTTP Proxy Case):

To remediate this issue, you must manually inject the required network environment variables directly into the deployment container specification using a runtime JSON configuration patch.

Step 1: Gather the Network Proxy Parameters

Log in to your License Hub UI.
Navigate to Server Configurations --> Proxy Server.
Note down the configured Proxy Host IP/FQDN and Port Number (e.g., 10.x.x.x:3128).

Step 2: Access the SSPI Control Plane Terminal

Establish an SSH connection to your SSPI console deployment using your administrator credentials:
```
ssh sysadmin@<ssp-ip-address>
```
Verify that your active Kubernetes configuration point path is mapped accurately to the workload cluster:
```
echo $KUBECONFIG
```
Expected output example: /config/clusterctl/1/workload.kubeconfig

Step 3: Determine Your Internal Local CIDR Exception Ranges

To prevent internal platform components from routing local database and microservice traffic externally to your proxy machine, you must determine your cluster's local subnet footprint.

Find the Node CIDR Range: Run the following command to see the internal IPs of the workload nodes:
```
k get nodes -o wide
```
Identify the subnet mask from the INTERNAL-IP column (e.g., if nodes are 172.16.111.43 and 172.16.111.44, your <NODE_CIDR> block is 172.16.111.0/24).
Find the Pod CIDR Range: Run this command to inspect the cluster network configuration and discover the IP range allocated to pods:
```
k get pods -A -o wide
```
Look at the IP column for the running pods to deduce the overall network block (e.g., if pods are sitting on 192.168.X.X addresses, your <POD_CIDR> block is 192.168.0.0/16).

Step 4: Apply the Deployment Runtime Patch

To ensure all short internal service names (such as site-service) are completely exempted from internet proxy routing, you must dynamically capture the active service inventory from your namespace and inject it alongside your network parameters.

Generate the Custom Local Service List: Run the following command in the terminal to automatically pull and copy a comma-separated list of every active internal service running in the workload cluster:
```
k -n nsxi-platform get svc -o jsonpath='{.items[*].metadata.name}' | tr ' ' ','
```
Keep this output string handy, as you will append it directly into the command below.
Execute the Environment Injection Command: Run the following k set env command. Substitute <proxy-ip>, <proxy-port>, <NODE_CIDR>, and <POD_CIDR> with your specific parameters discovered in Step 1 and Step 3.

⚠️ CRITICAL WARNING: At the end of the NO_PROXY string below, paste the exact comma-separated internal service name string you generated in sub-step.

k -n nsxi-platform set env deployment/licensing-service \
  HTTP_PROXY=http://<proxy-ip>:<proxy-port> \
  HTTPS_PROXY=http://<proxy-ip>:<proxy-port> \
  NO_PROXY="localhost,127.0.0.1,10.96.0.1,10.96.0.0/16,<NODE_CIDR>,<POD_CIDR>,.cluster.local,.svc,<PASTE_GENERATED_SHORT_NAMES_HERE_THAT_WERE_GATHERED_IN_THE_PREVIOUS_STEP>"

(For example, the end of your string will dynamically fill out to look like: ...svc,authelia,cluster-api,kafka,site-service,trust-manager)

Step 5: Restart the Licensing Service Deployment

Force a rolling restart of the deployment to cleanly terminate stale container threads and apply the newly injected network values:

k rollout restart deployment licensing-service -n nsxi-platform

Monitor the deployment rollout status until it completes successfully:

k rollout status deployment licensing-service -n nsxi-platform

Verification

1. Confirm Environment Injection Status

Verify that the runtime engine has integrated the values successfully by querying the pod configuration deployment manifest:

k get deployment licensing-service -n nsxi-platform -o yaml

Ensure that the env: array blocks explicitly list your configured HTTP_PROXY, HTTPS_PROXY, and NO_PROXY parameters.

2. Verify Successful Synchronization

Return to the License Hub Console browser UI interface.
Select the Licenses panel.
Click the Refresh Licenses button.
Confirm that the data sync completes successfully and the high-severity license file alert is cleared from the dashboard.

📘 NOTE ON HTTPS / DECRYPTING PROXIES: If your environment utilizes an advanced HTTPS-decrypting or SSL-inspecting proxy architecture (e.g., mitmproxy, Blue Coat, Zscaler), applying the basic HTTP environment variables will cause local container validation to fail with certificate trust errors. If you have an intercepting HTTPS proxy deployed, please open a Support Request (SR) / contact Broadcom Technical Support to have a designated engineer safely guide you through injecting your corporate CA certificate bundle into the License Hub deployment.

This issue is tracked internally via ticket #3722620 and is scheduled to be resolved in an upcoming release of License Hub.