DLP cloud detector in "Disconnected" status

Products

Data Loss Prevention Cloud Detection Service Data Loss Prevention Cloud Detection Service for ICAP Data Loss Prevention Cloud Detection Service for REST Data Loss Prevention Cloud Service for Email Data Loss Prevention Cloud Package Data Loss Prevention

Issue/Introduction

The Data Loss Prevention (DLP) Enforce Server shows that one or more DLP cloud detectors are disconnected.

Environment

DLP Cloud Service for Email
DLP Cloud Detection Service (for ICAP, or for REST)
DLP Cloud Detector (aka Cloud Connector)

Cause

Various issues related to the use of an Enrollment Bundle, or to the status of the Cloud Service at any time.

Resolution

This workflow offers suggestions to help you move through the problem.

New install

Without any pre-existing DLP Cloud Detectors installed/enrolled prior, check for the following error codes:

Shows a 4201 Event code (error requesting client certificate from Symantec Managed PKI Service).
This is the most common issue, and is always network-related (i.e., the Network team for Enforce Server environment needs to update any proxy and/or firewall rules to allow your Enforce Server to connect to the Cloud Service Gateway). See this KB for steps: DLP Cloud Service enrollment: error requesting client certificate from Symantec Managed PKI Service (broadcom.com)
Shows a 4200 Event code (client certificate successfully obtained from Symantec Managed PKI Service).
Check the Enforce Tomcat logs for either of the following errors:
- “Unable to write key store file” - for this error, see this article: Unable to write key store file "enforce_keystore.jks" when registering new Cloud Detection Server (broadcom.com)
- “...cannot be cast to org.bouncycastle.asn1.DERObjectIdentifier...” - for this error, see this article: Cloud detector showing “disconnected” after bundle upload to Enforce (broadcom.com)
No errors per se. The Cloud Detector might show as "Unknown":
- Try recycling the Enforce DetectionServerController service (aka the MonitorController service).
- FYI: the Cloud Service presents additional requirements for MonitorController service. For details and recommended levels, see Monitor Controller performance issues after adding new Detection Servers (broadcom.com)

Not a new install

A DLP Cloud Detector was previously connected, but now is not. Please see which of the following issues may apply.

Firstly, as of February 2021, the DLP Cloud Services have migrated fully to the Google Cloud Platform. For more information about the GCP Migration, see this Product Advisory.
- Your Enforce Server cannot connect to the Cloud Service unless it is version 15.1 MP1 or higher:
  - If it is NOT - replace the Enforce Truststore, as per Replacing the Cloud Services Enforce Truststore prior to migration of DLP Cloud Service to Google Cloud Platform (broadcom.com).
  - You should also upgrade, as versions 15.1 and 15.5 are both End of Service. See list of current and EOS releases here.
- Any proxy and firewall rules must allow the Enforce Server continued access to the URLs listed in this article.
- If the truststore is NOT replaced, this article describes the error which can result: Cloud Detector Disconnect - authentication issue with the validity of the certificate (broadcom.com)
Secondly, by design, the Cloud Service will “disconnect” every 24 hours. See Cloud Detection Servers show as disconnected periodically (broadcom.com).
Thirdly, also by design, Cloud Certificates expire 3 years after enrollment.
- Check the expiration date for the "Cloud Certificate", found at the System > Settings > General page in Enforce.
- Renew expiring Cert KB: Renew expiring cloud certificates (broadcom.com).
More than one Detector is involved – usually this appears in relation to some kind of “account issue”:
- Error 1: "Cloud Service unreachable due to an account issue":
  - Recycling the MonitorController service as per article above may allow your Detector to reconnect; if this recurs frequently, there is a fix in 15.7 MP1 and above: Error after adding new Cloud Detector "Cloud Service unreachable due to an account issue" and status remains "Disconnected" (broadcom.com).
  - If recycling does NOT resolve it. If this happened after moving a Cloud Detector from one Enforce server to another, verify if the second Enforce was clone of the first one: Please contact Support for assistance on this issue.
- Error 2: “Cloud Service is not available because of an account issue”. Usually because of TRIAL Detector, or some kind of error in provisioning, where there are two separate Accounts in one Enforce database: Please contact Support for assistance on this issue.
If recycling the DetectionServerController resolves the issue but it recurs infrequently, it could be the Enforce Server connection to the Oracle Database is at fault. Please confirm the following recommendation if the Oracle database connection is severred without first stopping the Enforce Server services: Recovering from Symantec Data Loss Prevention database connectivity issues (broadcom.com)
[Rare]: "The bundle refers to a Gateway different than the one that has already been configured." Happens if you have a Detector provisioned in the EU region and have subsequently added a second Detector that was setup in the US region (or vice versa): Please contact Support for assistance on this issue.
If you have upgraded the Enforce "ServerJRE" to 1.8.0.211 or higher – and all Cloud Detectors have gone into a disconnected state: Please contact Support for assistance on this issue.

Additional Information

The following circumstance can occur in either old or new installs (i.e., Disaster Recovery scenarios).

If you are enrolling a Cloud Detector in an Enforce Server that is a clone of another one that previously had a Cloud Detector enrolled, this error can also occur:

“Cloud Service is not available because of an account issue”

This issue can occur even if the original Enforce Server had its Cloud Detectors deleted prior to being cloned.

Please contact Support for assistance on this issue.