Skip to content

Gateway logs show "cloud unreachable"

Gateway logs show “cloud unreachable”

The gateway is powered on, has a network link, and logs roll past — but every 30 seconds or so a new error appears saying the cloud cannot be reached. Cameras behind this gateway all show Offline in the web UI. This page is for installers on-site with SSH on the gateway.

Symptom

In journalctl -u novavms-gateway, recurring entries like:

cloud unreachable, retrying in 30s

Plus the Gateways page in the cloud shows this gateway as Offline, and every camera attached to it is cascaded Offline.

The gateway connects to the cloud over HTTPS (WebSocket + REST) and retries on failure. Heartbeats flow over that socket. The exact port is set by your deployment’s cloud_url — typically 443 in production, 8080 on a local Docker Compose stack. If any hop on the outbound path to the cloud fails, the gateway records “cloud unreachable” and backs off before retrying.

Likely causes

  1. DNS resolution fails. The gateway’s configured resolver cannot resolve the cloud hostname (for example novavms.novalien.com).
  2. Outbound 443 blocked by firewall or NAT. Corporate networks sometimes egress-filter unknown destinations. Guest VLANs are the common offenders.
  3. mTLS certificate expired or mismatched. If the deployment uses mTLS between gateway and cloud, an expired client cert causes every WebSocket handshake to fail.
  4. Tailscale (or other overlay) is down. If the gateway reaches the cloud over a Tailscale tailnet, the tailnet itself must be up.

Fixes

If DNS resolution is failing

SSH to the gateway. Run:

Terminal window
dig +short novavms.novalien.com
# Replace with your actual cloud hostname if different

Empty response or SERVFAIL means the resolver is broken. Fixes:

  • Point the gateway at a public resolver in its network config: 1.1.1.1, 8.8.8.8.
  • Restart the systemd-resolved service if the gateway uses it.

If outbound 443 is blocked

From the gateway, try:

Terminal window
curl -I https://novavms.novalien.com
# Replace with your actual cloud hostname

Expected: HTTP response headers (200, 301, etc.). Failure modes:

  • Could not resolve host — DNS issue, see above.
  • Hang with no response — 443 egress is blocked. Ask the site’s network owner to allow outbound 443 to the cloud host for the gateway’s source IP.
  • TLS handshake error — either the cloud is down or a proxy is intercepting TLS. Bypass the proxy if one is configured on the gateway.

If your deployment uses mTLS

mTLS between the gateway and cloud is optional and not used by the default HostHatch or Pi deployments. If your deployment enables it:

  • Confirm the client certificate at the path your deployment uses (consult your ops runbook).
  • Check cert expiry: openssl x509 -in <cert-path> -noout -enddate.
  • If the cert is near expiry, rotate before connectivity fails.

If Tailscale is down

Terminal window
tailscale status

If the tailnet is not healthy, restart: sudo systemctl restart tailscaled. Check that the gateway’s node is still authorised in the Tailscale admin console.

Verify the fix

  1. Watch journalctl -u novavms-gateway -f for 60 seconds — no more cloud unreachable lines.
  2. The Gateways page in the cloud shows this gateway green within 30 seconds.
  3. Cameras behind the gateway transition from Offline back to Online within a minute.
  4. The gateway’s heartbeat counter on the detail page increments.

Still stuck?