Environment
- Carbon Black Cloud Sensor: All versions
- Apple macOS: All Supported Versions
- Linux: All Supported Versions
- Microsoft Windows: All Supported Versions
Objective
General troubleshooting guide for Sensor communication issues with Carbon Black Cloud services
Resolution
- Do the offline sensors all show the last check-in time as the same day/hour? That points to a potential infrastructure change - usually networking related - for instance a firewall ACL change, a GPO change, a new proxy or proxy password change, etc. Another possibility is a newly implemented zero trust solution and the traffic to Carbon Black needs to be bypassed by the solution.
- Test network connection to our services by following these docs:
- Do all the problem systems belong to the same subnet? That also points to a likely networking change
- Ensure that all firewall and proxy settings are correct. Make sure that the certificate revocation (CRL) checks to GoDaddy can go through, unless you have disabled CRL checks. Make sure the target can be resolved in DNS. Have there been any changes to the system hostfile?
- If the above look good, what do the logs say?
- The c:\program files\confer\confer.log shows current attempts to connect to our cloud services. It will iterate through several attempts to connect to the Carbon Black services in a particular order. Look for log entries around the same time as a “cloud hello” log entry
- Check the install logs, which detail the sensor registration process, including DNS issues, etc. Note that if the sensor(s) have previously registered and appear in the console, this may not help much, but can offer some insight as to what previously was set at install.
- Is there an in-line SSL inspection device being used, for instance BlueCoat? Carbon Black services use certificate pinning, so SSL decryption on our traffic cannot be used, or the connection will be rejected
- Are the GoDaddy root certificates installed?
- Is it possible that there are old records from a re-registered, reimaged, VDI or decommissioned device?
- If a system is re-registered (repcli reregister) it will get a new unique Device ID, and a new record will be generated for the sensor. The old record will not be deleted, and will still show "Active" for 30 days. The old record also has to be marked as deregistered before it will be able to be deleted, either manually or automatically. . This can lead to multiple records in the back-end database.
- A VDI system needs special setup or you will get duplicate records
- Devices that are decommissioned need to be removed from the console, unless the sensor is uninstalled and can communicate with our cloud services at the time of uninstall. During an uninstall, the sensor will attempt to contact our back-end services and de-register itself. Note that the record will still be in the console and will be listed as deregistered. The record can then be manually or automatically deleted.
- If a system is reimaged, and the sensor was not uninstalled before the reimage, the sensor will show as “Active” for 30 days from last communication to our cloud services. Then they will show as “inactive”. When a machine is reimaged, the sensor on the new image will get a unique Device ID when it registers.
- Export all your sensors data from the console to a csv, and make a pivot table in Excel to locate any duplicate hostnames.
- Is Auto-Delete enabled? You may not have the Auto Delete setting enabled
Additional Notes
This article should help with 90% of communication issues. If this does not help, please open a case and gather a sensor diagnostic and send the resulting file in to CB Support.
Related Content
