Network Isolation for OpenClaw: Tailscale, SSH Tunnels, and Zero Public Ports

Picture this: You’ve got OpenClaw running, it’s configured perfectly, skills are vetted, permissions are locked down. Everything’s solid, right? Then some kid finds your dashboard exposed on port 18789 with a default password. Game over.

Network isolation is the foundational layer of security. It doesn’t matter how bulletproof your application is if someone can just connect to it from the internet with a port scan. The architecture principle is brutally simple: your OpenClaw instance should never listen on a public IP. This isn’t being paranoid. This is recognizing that the public internet is a hostile environment where automated attackers scan for vulnerable services 24/7, and your job is to make your OpenClaw instance impossible to find.

This guide walks through three complementary strategies: Tailscale mesh VPN for zero-trust access, SSH tunnels for dashboard access, and why you should never, ever bind to 0.0.0.0. But before we get there, let’s talk about why this matters and what happens when you get it wrong.

Understanding the Threat Model

Before implementing defenses, you need to understand what you’re actually defending against. When your OpenClaw instance listens on a public port, you’re exposed to several distinct attack vectors, each with different consequences and different likelihood. Understanding these helps you appreciate why the defenses matter.

Passive reconnaissance attacks start the moment your service is reachable. Automated scanners continuously probe the entire IPv4 address space looking for open ports. Every cloud provider’s IP block is scanned thousands of times per day by threat intelligence operations, botnets gathering service information, security researchers mapping the global attack surface, and attackers looking for vulnerable services to exploit. Your service doesn’t need to be famous or targeted—it just needs to exist and be reachable. Shodan, Censys, and similar services catalog exposed services automatically. You could literally search “port:18789” and find OpenClaw instances that shouldn’t be exposed.

Credential guessing is the next layer. Once someone finds your service, they’ll try default credentials, common password combinations, and credentials from previous data breaches. If your OpenClaw dashboard accepts HTTP Basic Auth or uses default credentials, you’ll be compromised before you even know it was found. Attackers have credential databases with millions of username/password combinations from previous breaches. They automate testing these credentials against every exposed service. It’s not sophisticated—it’s just tedious, repetitive work that gets automated.

Vulnerability exploitation is the third vector. Every software has bugs. OpenClaw, its dependencies, the underlying libraries—all potentially exploitable. A zero-day vulnerability in a popular package hits thousands of systems simultaneously. Attackers don’t need to be sophisticated; they just need to run existing exploits against every IP that responds. Tools like Metasploit automate this. A vulnerability gets discovered, it gets added to an exploit tool, and within hours, millions of systems get scanned and attempted exploitation.

Supply chain attacks happen when a trusted dependency gets compromised. An attacker modifies a legitimate package, publishes it, and systems that pull updates automatically get the malicious code. A public-facing application is ground zero for this kind of attack because attackers know the code will be executed immediately and continuously.

Data exfiltration is the goal. Whether through vulnerability, credential theft, or supply chain compromise, the end game is accessing your data. If OpenClaw has access to sensitive information, credentials, API keys, or customer data, a compromised instance means all of that is at risk. The longer your OpenClaw runs exposed, the more likely it is that one of these attack vectors will work.

The beauty of network isolation is that it prevents the entire attack chain from starting. If someone can’t reach your OpenClaw instance from the internet, they can’t scan it, can’t guess credentials, can’t exploit vulnerabilities, and can’t exfiltrate data. Network isolation doesn’t make OpenClaw invulnerable—nothing is—but it makes attacking it orders of magnitude harder. You move from “constantly under automated attack” to “someone would need to target you specifically and have internal access to your network.” That’s a way different threat model.

The Zero Public Ports Principle

Let’s establish the baseline: your OpenClaw instance should have exactly zero listening ports exposed to the public internet. Not one. Not with authentication, not with IP whitelisting, not “just temporarily.” Zero.

This means:

• Dashboard (:18789) listens only on 127.0.0.1 (localhost)
• API endpoints (if exposed) listen only on 127.0.0.1 or private network IPs
• SSH for remote access is on the system itself, not exposed via OpenClaw
• All access is mediated through explicit tunnels or VPN
• Metrics endpoints, debug ports, and status pages are never public

The architecture looks like this:

Internet
  ↓
[Firewall: All ports dropped]
  ↓
[Your Network/VPN Client]
  ↓
[Tailscale or SSH Tunnel]
  ↓
[OpenClaw: Listening on localhost only]

Someone on the public internet sees your IP and runs nmap? They get zero open ports. Zero information. Perfect.

Think about what this means for your security posture. An attacker’s reconnaissance phase completely fails. They can’t fingerprint your service, they can’t identify the version of OpenClaw you’re running, they can’t detect configuration issues by probing endpoints. They can’t even confirm that the IP belongs to a service at all—from the outside, it looks like just another idle server. This is the principle of “security through obscurity” done right. Traditional security folks dismiss security through obscurity as insufficient because it’s true—obscurity alone isn’t enough. But obscurity combined with proper access controls becomes a powerful force multiplier. A hidden service is an unexploitable service.

Strategy 1: Tailscale Mesh VPN (The Modern Approach)

Tailscale is a zero-configuration VPN that gives you a mesh network—every device on your “tailnet” can talk to every other device securely, with automatic encryption and hole-punching for NAT traversal. No port forwarding, no public IP exposure, no complexity. It’s the simplest modern approach to network isolation, and it works better than you’d expect.

Why Tailscale Matters

The traditional VPN model requires a central server that everyone connects to. That server becomes a bottleneck and a single point of failure. If your VPN server goes down, nobody can access anything. Tailscale uses WireGuard to create a mesh network where devices connect peer-to-peer whenever possible. When peer-to-peer isn’t possible (NAT, firewalls), Tailscale’s coordination servers help establish connections through those barriers without ever having access to the actual traffic.

Let’s break down the advantages, because they’re genuinely compelling:

Zero configuration means you don’t have to understand VPN protocols, certificate authorities, or PKI. Install Tailscale, authenticate once, and you’re connected. The software handles the complex parts—hole punching, NAT traversal, endpoint discovery, key rotation. You just use it.

Encrypted by default is non-negotiable. All Tailscale traffic uses WireGuard encryption, which is modern, audited, and performant. You don’t have to configure TLS, manage certificates, or negotiate cipher suites. It just works.

Access control at the Tailscale layer means you can define policies about who can access what. This is enforced before traffic even reaches OpenClaw, giving you another security boundary.

Works through NAT and restrictive firewalls because Tailscale handles hole-punching automatically. Your OpenClaw server can be behind a CGnat ISP connection, a residential router, or a corporate firewall, and it’ll still be accessible to authorized users.

Automatic certificate management for HTTPS access. When you access OpenClaw via Tailscale DNS names like openclaw-server.tailscale.com, Tailscale automatically provides valid TLS certificates. No self-signed certificate warnings, no certificate rotation management.

Installation and Setup

First, install Tailscale on the machine running OpenClaw:

# On Ubuntu/Debian
curl -fsSL https://tailscale.com/install.sh | sh

# On macOS
brew install tailscale

# On other systems, visit https://tailscale.com/download

Now authenticate and join your tailnet:

sudo tailscale up

When you run tailscale up, you’ll get a login URL. Visit it, authenticate with your Tailscale account, and you’re part of the tailnet. If you don’t have a Tailscale account, the URL will prompt you to create one. It’s free for personal use (up to 100 devices on the free tier, which is more than enough for personal OpenClaw setups).

Verify you have a Tailscale IP:

tailscale ip -4
# Output: 100.x.x.x

That 100.x.x.x address is your node’s address within the Tailscale network. It’s routable only within your tailnet, not on the public internet. Every device on your tailnet has a unique address in that range. Think of it as a private IP address that works globally—you can access it from anywhere as long as you’re authenticated to the tailnet.

Binding OpenClaw to Tailscale

Now configure OpenClaw to listen on its Tailscale IP instead of localhost. This makes it accessible to other devices on your tailnet while keeping it off the public internet.

First, get the Tailscale IP:

TAILSCALE_IP=$(tailscale ip -4)
echo $TAILSCALE_IP

Then configure OpenClaw. If you’re using a YAML config:

server:
  host: 100.x.x.x # Your Tailscale IP
  port: 18789
  tls:
    enabled: true
    cert: /etc/openclaw/certs/server.crt
    key: /etc/openclaw/certs/server.key

If you’re using environment variables or command-line flags, set the bind address accordingly. The key is binding to the Tailscale IP, not 0.0.0.0.

Restart OpenClaw:

sudo systemctl restart openclaw

Verify it’s listening on the Tailscale IP:

sudo netstat -tulpn | grep 18789
# tcp   0  0 100.x.x.x:18789   0.0.0.0:0   LISTEN   1234/openclaw

That output is perfect. The service is listening on 100.x.x.x:18789, which is accessible only within the Tailscale network. Even if someone somehow got your server’s public IP and scanned it, port 18789 would show as closed—the traffic just doesn’t route from the public internet.

Now, from your local machine, join the same tailnet:

tailscale up

Once authenticated, verify you can reach the OpenClaw server:

ping 100.x.x.x
# PING 100.x.x.x (100.x.x.x): 56 data bytes
# 64 bytes from 100.x.x.x: icmp_seq=0 ttl=64 time=15ms

Now access the dashboard. Tailscale automatically sets up DNS, so you can use the hostname:

# Option 1: Use the Tailscale DNS name
open https://openclaw-server.tailscale.com:18789

# Option 2: Use the IP directly
open https://100.x.x.x:18789

You’re now accessing OpenClaw through an encrypted Tailscale tunnel. Someone on the public internet can’t touch it. Even if they could somehow find your server’s public IP, it has no open ports for them to connect through. Perfect isolation.

Tailscale Access Control Policies

Tailscale gives you granular access control beyond just network connectivity. Even if someone’s on your tailnet, you can restrict who accesses what. This is zero-trust in practice—you verify identity at multiple layers.

In your Tailscale admin console (accessible at https://login.tailscale.com), you can write ACL policies. Here’s a practical example:

{
  "acls":
    [
      {
        "action": "accept",
        "src": ["autogroup:self"],
        "dst": ["tag:openclaw:*"],
      },
      { "action": "accept", "src": ["group:team"], "dst": ["tag:openclaw:*"] },
      {
        "action": "accept",
        "src": ["autogroup:self"],
        "dst": ["tag:databases:*"],
      },
    ],
}

This policy means:

• Your user can access all devices tagged openclaw
• Members of the team group can access openclaw devices
• Your user can access databases
• Everyone else? Denied.

Tag your OpenClaw device as tag:openclaw in the Tailscale console, and these policies are enforced at the VPN layer. Even if someone’s on your tailnet, they can’t reach OpenClaw unless the policy allows it. This gives you incredibly fine-grained control over who can access what.

Tailscale Serve (Optional: Exposing to Non-Tailnet Users)

Sometimes you need to expose something to people not on your tailnet—contractors, customers, partners. Tailscale Serve lets you do this safely without exposing your network. The concept is elegant: Tailscale hosts a public endpoint on their infrastructure, and when someone accesses it, Tailscale routes the traffic through your tailnet to the local service. The actual OpenClaw server still listens only on 127.0.0.1 or the Tailscale IP; it never touches the public internet.

# Expose the OpenClaw dashboard via Tailscale's CDN
sudo tailscale serve https / localhost:18789

This creates a shareable link like https://openclaw-instance.tsc.fyi/ that’s accessible from the public internet. Behind the scenes:

• The actual OpenClaw server still listens only on localhost
• All requests go through Tailscale’s infrastructure
• Requests are authenticated and logged
• The link is temporary and can be revoked instantly
• Rate limiting and DDoS protection are built-in

Use this for temporary access only, and always with an authentication layer in front. Tailscale Serve is a fantastic tool for demos, one-off customer onboarding, or temporary contractor access, but not for permanent public exposure. You retain full control—disable it anytime.

Monitoring Tailscale Connections

Keep an eye on who’s accessing your OpenClaw instance. This is basic operational security:

# See active peers on your tailnet
tailscale status

# Check Tailscale network health
tailscale netcheck

In the Tailscale admin console, you can see detailed logs of all connections, bandwidth usage per peer, and alerts for suspicious activity. Set up alerts so you know if someone’s accessing your OpenClaw instance when they shouldn’t be.

Strategy 2: SSH Tunneling (The Explicit Approach)

If you want more control, can’t use Tailscale (perhaps due to corporate restrictions or privacy concerns), or prefer a more explicit, traditional approach, SSH tunneling is the classic fallback. It’s simpler in some ways and more explicit about what you’re doing. SSH is also available on basically every server you’ll ever work with, making it incredibly reliable.

SSH Port Forwarding Fundamentals

SSH port forwarding is a powerful feature that creates encrypted tunnels through SSH connections. The idea is simple: establish an SSH connection to your server, then tunnel traffic through that connection to localhost.

# Local port forward: Access OpenClaw dashboard from your local machine
ssh -L 18789:localhost:18789 [email protected]

When you run this command:

1. SSH connects to your-server.com as user user
2. SSH listens on your local machine’s port 18789
3. Any traffic you send to localhost:18789 is encrypted, sent to the remote server, and forwarded to localhost:18789 on the remote side
4. The response comes back encrypted through the SSH tunnel

Now you can visit https://automateanddeploy.com:18789 in your browser, and the traffic is encrypted and tunneled to the remote OpenClaw instance. This is genuine encryption—even if someone sniffs your network traffic, they just see encrypted SSH data, not your OpenClaw dashboard.

Let’s break down the SSH command:

• -L 18789:localhost:18789 means “Local port forward: listen on local port 18789, forward to remote localhost:18789”
• -N (used in production) means “don’t execute a remote shell command, just do the tunnel”
• [email protected] is the SSH server

The beauty is that it works even if OpenClaw is behind a firewall, behind NAT, or on a restricted network. As long as you can SSH to the server, you can tunnel through it. This makes SSH tunneling incredibly reliable for remote work scenarios.

Hardening SSH for OpenClaw Access

For security, create a dedicated SSH user with severely restricted capabilities. This user exists only for port forwarding, not for interactive access. If someone compromises this account, they can only do one thing: forward port 18789.

# Create a restricted user for tunnel access only
sudo useradd -r -s /usr/sbin/nologin -d /nonexistent openclaw-tunnel

This user:

• Has no shell (/usr/sbin/nologin)
• Has no home directory (/nonexistent)
• Is a system user (-r)
• Cannot log in interactively
• Cannot do anything except what the SSH configuration explicitly allows

Now set up SSH key authentication. On your local machine, generate a key pair:

ssh-keygen -t ed25519 -f ~/.ssh/openclaw-tunnel -C "openclaw-tunnel"

You’ll be prompted for a passphrase. For automated tunnels, use no passphrase. For manual use, add a passphrase for security.

Add the public key to the server’s authorized_keys:

# Copy the key to the server (you'll do this once)
ssh-copy-id -i ~/.ssh/openclaw-tunnel [email protected]

# Then manually add restrictions to the key
sudo nano /home/openclaw-tunnel/.ssh/authorized_keys

Edit the authorized_keys file to add restrictions. Find the key line and prepend these options:

no-X11-forwarding,no-agent-forwarding,no-pty,permitopen="localhost:18789" ssh-ed25519 AAAA...

What do these options do?

• no-X11-forwarding: Prevents X11 graphical protocol forwarding
• no-agent-forwarding: Prevents SSH agent forwarding
• no-pty: Prevents pseudo-terminal allocation
• permitopen="localhost:18789": Restricts port forwarding to only localhost:18789

That last option is critical. Even if someone steals the private key, they can only forward to localhost:18789. They can’t forward to other ports, other machines, or anywhere else. They’re locked down to exactly what OpenClaw needs.

Set correct permissions:

sudo chmod 600 /home/openclaw-tunnel/.ssh/authorized_keys
sudo chown openclaw-tunnel:openclaw-tunnel /home/openclaw-tunnel/.ssh/authorized_keys

Setting Up the SSH Tunnel

Now create a helper script to manage the tunnel connection:

#!/bin/bash
# openclaw-tunnel.sh

SSH_KEY=~/.ssh/openclaw-tunnel
REMOTE_HOST=your-server.com
REMOTE_USER=openclaw-tunnel
LOCAL_PORT=18789

# The -N flag means "don't execute a shell, just do the tunnel"
# The -f flag means "go to background after authentication"
ssh -N -L ${LOCAL_PORT}:localhost:${LOCAL_PORT} \
    -i ${SSH_KEY} \
    ${REMOTE_USER}@${REMOTE_HOST}

You can run this manually when you need access:

./openclaw-tunnel.sh &

Or better, integrate it into your system so the tunnel persists. Create a systemd service:

sudo tee /etc/systemd/system/openclaw-tunnel.service > /dev/null <<EOF
[Unit]
Description=OpenClaw SSH Tunnel
After=network.target

[Service]
Type=simple
User=$USER
ExecStart=/home/$USER/openclaw-tunnel.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

Enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable openclaw-tunnel
sudo systemctl start openclaw-tunnel

Now the tunnel automatically establishes on boot and persists if it drops. Check status:

sudo systemctl status openclaw-tunnel
ps aux | grep ssh

Remote Port Forwarding (Reverse Tunnel)

Sometimes you need to expose a service from one machine through another machine to a third machine. This is where reverse port forwarding comes in. For example, if you’re developing on a laptop but want to test through a bastion host:

# On the server with OpenClaw, connect back to a bastion host
ssh -R 18789:localhost:18789 [email protected]

This creates a reverse tunnel: the remote bastion host can now access localhost:18789 of the OpenClaw server.

From bastion, you’d then do:

ssh -L 18789:localhost:18789 [email protected]

This is more complex and requires careful setup, but it’s invaluable for highly restricted environments where outbound connections are limited. Most people won’t need this, but knowing it exists can save you in edge cases.

The Real Cost of Network Isolation Failures

Before we cover the last strategy, let’s talk about what happens when isolation breaks. This isn’t theoretical. Every month, I see teams who “just temporarily” exposed their OpenClaw instance to the public internet while “testing something,” then forgot about it. The results are predictable and grim.

A popular scenario: a team spins up OpenClaw on AWS, configures it on 0.0.0.0:18789, intends to test with a colleague for one hour. They never change it. Two weeks later, automated scanners find it. Default credentials get guessed. An attacker has full access to the OpenClaw instance, which has API keys for their internal services. Those keys get exfiltrated. The attacker uses them to access production databases. Data breach. The team scrambles to notify customers, rotate credentials, and figure out how long the attacker had access.

The attack timeline is measured in hours from discovery to full compromise. The teams tell themselves “we had authentication,” but authentication is useless against vulnerability exploitation, not credential guessing. Network isolation isn’t paranoid—it’s acknowledging that the public internet is not a safe place to test things.

The solution isn’t better passwords or more secure auth. The solution is: never expose the port in the first place. If an attacker can’t reach your OpenClaw instance, they can’t exploit it, can’t guess credentials, can’t do anything. Network isolation is the only layer that truly works.

Strategy 3: Gateway Binding (When You Must Expose)

Sometimes you actually need to expose OpenClaw to a network—internal LAN, VPC, corporate network. In these cases, never bind to 0.0.0.0. Bind to a specific gateway IP. This limits exposure to just the networks you intend to expose to.

Why 0.0.0.0 is Dangerous

The address 0.0.0.0 is a catch-all that means “listen on all available network interfaces.” If your server has multiple network interfaces—one connected to the public internet, one to a private LAN, one to a VPN—binding to 0.0.0.0 exposes the service on all of them, including the one connected to the internet.

This is often accidental. Developers configure a service to listen on 0.0.0.0 during development for convenience, then deploy it to production without changing it. Suddenly, your internal service is world-accessible. I’ve seen this happen more times than I’d like to admit.

Binding to a Specific Network Interface

Find your network interfaces:

ip addr show

Output looks like:

1: lo: <LOOPBACK...> inet 127.0.0.1/8
2: eth0: <BROADCAST...> inet 192.168.1.100/24
3: eth1: <BROADCAST...> inet 10.0.0.50/24

You have multiple network interfaces. Maybe eth0 is connected to your private LAN and eth1 is connected to an internal corporate network. You want OpenClaw accessible only on eth0.

In your OpenClaw config, specify the exact IP:

server:
  host: 192.168.1.100 # Specific private network interface
  port: 18789
  tls:
    enabled: true

Now OpenClaw listens only on 192.168.1.100:18789. Someone on the public internet accessing your server’s public IP gets nothing. Someone on the 10.0.0.0 network gets nothing. Only devices on 192.168.1.0/24 can reach it.

Verify:

sudo netstat -tulpn | grep 18789
# tcp   0  0 192.168.1.100:18789   0.0.0.0:0   LISTEN

The output shows it’s listening on 192.168.1.100, not 0.0.0.0.

Firewall-Level Control

Even when binding to a specific interface, use firewall rules for defense in depth. Two layers of protection is better than one:

# UFW (Uncomplicated Firewall)
sudo ufw allow from 192.168.1.0/24 to any port 18789

# iptables (more powerful but more complex)
sudo iptables -A INPUT -p tcp --dport 18789 \
  -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 18789 -j DROP

# Save iptables rules
sudo apt-get install iptables-persistent
sudo netfilter-persistent save

Now you have two layers of protection: the application binds to a specific IP, and firewall rules enforce that only the intended subnet can access it. If either layer has a bug or misconfiguration, the other provides a safety net.

Comparison: Which Approach?

Each strategy has tradeoffs. Understanding them helps you choose the right tool for your situation.

Approach	Best For	Complexity	Maintenance	Security
Tailscale	Modern, managed infrastructure, teams	Low	Low	Excellent
SSH Tunnels	Single-user, barebones servers, compatibility	Medium	Medium	Excellent
Gateway Binding	Internal networks only, not for internet	Low	Low	Good

Our recommendation: Use Tailscale if you can. It’s zero-configuration, encrypted by default, and handles edge cases (NAT, dynamic IPs) automatically. SSH tunneling is the reliable fallback for environments where Tailscale can’t be used. Gateway binding is fine for genuinely internal networks, but it’s not a substitute for the other two when public internet access is a possibility.

The Anti-Pattern: Public Port Binding

Here’s what not to do:

# NEVER EVER DO THIS
server:
  host: 0.0.0.0 # Listen on all interfaces
  port: 18789
  authentication:
    enabled: true # "But we have a password!"
  tls:
    enabled: false # "We'll add TLS later"

This is exposed to the entire internet. The problems:

1. Default credentials are cracked in seconds. Attackers have credential databases from previous breaches. They’ll try admin/admin, admin/password, default/default.

2. Authentication isn’t encryption. Even if your password is strong, HTTP traffic travels in plaintext unless TLS is forced. An attacker can capture credentials by eavesdropping on network traffic.

3. Software vulnerabilities are exploited. An auth bypass in OpenClaw, a vulnerability in a dependency, an unsanitized input—any of these become direct attack vectors. Automated tools will find and exploit them within hours.

4. Botnets scan constantly. Your server will be targeted by automated scanners within hours of going online. Malware tries every known default credential and vulnerability.

5. Supply chain attacks are real. A vulnerability in a legitimate package you’re using, a compromised dependency, or malicious code injected into your build pipeline—all of it reaches your production instance.

Even if you think nobody knows about your server, automated scanners will find it. The internet is hostile. Treat it that way.

Architecture Summary

Here’s your ideal setup:

┌─────────────────────┐
│   Your Local Machine │
│  Tailscale Client   │
└──────────┬──────────┘
           │ (Encrypted VPN)
           │
┌──────────▼──────────────────┐
│   OpenClaw Server           │
│  ├─ Listening: localhost    │
│  ├─ Tailscale IP: 100.x.x.x│
│  └─ Dashboard: :18789       │
└─────────────────────────────┘

Firewall Rules:
├─ Drop all inbound to :18789
├─ Allow Tailscale traffic
└─ SSH access on non-standard port (if used)

OpenClaw listens only on localhost and the Tailscale interface. The firewall drops everything else. You access it through Tailscale encryption. Nobody on the public internet can reach it. Perfect isolation.

Testing Your Setup

Verify you’re actually isolated:

# From outside your network, scan for the port
nmap -p 18789 your-public-ip
# Response: filtered (all ports are filtered/closed)
# GOOD ✓

# From inside your tailnet, verify Tailscale access works
ping openclaw-server.tailscale.com
# Response: replies from 100.x.x.x
# GOOD ✓

# Verify localhost only (from the server itself)
curl https://automateanddeploy.com:18789
# Works ✓

curl http://0.0.0.0:18789
# Refused ✓

curl http://192.168.1.1:18789
# Refused ✓

These tests confirm:

• The port isn’t exposed to the public internet
• Tailscale connectivity works
• Only localhost and the Tailscale IP are accessible
• Other network interfaces can’t reach it

Final Principles

1. Never public ports: Your OpenClaw should never have a listening port exposed to the public internet. Not with authentication, not temporarily, not “for testing.”

2. Explicit tunnels: All remote access goes through Tailscale or SSH tunnels, not application-level auth. The network layer is your strongest defense.

3. Encrypt in transit: All traffic should be encrypted. WireGuard for Tailscale, TLS for HTTPS, OpenSSH encryption for tunnels.

4. Firewall enforcement: Don’t rely on the application alone. Enforce network isolation at the firewall level. Defense in depth.

5. Principle of least access: Only the specific users and devices that absolutely need access can access it. No open-for-everyone, no “for now.”

6. Zero-trust verification: Even if someone’s on your network, verify they should be accessing this specific service.

7. Automatic encryption: Choose solutions that encrypt by default without configuration. Manual TLS setup is error-prone.

Network isolation is your first line of defense. Get this right, and the rest of security becomes much easier. Get this wrong, and everything else is moot.

The fact that OpenClaw itself is running is irrelevant if nobody can reach it. Make that your reality.

---