Skip to main content

​
Common Issues

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:
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 forwardingIf the host can reach cloud.cdata.com but the container cannot, verify IP forwarding on the host:
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:
The Connector reconnects on its next retry. No rebuild or image re-pull is needed, and the local image and configuration are unaffected.
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:
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:
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.
Symptom: The Connector container logs show repeated entries like:
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 for guidance on this approach.

​
Additional Help

For additional help, contact CData Support.
Last modified on October 2, 2026