Telnyx Network

Private mesh networking and public IP exposure via Telnyx WireGuard infrastructure. Connect nodes securely or expose services to the internet.

Security Scan

The skill largely does what it claims (manage a Telnyx WireGuard mesh), but there are mismatches and privileged operations (passwordless sudo for WireGuard, persistent local private keys, missing declared dependencies) that raise security concerns you should understand before installing.

Purpose & Capability

The code and SKILL.md implement Telnyx WireGuard mesh and public-IP exposure, which fits the name/description. However the declared requirements (only 'wg' binary and TELNYX_API_KEY) are incomplete: the scripts also rely on curl, python3, sudo, iptables/ip/ifconfig, wg-quick, and the optional 'telnyx' CLI. The skill therefore underdeclares what it needs, which is an incoherence the user must notice.

Instruction Scope

Runtime instructions and scripts perform privileged system changes (writing /etc/sudoers.d via setup-sudoers.sh), create and store WireGuard private keys (wg-<name>.conf), modify iptables to open ports, and create/delete cloud resources via Telnyx APIs/storage. Those actions are within the documented feature set, but they are high-impact: the sudoers change enables passwordless execution of wg/wg-quick, and the skill's automation could bring up interfaces or expose services without further explicit system prompts if the user enables it.

Install Mechanism

There is no registry install spec (instruction-only), and all code is bundled as scripts in the package. No external download URLs are used. This is lower risk than arbitrary remote installers, but the presence of many local scripts means you must review them before running. The package does not provide an automated install; it expects users to run the provided scripts manually (including the sudoers installer).

Credentials

The declared primary credential is TELNYX_API_KEY, which is appropriate for the Telnyx API calls present. However scripts also source a local .env (which can contain arbitrary values) and call the Telnyx CLI (which may use separate auth). The skill will store WireGuard private keys and config.json locally — these are sensitive secrets stored on disk and not encrypted by the scripts.

Persistence & Privilege

The README explicitly instructs the user to run setup-sudoers.sh to allow passwordless sudo for wg/wg-quick so the agent can manage WireGuard autonomously. While enabling autonomous management is a functional requirement, the resulting persistent sudoers entry combined with normal model-invocation (disable-model-invocation is false) increases blast radius: an agent or any process that can invoke these scripts could bring up interfaces, change firewall rules, or expose services without additional password prompts. This is a meaningful privilege escalation risk and should be accepted only consciously.

What to consider before installing

What to consider before installing/using: - Review and verify the scripts yourself. They will: call Telnyx APIs, create/delete cloud resources, write WireGuard config files containing private keys (wg-<name>.conf), modify iptables, and (optionally) add a sudoers file to allow passwordless wg/wg-quick. - Missing declared dependencies: the SKILL metadata only lists 'wg' and TELNYX_API_KEY, but the scripts also require curl, python3, sudo, iptables (or nftables equivalent), ip/ifconfig, wg-quick, and (for some commands) the Telnyx CLI. Ensure these are acceptable and installed. - Sudoers change is high-impact. setup-sudoers.sh writes /etc/sudoers.d/wireguard-<user> to allow passwordless execution of wg/wg-quick. Only run this if you trust the code and understand that it lets processes run WireGuard commands without a password. - Secrets handling: WireGuard private keys and config.json are saved unencrypted in the skill directory. Treat the TELNYX_API_KEY with least privilege (create a scoped/revocable key if Telnyx supports it) and consider file permissions and where you run these scripts (use an isolated VM/container if unsure). - Autonomous invocation: the skill is invocable by the agent and not marked 'always', but if you enable passwordless sudo you effectively permit the agent to manage networking without interactive confirmation. If you do not want that, do not run setup-sudoers.sh; instead run privileged commands manually. - Network exposure: exposing ports and adding an Internet Gateway will make services reachable from the public internet. The scripts block a list of database/SSH ports by default, but you should double-check firewall rules and only expose what you intend. - Safe deployment suggestions: test in an isolated environment (VM/container), use a Telnyx API key with minimal scope, audit and possibly harden the scripts (encrypt private keys, restrict sudoers to exact command paths and arguments, ensure iptables rules are safe), and avoid enabling passwordless sudo if you cannot fully audit and trust the code. If you want, I can produce a checklist of exact lines to inspect/change in the scripts to harden them (e.g., restrict sudoers commands, secure file permissions, or avoid saving private keys to disk).

Private mesh networking and public IP exposure via Telnyx WireGuard infrastructure.

Requirements

• Telnyx API Key — Get one free
• WireGuard installed on your machine

Agent Use (OpenClaw)

WireGuard requires elevated permissions to create network interfaces. For OpenClaw to manage your mesh autonomously, run this once:

sudo ./setup-sudoers.sh

This adds a sudoers rule allowing WireGuard commands without password prompts. After setup, your agent can:

# Agent can now do all of this without password prompts:
./setup.sh --region ashburn-va
./join.sh --name "my-node" --apply
./register.sh --name "my-node"
./teardown.sh

What it does:

• Adds /etc/sudoers.d/wireguard-<username>
• Only allows wg and wg-quick commands (not blanket sudo)
• Can be removed anytime: sudo rm /etc/sudoers.d/wireguard-*

Without this setup, the agent can still create networks and generate configs, but you'll need to manually run sudo wg-quick up <config> to connect.

Two Modes

Mesh Mode (Private)

Connect multiple machines in a private network. Like Tailscale, but on Telnyx infrastructure.

./setup.sh --region ashburn-va
./join.sh --name "laptop"
./join.sh --name "server"  # run on server
# Now laptop and server can talk via 172.27.0.x

Cost: $10/month (WireGuard Gateway)

Expose Mode (Public)

Get a public IP and expose services to the internet.

./setup.sh --region ashburn-va
./join.sh --name "server" --apply
./add-public-ip.sh
./expose.sh 443
# Now https://64.16.x.x:443 reaches your server

Cost: $60/month (WireGuard Gateway + Internet Gateway)

Commands

Command	Description
sudo ./setup-sudoers.sh	Enable passwordless sudo for WireGuard (one-time, for agent use)
./setup.sh --region <code>	Create network + WireGuard gateway
./join.sh --name <name>	Add this machine to the mesh
./peers.sh	List all connected peers
./add-public-ip.sh	Add internet gateway (public IP)
./expose.sh <port>	Open a port
./unexpose.sh <port>	Close a port
./status.sh	Show full status
./teardown.sh	Delete everything
./register.sh --name <name>	Register node in mesh registry
./discover.sh	Discover other nodes on mesh
./unregister.sh --name <name>	Remove node from registry

Node Discovery

Nodes on the mesh can find each other using a registry stored in Telnyx Storage. This enables OpenClaw instances to automatically discover and communicate with each other.

Register This Node

After joining the mesh, register your node so others can find it:

./register.sh --name "home-server"

Discover Other Nodes

Find all registered nodes on the mesh:

./discover.sh

# Output:
# NAME            IP              HOSTNAME             REGISTERED
# home-server     172.27.0.1      macbook.local        2026-01-31 ✅
# work-laptop     172.27.0.2      thinkpad             2026-01-31 ✅

# JSON output for scripts
./discover.sh --json

Unregister

Remove a node from the registry:

./unregister.sh --name "old-server"

Use Case: Multi-OpenClaw Communication

# On OpenClaw A
./join.sh --name "openclaw-a" --apply
./register.sh --name "openclaw-a"

# On OpenClaw B
./join.sh --name "openclaw-b" --apply
./register.sh --name "openclaw-b"

# Either can now discover the other
./discover.sh
# → Shows both openclaw-a and openclaw-b with their mesh IPs

# Direct communication works via mesh IPs
curl http://172.27.0.2:18789/health  # OpenClaw B's gateway

This completes the "host-to-local node sessions" and "direct comms between OpenClaws" use cases.

Regions

Region	Code	Location
US East	ashburn-va	Ashburn, VA
US Central	chicago-il	Chicago, IL
EU	frankfurt-de	Frankfurt, DE
EU	amsterdam-nl	Amsterdam, NL

Get full list:

./setup.sh --region help

Safety

Blocked Ports (need --force)

• 22 (SSH)
• 23 (Telnet)
• 3306 (MySQL)
• 5432 (PostgreSQL)
• 6379 (Redis)
• 27017 (MongoDB)

Firewall

Only explicitly exposed ports accept traffic on the WireGuard interface. All other ports are blocked by default.

Configuration

All state is stored in config.json:

{
  "network_id": "...",
  "region": "ashburn-va",
  "wireguard_gateway": {
    "id": "...",
    "endpoint": "64.16.x.x:5107",
    "subnet": "172.27.0.1/24"
  },
  "internet_gateway": {
    "id": "...",
    "public_ip": "64.16.x.x"
  },
  "peers": [...],
  "exposed_ports": [443, 80]
}

Use Cases

1. Connect OpenClaw Instances

# On main server
./setup.sh --region ashburn-va
./join.sh --name "openclaw-main" --apply

# On secondary server
./join.sh --name "openclaw-backup" --apply

# Now they can communicate securely

2. Expose Webhook Endpoint

./add-public-ip.sh
./expose.sh 443
# Configure your webhook URL as https://64.16.x.x/webhook

3. Multi-Region Mesh

./setup.sh --region ashburn-va
./join.sh --name "us-east-server"

# Same network, different region gateway
./setup.sh --region frankfurt-de --name same-network
./join.sh --name "eu-server"

Pricing

Component	Monthly Cost
WireGuard Gateway	$10
Internet Gateway	$50
Peers	Free
Traffic	Free (beta)

Troubleshooting

"Gateway still provisioning"

Wait 5-10 minutes after setup for the gateway to be ready.

"Connection refused"

• Check WireGuard is running: sudo wg show
• Check port is exposed: ./status.sh
• Check firewall: sudo iptables -L -n

"Permission denied"

WireGuard requires root. Run with sudo or use --apply flag.

License

MIT