OpenClaw Network Isolation

1. Why Network Isolation Matters

Unlike a read-only chatbot, OpenClaw can execute tasks: run shell commands, read and write files, send emails, and call APIs. If an attacker can reach the gateway, they can potentially:

• Send commands to your agent and abuse your LLM and messaging accounts
• Trigger skills that leak or exfiltrate credentials
• Use the agent to pivot into other systems on your network

Security researchers (including Cisco, CrowdStrike, and Snyk) have highlighted risks around exposed gateways and the skills marketplace. Keeping the gateway off the public internet is one of the highest-impact steps you can take. See Security Overview for the full threat model.

2. The Golden Rule: Bind to Localhost Only

In your OpenClaw configuration, set the gateway bind address to 127.0.0.1 (localhost). This ensures the gateway listens only on the loopback interface and is not reachable from other machines or the internet. If your config uses a host/port section for the gateway, set the host to 127.0.0.1 or localhost. Consult the official documentation for the exact key names in your version.

If you need remote access: Do not bind to 0.0.0.0. Instead, keep the gateway on localhost and use one of the methods below (Tailscale, SSH tunnel, or VPN) so that only you-or trusted devices-can reach it.

3. Firewall Configuration (UFW on Linux)

Even with the gateway bound to localhost, a host firewall adds defense in depth. On Ubuntu and other Linux systems, UFW (Uncomplicated Firewall) is a common choice. The goal: allow SSH (and any required outbound traffic), and ensure the gateway port is not accessible from the public internet.

Basic UFW Setup

• Allow SSH so you don’t lock yourself out: ufw allow ssh (or ufw allow 22/tcp)
• Default policy: ufw default deny incoming and ufw default allow outgoing
• Do not allow the OpenClaw gateway port (e.g. 8080 or the port you use) from the public interface. If the gateway is bound to 127.0.0.1, it won’t be listening on the public interface anyway; the firewall is an extra safeguard.
• Enable UFW: ufw enable

# Example: allow SSH, then enable
sudo ufw allow ssh
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status

If you run other services (e.g. a web server), allow only the ports they need. Never open the OpenClaw gateway port to the internet (ufw allow 8080 from anywhere is unsafe). For more host hardening, see Security Best Practices.

4. Remote Access: Tailscale (Recommended)

Tailscale creates a secure mesh VPN (a “tailnet”) so you can reach your OpenClaw host from your laptop or phone without opening ports. The gateway stays bound to localhost; you access the host over Tailscale and then connect to localhost on that host (or bind the gateway to the Tailscale interface if you need CLI/agents on other machines in the tailnet).

Typical workflow

1. Install Tailscale on the machine running OpenClaw and on the devices you use for access.
2. Authenticate both to the same tailnet (e.g. same account or shared ACLs).
3. From your laptop, SSH to the OpenClaw host using its Tailscale IP (e.g. ssh user@100.x.x.x).
4. Use SSH local port forwarding to reach the gateway: ssh -L 8080:127.0.0.1:8080 user@100.x.x.x. Then open http://127.0.0.1:8080 (or the port you use) on your local machine.

Alternatively, if your OpenClaw config supports binding to a specific interface, you can bind the gateway to the Tailscale interface (e.g. 100.x.x.x) so that only devices on the tailnet can connect. Restrict access via Tailscale ACLs if needed. For full Tailscale setup and ACLs, see the Tailscale documentation.

5. Remote Access: SSH Tunneling

If you don’t use Tailscale, SSH port forwarding is a simple way to reach the gateway from your laptop without exposing it to the internet.

1. Ensure the OpenClaw gateway is bound to 127.0.0.1 on the server.
2. From your local machine: ssh -L 8080:127.0.0.1:8080 user@your-server (replace 8080 with your gateway port and your-server with the hostname or IP you use for SSH).
3. Open http://127.0.0.1:8080 in your browser on the local machine. Traffic goes over the SSH connection to the server’s localhost.

This requires SSH access to the host (key-based auth is recommended). No gateway port is exposed to the internet. For persistent access from multiple devices, Tailscale or another VPN is often more convenient.

6. Docker Network Isolation

If you run OpenClaw in Docker, use a dedicated bridge network and avoid publishing the gateway port to the host unless necessary. When the gateway port is not published, only containers on the same Docker network (or the host via internal networking) can reach it-reducing exposure.

• Create a dedicated network: docker network create openclaw-net
• Attach the OpenClaw container to this network. Do not use ports: to expose the gateway to the host unless you have a specific need (e.g. you run the CLI on the host and need to talk to the gateway). If you do expose it, bind to 127.0.0.1 only, e.g. 127.0.0.1:8080:8080.
• Other services (e.g. a reverse proxy or monitoring container) that need to reach OpenClaw can be placed on the same openclaw-net and use the container name as hostname. The gateway does not need to be on the host’s public interface.

For full container hardening (volumes, no docker.sock, resource limits), see Docker Hardening.

7. Quick Reference & Checklist

• Gateway bound to 127.0.0.1 (or private/VPN IP) - never 0.0.0.0
• UFW (or equivalent) enabled: allow SSH, deny incoming to gateway port from public
• Remote access via Tailscale or SSH tunneling only - no open gateway port on the internet
• Docker: dedicated network; do not publish gateway port to host unless needed, and then only to 127.0.0.1

For a full post-install list, use the Security Checklist. For credential safety and skills audit, see Credential Management and Skills Security.

8. Common Issues & Solutions

Need more help? See the Troubleshooting Guide and the Discord community.

9. Related Resources

10. Next Steps

After securing network access, consider:

• Credential and API key management
• Auditing ClawHub skills before installing
• Enabling audit logs and monitoring
• Running the full Security Checklist