MPS and NDR Status Shows DOWN with "Lastline cloud resources associated with the customer license have not yet been provisioned."

Products

• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

In Security Services Platform (SSP)  Malware Prevention Service (MPS) and Network Detection and Response (NDR) status flags on the dashboard display as ANALYTICS | Status: DOWN.

The critical alarm indicates that the cloud-connector-check-license-status service within the SSP is degraded.

The cloud-connector-check-license-status-XXXXXXX pod may experience frequent restarts or be stuck in a CrashLoopBackOff state.

Pod logs for cloud-connector-check-license-status repeatedly show the cloud resources are not provisioned: 

 14:36:11,341 - nsx_cloud_connector.registration_service.check_cloud_status - INFO - The Lastline cloud resources associated with the customer license have not yet been provisioned.
 14:36:11,342 - default - INFO - Sleeping 0:00:30
14:36:41,374 - nsx_cloud_connector.registration_service.check_cloud_status - INFO - Querying Lastline cloud for licensing information...

Concurrently, checking the cloud-connector-update-license-status pod logs indicates that a valid, unexpired license is active locally:

15:14:07,937 - nsx_cloud_connector.registration_service.update_cloud_license - INFO - Updated license information: {'access_key': 'XXXXXXXXXXXXXX', 'subkey': 'nsx01', 'end_date': '20XX-0X-X'}

The update-license-status pod successfully verifies a valid license expiration date, but the check-license-status pod fails because backend cloud resources are completely unprovisioned.

Environment

SSP 5.0 and above

Cause

By design, If an SSP installation remains completely disconnected from the Lastline/NSX backend cloud for an extended period of time (typically several months), the backend cloud resources associated with the customer's license are automatically deprovisioned on the SaaS side to free up dormant infrastructure.

Resolution

Because this issue stems from an administrative deprovisioning status on the backend cloud infrastructure, it cannot be resolved through local configuration changes or pod restarts on the on-premises SSP installation.

Please follow the steps below to validate local connectivity and gather data before engaging Broadcom Support.

Step 1: Validate Local Cloud Connectivity from SSPI.

   Confirm that your on-premises environment still maintains network connectivity to the cloud backend by testing lookup and reachability via the cloud-connector-proxy pod:

    k get pods -n nsxi-platform | grep cloud-connector-proxy

    k exec -n nsxi-platform <cloud-connector-proxy-pod-name> -c cloud-connector-proxy -- nslookup user.lastline.com

    k exec -n nsxi-platform <cloud-connector-proxy-pod-name> -c cloud-connector-proxy -- curl -vI https://user.lastline.com

Step 2: Retrieve API Key Credentials

Collect the following backend authentication information from your SSP cluster to provide to support: 

 

kubectl -n nsxi-platform get secrets credentials.lastline.cloud --template={{.data.api_key}} | base64 --decode

 

Step 3: Open a Broadcom Support Case

  

Contact Broadcom Technical Support to log a service request. Provide the output of the commands in Steps 1 and 2, along with a copy of this KB reference.