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 30sPlus 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
- DNS resolution fails. The gateway’s configured resolver cannot resolve the cloud hostname (for example
novavms.novalien.com). - Outbound 443 blocked by firewall or NAT. Corporate networks sometimes egress-filter unknown destinations. Guest VLANs are the common offenders.
- mTLS certificate expired or mismatched. If the deployment uses mTLS between gateway and cloud, an expired client cert causes every WebSocket handshake to fail.
- 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:
dig +short novavms.novalien.com# Replace with your actual cloud hostname if differentEmpty 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:
curl -I https://novavms.novalien.com# Replace with your actual cloud hostnameExpected: 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
tailscale statusIf 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
- Watch
journalctl -u novavms-gateway -ffor 60 seconds — no morecloud unreachablelines. - The Gateways page in the cloud shows this gateway green within 30 seconds.
- Cameras behind the gateway transition from Offline back to Online within a minute.
- The gateway’s heartbeat counter on the detail page increments.
Still stuck?
- Gateway shows “Offline” — for the wider case where the gateway process itself is down
- Ports and protocols reference — every port NovaVMS opens, inbound and outbound
- Gateway network requirements — what to tell the site’s network owner to allow