Community Solution

Fix ZVM Remote Access Through Tunnels

A ZimaOS user could use ZVM on the LAN but not through DDNS or Cloudflare Tunnel; replies discussed secondary console traffic, WireGuard, port 5700, and TCP passthrough.

Why ZVM Can Work on LAN but Fail Through a Tunnel

ZVM Windows virtual machine console working normally over the local network
Community screenshot showing the ZVM Windows console rendering normally when accessed over the local network.
ZVM remote console failing to render through DDNS or Cloudflare Tunnel
Community screenshot showing the contrasting remote-access failure: the ZVM console remains blank while browser developer tools report connection errors.

The community case showed a ZVM virtual machine that displayed correctly over the local network but not through DDNS or a Cloudflare Tunnel. The thread suspected that the ZVM console depends on additional traffic beyond the initial web page. Later replies mentioned WireGuard and TCP passthrough on port 5700, but the thread does not establish one universal fix for every ZimaOS version.

For current remote-access architecture, start with the current Zima Client connectivity page and Zima Client remote-access guide before adding a public tunnel.

DDNS and Cloudflare Tunnel Solve Different Layers

DDNS only maps a hostname to an IP address. Cloudflare Tunnel proxies supported application protocols through cloudflared. Neither automatically understands every multi-port or interactive console protocol used by a VM management interface.

Cloudflare's current protocol documentation states that TCP services are streamed over WebSocket for published applications and require client-side cloudflared for non-HTTP access. See Cloudflare Tunnel protocol documentation and the current Cloudflare Tunnel FAQ.

Diagnose the ZVM Path Before Changing Ports

  1. Confirm ZVM works fully from the LAN.
  2. Open browser developer tools and identify failed WebSocket or secondary requests when using the tunnel.
  3. Compare destination hostnames and ports between the working LAN session and remote session.
  4. Do not assume port 5700 is sufficient unless the current ZVM build actually uses it for your console path.
  5. Test a private-network approach such as ZimaClient, WireGuard or another supported overlay to see whether the full private service works without protocol translation.

When TCP Passthrough May Help

A community reply suggested NGINX Stream TCP passthrough for port 5700. Treat that as a community workaround, not an official ZVM networking contract. It can be useful only if you have verified that the needed console traffic is plain TCP on that port and your authentication boundary remains secure.

Security Boundary

Publishing a VM console is more sensitive than publishing a static web page. Prefer a private network for administrative interfaces, require authentication at every layer, and avoid exposing management ports directly to the public internet.

The current official ZimaOS remote access documentation describes built-in and standard-protocol remote access options.

FAQ

Why does the VM start even though the console does not display?

The management request and the interactive console transport can use different requests or channels. The VM process can start successfully while the browser fails to establish the display path.

Will port forwarding 5700 always fix ZVM?

No. The community thread includes an unsuccessful 5700-forwarding attempt, so verify the current traffic instead of assuming one fixed port.

Is DDNS enough for remote ZVM?

No. DDNS only provides name resolution; you still need a secure and protocol-compatible path to the VM console.