Skip to main content

​
Common Issues

Symptom: The Gateway container logs show ConnectTimeoutException: connection timed out...cloud.cdata.com:443 and the container restarts in a loop. The Gateway 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 Gateway 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 Connect Gateway, 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 Gateway container logs show repeated entries like:
The Gateway 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 Gateway’s outbound WebSocket connection to Azure Service Bus. The Gateway 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 (Gateway relay tunnel)
  • *.azurecr.io–Azure Container Registry (Gateway 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 Gateway 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 Gateway container’s Java trust store. This allows the Gateway 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.