Skip to main content

File Server backup stuck at 0% or fails with SSL errors when Druva URLs are blocked or SSL inspection is on

File Server backup stuck at 0% or fails with SSL errors when Druva URLs are blocked or SSL inspection is on

Problem Description

A Hybrid Workloads File Server backup job starts but never progresses, or finishes with errors, even for a small backup set. The agent can reach the network, but its connection to the Druva cloud is either blocked because the required Druva URLs are not allowed on the firewall, or intercepted by a firewall or proxy that performs SSL/TLS inspection (deep packet inspection).

Symptom

  • The File Server backup job is stuck at 0%, or ends as "Succeeded with errors" or failed, with an SSL error reported for the job.

  • Where SSL inspection is the cause, jobs fail at session initialization with "broken pipe" errors, or sit without progress and then fail with Phoenix error 189.

  • A TCP connection to port 443 succeeds, so basic connectivity looks healthy, and restarting the Druva Enterprise Workloads Agent service on its own does not resolve it.

Cause

Route 1 - Required Druva URLs are not allowed. The firewall or network blocks some of the URLs the agent needs, so the SSL connection to the Druva cloud breaks and the backup job fails or hangs. Backups worked as expected once the URLs were allowed.

Route 2 - SSL inspection. A security proxy or firewall decrypts and re-signs the HTTPS traffic to Druva. An OpenSSL test against the Druva endpoint returned a certificate chain issued by the SSL-inspection product instead of Druva's certificate, with a "self-signed certificate in certificate chain" verification error. The agent does not trust the substitute certificate, so jobs hang or break. In this scenario the Druva URLs were already allowed and the jobs still failed, so allowing URLs alone does not rule out Route 2. A bypass of SSL inspection for the Druva endpoints is the recommended configuration; that it resolves the failure has not yet been confirmed by a customer.

Resolution

  1. Allow the Druva URLs and ports for your region on the firewall, including both the FQDN and alias URLs and outbound port 443, as listed in "Firewall, antivirus and network configuration for Druva Enterprise Workloads" (see below).

  2. From the file server, run an OpenSSL test against a Druva endpoint, for example openssl s_client -connect devicemgmt-reverseproxy-dcp.druva.com:443, and check the certificate chain. If the issuer is your own proxy or security product rather than a public certificate authority, or OpenSSL reports self-signed certificate in certificate chain, SSL inspection is intercepting the connection.

  3. If SSL inspection is intercepting, configure an SSL decryption (inspection) bypass for the required Druva endpoints on the firewall or proxy.

  4. After the firewall change, restart the Druva Enterprise Workloads Agent service on the file server.

  5. Start the backup again from the console and monitor it. The job should move past 0% and complete. If it is still stuck, collect the OpenSSL output from step 2 and the job details and contact Druva Support.

To reduce the chance of recurrence, check the Druva allow list and the SSL inspection bypass whenever the firewall or proxy policy changes.

Evidence

Snippet from the OpenSSL check on an affected file server (the issuer line is omitted because it identified the customer):

connect to devicemgmt-reverseproxy-dcp.druva.com:443 verify error:num=19:self-signed certificate in certificate chain

See also

Did this answer your question?