Some DLP Detection servers are in unknown status after upgrade to 16.1

Products

• Data Loss Prevention Core Package
• Data Loss Prevention
• Data Loss Prevention Endpoint Prevent
• Data Loss Prevention Enforce

Issue/Introduction

After upgrading your Symantec DLP environment to version 16.1, some Detection Servers are no longer reporting to the Enforce console and appear in an "Unknown" status.

MonitorControllerX.log on enforce server shows that the connection is being closed by remote server:

May 5, 2025 4:29:49 PM com.vontu.communication.transport.ConnectWrapperOperation select
INFO: connectOp select failed
May 5, 2025 4:29:49 PM com.vontu.communication.transport.ChannelManager processOperationResult
INFO: Operation com.vontu.communication.transport.ConnectWrapperOperation:XXXXXXXXXXXXX:Detection_Server_Hostname:detectionserverdatabase:IP_Address.port:com.vontu.communication.transport.SessionIdentifier@XXXXXXX failed with exception: com.vontu.communication.transport.exception.TransportException: remote endpoint closed connection

Similarly, the SymantecDLPEnforceConnectorX.log on the Detection Server shows:

May 5, 2025 4:29:49 PM com.symantec.dlp.communications.applicationcommunicatorlayer.ApplicationCommunicatorActivityNotifiableImpl onCreateHandshaker
FINER: Creating Handshaker for the data connection with connection number: XX
May 5, 2025 4:29:49 PM com.symantec.dlp.communications.common.activitylogging.JavaLoggerImpl log
INFO: DC - Processing disconnected notification  for connection number XX at 2025-05-05 04:29:49. DisconnectReason=REMOTE_PEER_DISCONNECTED
May 5, 2025 4:29:49 PM com.symantec.dlp.enforceconnector.applications.connection.EnforceConnectorConnectionStatusWriter onDisconnected
INFO: EnforceConnector disconnected from MonitorController

As a test, you ping and use telnet from the Enforce Server to the affected Detection Server, and no network connectivity issues are observed.

However, when inspecting the traffic with Wireshark, you observe that the connection is being reset, and no TLS handshake occurs.

Additionally, using the openssl s_client -connect command — an open-source command-line tool used to initiate SSL/TLS connections and inspect certificates — from the Enforce Server to the Detection Server returns an error similar to the following. 

C:\>openssl s_client -connect Detection_Server_IP:Port
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(000001B4)
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1746538504
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

This indicates that while the TCP connection was established, the server reset it when OpenSSL attempted to send data. No certificate was presented, and the TLS handshake did not complete:

However, when running the same command locally on the Detection Server, the connection completes successfully, the server certificate is presented, and the TLS handshake is established.

 

 

Environment

DLP 16.1

Cause

The network connection between the Enforce and Detection Servers is being disrupted during the TLS handshake. This is commonly caused by network security devices (e.g., firewalls or proxies) performing SSL/TLS inspection, protocol validation, or otherwise interfering with secure communication.

It's important to note that this issue may only become apparent after upgrading to version 16.1.

As of DLP version 16.1, and with the introduction of the Universal Detection Server (UDS) architecture, support for third-party certificates has been added for communication between the Enforce Server and Detection Servers. In earlier versions, although self-signed certificates were used to encrypt traffic, a full TLS handshake was not performed, and the server certificate was not exposed during connection setup. As a result, network security devices such as SSL inspection tools, firewalls, or proxies may not have interfered with the traffic previously. This change can cause certain devices to inspect, block, or reset the connection if they do not trust the certificate or if the handshake violates their inspection or validation policies, leading to Detection Servers showing an "Unknown" status in the Enforce Console.

Resolution

To address this issue, ensure that any firewalls, proxies, or other network security devices between the Enforce and Detection Servers are configured to allow TLS traffic without blocking, inspecting, or modifying it.