Security

What evidence is enough to prove an OpenClaw Gateway is not accidentally public?

June 22, 202612 min readUpdated September 13, 2026By OpenClawBlog Team

Published June 22, 2026 · OpenClawBlog Team. Sources rechecked September 13, 2026.

A Gateway can look local in a configuration file and still be reachable from the internet. A reverse proxy may publish a loopback service. Docker may publish a container port while the host firewall looks quiet. Tailscale may still own a route after an OpenClaw setting changes. A successful health check can even come from the wrong process.

The useful question is therefore narrower than “is the Gateway secure?” It is: what observations are strong enough to support the claim that this Gateway is not accidentally public?

This article separates documented OpenClaw behavior from proposed operator tests. It does not claim that a live Gateway was tested here.

Define the exposure claim first

“Not public” is not the same as “requires a token.” Authentication controls what happens after a request reaches an application. Public exposure describes whether an outside client can reach a route, port, proxy, tunnel, or published container at all.

Write the intended boundary before running commands:

Intended boundary	What should be reachable	What should not be reachable
Local only	Loopback clients on the Gateway host	LAN, tailnet, and internet clients
Private remote	A named LAN, tailnet, SSH tunnel, or Tailscale Serve path	Unplanned public routes and direct origin access
Public proxy	An intentional public URL protected by the chosen identity layer	The Gateway origin, published port, or proxy bypass

These are different decisions. A private remote deployment can be reachable from another device and still meet its contract. A public proxy can be intentionally internet-facing, but its direct Gateway port should remain outside that public path. If the requirement is local only, a 401 or 403 from a public address is evidence of public reachability, not evidence of success.

What the OpenClaw documentation establishes

The current network exposure reference describes a Gateway that multiplexes WebSocket and HTTP traffic on one port, normally 18789. That surface includes the Control UI, HTTP APIs, hooks, and hosted canvas or A2UI content. Checking only whether a web page loads is too narrow; the port and every route in front of it matter.

The same reference documents loopback as the normal bind. LAN, tailnet, and custom binds expand the attack surface and need Gateway authentication plus a real firewall. Container behavior deserves separate attention: the effective automatic bind can resolve to 0.0.0.0 for port forwarding. A configuration that looks like a local installation is not enough to establish a local network boundary.

OpenClaw's Gateway exposure runbook advises using the narrowest access pattern that meets the workflow and avoiding direct public port forwarding. It also asks operators to record the host, state directory, bind mode, authentication source, channels, reachable agents, tool policy, and external credentials before widening access.

The security policy adds an important limit. Authenticated callers are treated as trusted operators for that Gateway, and one Gateway is not a hostile multi-tenant boundary. A token can prove possession of the Gateway credential. It does not turn an internet-facing control plane into a private service.

Build an evidence packet

A useful audit has several independent parts. Each one answers a different question. The following is a proposed acceptance test based on the documented controls, not a result from this article.

Record the effective configuration. Save a redacted record of the profile, active config path, state directory, resolved port, bind mode, authentication mode, Tailscale mode, reverse-proxy address, and firewall source range. Keep tokens, passwords, browser sessions, and credential values out of the record.
The Gateway runbook says the active file can be selected through profile and state defaults or OPENCLAW_CONFIG_PATH. It also documents port precedence: CLI override, environment variable, configuration value, then the default port. That means a screenshot of a JSON file can describe intent while the supervisor starts a different port or profile.
Run the OpenClaw checks. The documented baseline is:
```
openclaw doctor
openclaw security audit --json
openclaw security audit --deep
openclaw health
```
The security audit guide says to run the audit after configuration changes or before exposing network surfaces. The deep form attempts a live Gateway probe. Treat a failed probe as unverified reachability or configuration, not as proof of safety.
Review the machine-readable findings. The audit check catalog includes network findings such as gateway.bind_no_auth, trusted-proxy configuration errors, and gateway.probe_failed. It also records when audit suppressions are active. A clean-looking summary with suppressed findings is not the same evidence as an unsuppressed review.
Inspect the real socket and its owner. On macOS, use an operating-system listener check such as lsof -nP -iTCP:<resolved-port> -sTCP:LISTEN. On Linux, use the equivalent ss -ltnp check. Confirm the address family, bound address, port, PID, executable, and supervisor command.
This is a proposed host test. It is not an OpenClaw result. A listener on 127.0.0.1 or ::1 supports a local-only socket claim. A listener on 0.0.0.0 or [::] indicates a broader host-level bind, subject to the operating system's IPv4 and IPv6 behavior. A port number without an address and process owner says very little.
Map the paths around the process. Check public DNS A and AAAA records, router forwarding, cloud security groups, load balancers, reverse proxies, SSH tunnels, Tailscale Serve or Funnel routes, and container publishing rules. Record the intended owner of each route.
The network reference warns that Docker-published ports travel through Docker forwarding chains rather than only the host's INPUT rules. Its guidance uses the DOCKER-USER chain and calls for a matching IPv6 policy when Docker IPv6 is enabled. A quiet host firewall therefore cannot close an accidentally published container port by itself.
Prove the allowed path. Use the exact hostname, scheme, port, and path that a real approved client will use. For a direct remote CLI check, the runbook shows an explicit Gateway probe with credentials supplied for that URL. Do not assume that local configuration credentials automatically apply to an explicit remote endpoint.
Correlate this positive result with the host identity, PID, Gateway status, and route owner. A response proves that something answered. It does not prove that the intended Gateway answered.
Prove the denied paths. Test from every network that should be refused. For a local-only contract, use an untrusted LAN device and an external network. For a tailnet-only contract, test from a non-tailnet network. For an identity-aware proxy, test both the public URL without valid identity and the direct origin address.
The exposure runbook explicitly calls for an authorized connection to succeed and an unauthorized sender or browser session to be denied after an exposure change. For a public IP you own, the network reference includes a full TCP scan example: nmap -sT -p 1-65535 <public-ip> --open. Run such scans only against infrastructure you control and are authorized to test.

Test each network edge, not just the Gateway host

Test vantage point	Expected result for a private Gateway	What the result proves
Gateway host, loopback address	Expected service responds with the intended authentication path	The local process is alive
Approved LAN or tailnet client	Only succeeds when that private route is part of the contract	The intended remote path works
Unapproved LAN or tailnet client	Connection is blocked or the intended application denial appears	The local private boundary behaves as designed
External IPv4 and IPv6 clients	No route for a private deployment; only the approved proxy route for a public-proxy deployment	The internet-facing boundary was tested from outside
Direct origin behind a proxy	Unreachable from the public network	The proxy is the only public path

A refused connection or timeout supports a closed path from that vantage point, but it is still worth repeating from more than one network. A 401 or 403 proves that an endpoint is reachable and has rejected the request. That may be the correct result for an intentional public proxy. It cannot satisfy a claim that the Gateway is not public.

A successful health response is weaker than an authenticated protocol response. The Gateway runbook distinguishes ordinary status from deeper service discovery, and the security documentation distinguishes liveness from control-plane authentication. Prefer a read-only authenticated probe that can be tied to the intended Gateway.

Special cases that create false confidence

The file says loopback, but a public URL works

Look for a reverse proxy, port forward, container publication, SSH tunnel, or stale Tailscale route before changing the bind value. Loopback describes the process listener. It does not describe every route that can reach that listener.

The audit is clean, but the port is open

The audit is valuable evidence about OpenClaw configuration and selected runtime checks. It is not an inventory of every router, cloud load balancer, Docker chain, or external tunnel. Treat the open port as a deployment failure for a private contract and close the edge first.

The proxy authenticates users, but the origin is also reachable

The trusted-proxy guidance requires narrow trusted proxy addresses and says the proxy should overwrite or safely rebuild forwarded identity headers. It also warns that loopback trust can let local processes impersonate a proxy. Check the firewall and direct-origin path, then verify that client-supplied identity headers cannot become authority.

Tailscale mode is off

The Tailscale documentation says that off means OpenClaw is not managing Serve or Funnel. It does not mean the local Tailscale daemon is stopped or that an externally configured route has disappeared. Serve keeps the Gateway on loopback for tailnet access; Funnel is public. Inspect the actual route rather than inferring it from one OpenClaw setting.

The file changed, but the service did not

The Gateway can serve an active in-memory configuration snapshot after a successful load, while an installed supervisor may retain its resolved port metadata. Recheck the running status, process arguments, active port, and service owner after any change. Do not call the new file the running state until those observations agree.

Only IPv4 was checked

Repeat DNS, firewall, listener, and external tests for IPv6. Docker's own documentation section in the network reference calls out separate IPv6 filtering rules. A private IPv4 result does not close an IPv6 route.

When is the evidence enough?

For a private deployment, I would call the decision supported only when all of these statements are true:

The intended boundary is written in one sentence.
The effective configuration and the running process show the same profile, port, bind, and authentication path.
The socket owner is the expected Gateway, and no second process owns the relevant address or port.
DNS, firewall, proxy, tunnel, container, and Tailscale routes match the written boundary.
The approved client succeeds through the exact intended path.
Disallowed clients fail from the relevant LAN, tailnet, IPv4, IPv6, and public vantage points.
The audit has no unresolved critical finding, no unexplained probe failure, and no suppression hiding a relevant result.

If the local config and audit are the only evidence, the correct status is unverified. If an unintended public route responds, the status is failed for a private deployment, even when authentication blocks the request. If a public proxy is intentional, narrow the claim: prove that the proxy is authenticated and that the Gateway origin is unreachable from the public network.

The short acceptance rule

Evidence is enough when intent, runtime, edge routing, and outside observations all describe the same boundary. A configuration line proves what someone meant to run. A socket check proves what the host opened. An external denial test checks what an unwanted client can do. The audit explains OpenClaw findings and warnings. None of those pieces can replace the others.

Keep the record dated and rerun it after changing the bind, supervisor, container ports, proxy, firewall, DNS, or Tailscale route. The safest conclusion is often the least dramatic one: the Gateway answers on the path it is supposed to use, and the paths nobody approved do not reach it.

Sources

All sources were accessed on 2026-09-13. The official documentation pages do not expose publication dates.