> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloud.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Private Cloud Connector Troubleshooting

> Common issues when running the Private Cloud Connector, with step-by-step diagnostics and fixes.

## Common Issues

<AccordionGroup>
  <Accordion title="The connector shows a 'tunneling configuration' timeout or restarts repeatedly.">
    **Symptom:** The Connector container logs show `ConnectTimeoutException: connection timed out cloud.cdata.com:443` and the container restarts in a loop. The Connector never reaches **Success** status in Connect AI.

    **Step 1: Test host egress (independent of Docker)**

    Run the following on the host:

    ```bash theme={null}
    curl -v https://cloud.cdata.com/api
    ```

    If the TLS handshake completes and you receive any HTTP response (for example, a 404), host egress is healthy and the issue is container-level, not your corporate firewall.

    **Step 2: Check IP forwarding**

    If the host can reach `cloud.cdata.com` but the container cannot, verify IP forwarding on the host:

    ```bash theme={null}
    sysctl net.ipv4.ip_forward
    ```

    If this returns `0`, the host cannot route the container's outbound traffic to the internet. Docker requires IP forwarding to be enabled. Enable it:

    ```bash theme={null}
    sudo sysctl -w net.ipv4.ip_forward=1
    ```

    The Connector reconnects on its next retry. No rebuild or image re-pull is needed, and the local image and configuration are unaffected.
  </Accordion>

  <Accordion title="Issues keeping the Connector connected across reboots, patches, and hardening.">
    `net.ipv4.ip_forward` is commonly reset to `0` by OS reboots, patch cycles, and security-hardening baselines. Apply the level of persistence your environment requires.

    **Survives a reboot:** Add a persistent sysctl setting:

    ```bash wrap theme={null}
    echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-ip-forward.conf
    sudo sysctl --system
    ```

    **Survives patching and security hardening (CIS / DISA STIG environments):** Many hardened images (for example, corporate RHEL builds) disable IP forwarding as a standard security control and re-apply that control on every patch or configuration-management run. In these environments, the sysctl file above might be overridden. To prevent recurrence, the team that owns the hardening baseline must add a host-level exception:

    * Permit `net.ipv4.ip_forward=1` on hosts running the Connector, on the basis that Docker requires IP forwarding for container connectivity.
    * If forwarding must remain globally disabled, apply a scoped forward/masquerade rule allowing only the Docker bridge subnet outbound to `cloud.cdata.com` on port 443.

    Both are narrow, deliberate exceptions and do not reduce the host's overall hardening posture.

    **To identify what is resetting the value:**

    ```bash wrap theme={null}
    grep -rns 'ip_forward' /etc/sysctl.conf /etc/sysctl.d/ /usr/lib/sysctl.d/
    ```

    A hardening file setting `net.ipv4.ip_forward = 0` with a load order after `99-ip-forward.conf` is the line the exception must override.
  </Accordion>

  <Accordion title="The Connector connects then disconnects repeatedly / SSL handshake failure.">
    **Symptom:** The Connector container logs show repeated entries like:

    ```
    SSLHandshakeException: Abruptly closed by peer
    java.io.IOException: Broken pipe
    Failed to open Azure Relay listener
    Scheduling reconnect in 5 seconds...
    ```

    The Connector might show **Success** in Connect AI intermittently, but connections fail with `HTTP [40005] Invalid HTTP response ... Action impossible while not connected`.

    **Cause:** SSL/TLS inspection on your egress firewall or proxy is intercepting and terminating the Connector's outbound WebSocket connection to Azure Service Bus. The Connector expects to complete a TLS handshake directly with Microsoft's Azure infrastructure; when an inspection appliance presents its own certificate instead, the handshake fails.

    **Fix:** Request a TLS inspection bypass from your network/security team for the following hostnames:

    * `*.servicebus.windows.net`–Azure Service Bus (Connector relay tunnel)
    * `*.azurecr.io`–Azure Container Registry (Connector image pull)
    * `*.cdata.com`–CData cloud infrastructure

    These are Microsoft Azure and CData infrastructure endpoints. Bypassing TLS inspection for these hosts does not reduce overall security posture; it allows the Connector to complete its intended encrypted connection directly with the service endpoint.

    **Alternative:** If a full TLS bypass is not permitted, your network team can export the internal CA certificate used by the inspection appliance and add it to the Connector container's Java trust store. This allows the Connector to trust the intercepted certificate and complete the handshake. Contact [CData Support](https://www.cdata.com/support/submit.aspx) for guidance on this approach.
  </Accordion>
</AccordionGroup>

## Additional Help

For additional help, contact [CData Support](https://www.cdata.com/support/submit.aspx).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.