If you run an OpenClaw agent — or any local AI agent — you eventually hit a wall: your agent lives on your machine, but the things you need it to reach (another agent across town, a SaaS tool behind NAT, a teammate's private service) live somewhere else. Opening a port feels reckless. SSH tunnels get brittle. Webhooks need a public URL you don't have.
This post walks through the actual options for wiring an OpenClaw agent to external peers and capabilities without ever punching a hole in your firewall.
The Default: Local-Only and Why That Breaks
OpenClaw runs as a local gateway process on your machine or VPS. That's great for local tools — files, shell, browser, your local database. Its communication model assumes reachable endpoints: either localhost, or public APIs that your machine can connect outbound to.
The problem shows up when your agent needs to:
- Talk to another agent running on a different machine (a coworker's agent, a fleet agent on a cloud VM)
- Access a service on a private network (a self-hosted API, a database that you don't want exposed)
- Receive inbound requests (a webhook call from GitHub, a message from another agent asking for help)
In all these cases, the remote side needs a way to reach your agent — and your agent is behind a router, a carrier-grade NAT, or a corporate VPN.
Path 1: Port Forwarding (Don't)
You could forward a port on your router to the OpenClaw gateway port (default 127.0.0.1:18789). Please don't.
- You're exposing your entire agent gateway to the internet
- Dynamic IPs break the address
- CGNAT on many ISPs makes it impossible
- Your home or laptop becomes a production dependency
This is the highest-risk option and I only mention it to rule it out.
Path 2: SSH Reverse Tunnel
SSH tunneling is the classic workaround. You provision a cheap cloud VM with a public IP, then run a reverse tunnel from your local machine:
ssh -R 9090:localhost:18789 user@your-vm.example.com
Now anything that reaches your-vm.example.com:9090 gets forwarded to your local OpenClaw gateway.
It works — I've done it. But:
- One SSH tunnel per agent (they don't multiplex well)
- If the tunnel drops, your agent goes silent (autossh helps, but still)
- No authentication layer — you're trusting that whatever hits port 9090 is legitimate
- Adding another peer means another tunnel config
Path 3: Overlay Network (The Scalable Pattern)
An overlay network gives every agent a permanent virtual address — independent of its physical IP. Agents talk to each other over encrypted tunnels, and NAT traversal is handled at the protocol layer. You don't expose ports. You don't configure tunnels. You just install one daemon and join.
This is the pattern used by open-source projects like Tailscale (wireguard-based) and Pilot Protocol (UDP-based with no kernel deps). For agents specifically, the requirements are a bit tighter than general mesh VPNs: you need agent-native discovery (find capabilities by name, not just IP), a trust model that matches agent relationships (not "join a network = trust everyone"), and ideally an app ecosystem.
Pilot Protocol, for example, is an open-source overlay network written in Go with zero external dependencies. It gives each agent a permanent address, handles NAT traversal (STUN + hole-punching + relay fallback), and pairs each peer relationship with an explicit handshake — no "joined = trusted."
For an OpenClaw agent, the setup looks like this:
# On your local machine — install the overlay node
curl -fsSL https://pilotprotocol.network/install.sh | sh
# Your agent now has a permanent virtual address
pilotctl info
# Approve a handshake from a peer agent on a different machine
pilotctl pending
pilotctl approve <peer-node-id>
Your OpenClaw agent can now reach that peer at a virtual address, and vice versa. No open ports. No cloud VM. No tunnel config.
What This Unlocks
Once your agent is on the overlay, the "reachability" problem flips to "what can I reach?":
-
Agent-to-agent messaging: your OpenClaw agent can send structured messages to any other peer on the overlay using
pilotctl send-message. This replaces webhook callbacks with direct, persistent channels. - Private service access: expose a local service (your OpenClaw gateway, a database, an internal API) to specific peers without a public endpoint.
- Agent app store: the same overlays often include installable capability apps — web search, SQL databases, contact enrichment — that run locally on your daemon. Your OpenClaw agent can discover and invoke them as typed JSON services.
The Trust Model Matters
For agent networking, trust is the part most VPNs get wrong. In a mesh VPN, "joining the network" typically means you can reach every other member. For agents, you generally want finer control: "I approve this specific peer to talk to my agent, not every node on the network."
Overlay networks built for agents (rather than general site-to-site VPNs) support per-peer handshake approval. Your OpenClaw agent can accept a handshake from a colleague's agent, and reject everyone else — no broadcast trust.
Which Path Should You Use?
If you have one tunnel to maintain and a cheap VM, SSH tunnels are a valid quick fix. I've run agents that way for weeks.
But if you're building anything that outlives a single afternoon — multiple agents, services on different machines, regular peer-to-peer communication — an overlay network is the pattern that scales without piling on fragile infrastructure. The agents get addresses. The network handles NAT. You handle the trust decisions.
The commands are the same whether you have two agents or two hundred:
pilotctl handshake <peer> "OpenClaw agent mesh"
pilotctl send-message <peer> "help me review this PR"
That's the end state worth aiming for: your OpenClaw agent stops being a lonely process on one machine and becomes a node on a network where it can reach — and be reached by — the peers and services it actually needs to be useful.
Top comments (0)