Skip to main content

Resolving Druva VMware Backup Proxy Failures and Network Connectivity Blockages

Resolving Druva VMware Backup Proxy Failures and Network Connectivity Blockages

Problem description

When deploying, registering, or running backups via the Druva VMware Backup Proxy, operations may fail with network timeout errors, vCenter/ESXi snapshot execution failures, or proxy disconnects.

This issue typically occurs in environments with strict internal firewalls, SSL inspection appliances, or improper traffic routing between the proxy, local VMware infrastructure, and the Druva Cloud.

Cause

Network communications are blocked or intercepted along one of four critical communication paths:

  1. Management Traffic: Blocked TCP Port 443 communication between the proxy and vCenter Server.

  2. Data Traffic: Blocked TCP Port 902 communication between the proxy and ESXi host management interfaces (when using NBD mode).

  3. WAN Traffic: Intercepted or blocked outbound HTTPS (TCP Port 443) traffic to *.druva.com or regional AWS S3 endpoints.

  4. Environment Misconfigurations: Deep Packet Inspection (DPI/SSL Inspection) breaking TLS certificate chains, or NTP time drift causing AWS authentication timeouts.

Resolution

Ensure your network, firewall, and VMware environments adhere to the required traffic flows detailed below:

1. Configure Internal Management Traffic (LAN)

The proxy requires uninterrupted management access to discover VMs and execute snapshot operations.

  • Destination: vCenter Server

  • Port: 443 (TCP)

  • Purpose: VM discovery, snapshot request/consolidation, and configuration retrieval.

2. Configure Internal Data Traffic (LAN)

Depending on your selected Transport Mode, ensure the proxy can stream virtual disk (.vmdk) data:

  • A. NBD (Network Block Device) Mode:

    • Destination: Individual ESXi Hosts

    • Port: 902 (TCP)

    • Purpose: Streams data using the VMware NFC (Network File Copy) protocol from the host management interface.

  • B. HotAdd Mode:

    • Destination: Internal Virtual SCSI Bus

    • Port: N/A (Internal backplane to ESXi)

    • Purpose: Mounts target VM disks directly to the proxy, avoiding LAN interface bottlenecks.

3. Allow Outbound Data Traffic (WAN)

The proxy processes, deduplicates, and encrypts backup data before sending it outbound to the cloud.

  • Destination: *.druva.com and regional AWS S3 Endpoints

  • Port: 443 (TCP)

  • Protocol: HTTPS / TLS 1.2

  • Purpose: Control commands, metadata synchronization, and deduplicated block uploads.

4. Configure Auxiliary Traffic & Firewall Best Practices

  • Auxiliary Ports:

    • NTP Server (Port 123 UDP - Mandatory): Time synchronization for valid TLS/AWS authentication tokens.

    • CloudCache (Port 443 TCP - Optional): Required only if utilizing localized storage for LAN-speed operations.

    • Target VM (Port 3542 TCP - Optional): Required only for Application-Aware processing (SQL/Exchange).

  • Firewall Rules:

    • Inbound Ports: None required. All connections are initiated outbound by the proxy.

    • DNS Whitelisting: Whitelist by domain (*.druva.com) rather than static IP addresses, as cloud endpoints use dynamic IP pools.

    • SSL/HTTPS Inspection: Exclude the Backup Proxy IP from SSL Deep Packet Inspection (DPI). Decrypting the TLS stream breaks cloud authentication.

Include and exclude filters

  • Include: Domain *.druva.com on outbound firewall rules.

  • Exclude: Backup Proxy IP address from SSL/HTTPS Deep Packet Inspection (DPI).

Verification

To verify that network traffic flows are operating correctly:

  1. Test Cloud Connectivity: Log in to the Backup Proxy terminal and verify connection to Druva cloud endpoints over TCP port 443:

    telnet phoenix.druva.com 443 # OR nc -zv phoenix.druva.com 443
  2. Test LAN Connectivity: Verify that the proxy can reach vCenter on port 443 and individual ESXi hosts on port 902:

    Bash

    nc -zv <vCenter_IP> 443 nc -zv <ESXi_Host_IP> 902
  3. Verify Time Drift: Check NTP time synchronization using chronyc tracking or ntpdate -q to confirm the proxy clock is accurately synchronized.

Did this answer your question?