How to Run an OpenClaw Raspberry Pi WireGuard Site-to-Site VPN Agent

Most WireGuard tutorials stop at a single client dialing into a single server. A site-to-site deployment is different. You have two networks, usually a main office and a branch or a home lab, and you want every device on each side to reach every device on the other side without installing a VPN client on each host. The Raspberry Pi on each end becomes the gateway: it holds the WireGuard interface, advertises the remote subnet through its routing table, and forwards packets between the two LANs.

A WireGuard handshake completes in roughly one round trip, which is why the protocol feels instant on resumes and roaming. The agent sitting on top of this, an OpenClaw agent in this case, is not replacing wg-quick or systemd-networkd. It orchestrates the messy operational work around the tunnel: generating keypairs, distributing public keys between peers, keeping the two AllowedIPs lists in sync as subnets grow, and writing down what changed so the next person to look at the gateway understands why.

The reason this matters is that site-to-site tunnels are quiet until they break. A forgotten route, a rotated key, a firewall rule drift, and suddenly two offices cannot see each other and no one remembers who touched the config last. An agent fixes that only if its work is visible and durable. Scripts that run and disappear are worse than no automation at all.

Before touching any config, decide on the topology. Single-gateway, single-tunnel is fine for a home lab. For anything you would call production, even a small one, plan for a second gateway on at least one side.

A reasonable starting layout looks like this:

• Site A: two Raspberry Pi gateways, each with its own WireGuard interface and a floating virtual IP managed by keepalived or a similar VRRP daemon. The LAN default route points at the virtual IP.
• Site B: one or two Raspberry Pi gateways, configured as peers of both Site A gateways.
• Peering: each Site A gateway holds a peer entry for each Site B gateway, and vice versa. PersistentKeepalive keeps NAT mappings warm so the tunnel can re-establish quickly after a link flap.
• Failover signal: the VRRP daemon promotes the standby when the active gateway stops responding. The tunnel on the standby is already up, so traffic shifts within a few seconds.

This is the gap most guides leave open. They show you how to bring up one tunnel, not how to keep the link alive when a Pi decides to wedge itself at 3am. A Raspberry Pi 4 or 5 with a decent SD card and a wired Ethernet connection is more than capable of pushing a symmetric 300-500 Mbps WireGuard tunnel, so the hardware is rarely the bottleneck. The failure modes are SD card corruption, power blips, and kernel panics after a bad update.

Plan the IP allocation before you generate any keys. A common pattern is a dedicated /30 or /29 for the tunnel link itself (for example 10.88.0.0/30) plus explicit AllowedIPs entries for each LAN subnet on the far side. Using an overly broad AllowedIPs like 0.0.0.0/0 on a site-to-site link is the fastest way to black-hole your own internet traffic.

Give your network agent a workspace it can actually work in

Store topology, configs, and audit artifacts in a Fast.io workspace your OpenClaw agent and your network engineer can both reach. 50GB free, 5,000 credits a month, no credit card.

Sign Up Free

Keep the scope of the agent honest. The OpenClaw agent is a workflow runner. It is good at reading a declared desired state, running small idempotent steps, and reporting what it did. It is not a replacement for the WireGuard kernel module, the Pi's package manager, or your firewall.

A realistic division of labor looks like this:

The agent owns the paperwork. It renders wg0.conf from a template, tracks which peers are in the topology, generates new keypairs when an operator requests rotation, and files the resulting public keys and configs back into a shared workspace. When a new branch office comes online, the agent writes the peer block for both sides and opens a change record.

The operator owns the install. Flashing the SD card, installing wireguard-tools, enabling IP forwarding in sysctl, and opening the UDP port on the upstream firewall are one-time steps that happen before the agent gets involved. Trying to automate first-boot provisioning with a cloud agent is usually more fragile than just running the commands from a checklist.

The kernel owns the tunnel. Once wg0 is up, the WireGuard kernel module handles the handshake and packet encryption. The agent should never be in the data path. Its job ends when the config file on disk matches the declared peer list.

Because the OpenClaw integration path changes as the project evolves, treat the exact skill or tool invocation as something to confirm against the current OpenClaw docs in your own run. What stays stable is the pattern: the agent reads inputs from a workspace, mutates files in place on the Pi, and writes artifacts back.

The config itself is the easy part. Here is the shape of a minimal site-to-site pair, with placeholder values you would replace during provisioning. Treat these as illustrative templates, not copy-paste production configs.

Site A gateway (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.88.0.1/30
ListenPort = 51820
PrivateKey = <site-a-private-key>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <site-b-public-key>
Endpoint = siteb.example.com:51820
AllowedIPs = 10.88.0.2/32, 192.168.20.0/24
PersistentKeepalive = 25

Site B gateway mirrors it:

[Interface]
Address = 10.88.0.2/30
ListenPort = 51820
PrivateKey = <site-b-private-key>

[Peer]
PublicKey = <site-a-public-key>
Endpoint = sitea.example.com:51820
AllowedIPs = 10.88.0.1/32, 192.168.10.0/24
PersistentKeepalive = 25

Three details that trip people up:

1. AllowedIPs is a routing statement, not a filter. WireGuard uses it to decide which peer a packet belongs to. If you leave the far-side LAN out, packets for that LAN will never hit the tunnel.
2. net.ipv4.ip_forward = 1 must be set in /etc/sysctl.conf on both Pis, otherwise the gateway silently drops transit traffic.
3. The UDP port (51820 by default) must be reachable from the internet on at least one side. If both sides are behind CGNAT, you need a relay or a cloud pivot. A Pi at home with a CGNAT ISP will never accept an inbound handshake, no matter how clean the config is.

Bring the tunnel up with wg-quick up wg0 and confirm with wg show. A healthy peer shows a recent handshake timestamp and non-zero transfer counters within a minute.

This is the part that makes the difference between a working tunnel and a maintainable one. The agent needs somewhere to read inputs from and write outputs to that the human operator can also see, comment on, and hand off to the next person.

A workspace-backed flow looks like this. Create a Fast.io workspace for the VPN project and enable Intelligence Mode so its contents are indexed and queryable. Drop the topology file (a simple YAML listing each site, each Pi, and each subnet) in the workspace. When the agent runs, it pulls the topology, renders the peer configs, writes them back into a configs/ folder in the workspace, and logs what changed. The audit trail is built in. Every version of every config file is retained and timestamped, so if a rollback is needed the previous known-good file is one click away. See the workspace product page for the general shape.

For the sensitive bits, keep private keys out of the shared area. A common pattern is to generate the keypair on the Pi itself with wg genkey | tee privatekey | wg pubkey > publickey, upload only the public key to the workspace, and never let the private key leave the gateway. The agent still has enough to do its job because peer configs only reference the far side's public key.

Three Fast.io features pull their weight here:

• Granular permissions at the folder and file level let you share the configs/ folder with a network engineer read-only while keeping the agent's working folder writable only to the agent's credentials.
• Branded shares make it easy to hand an audit bundle to a client, a security reviewer, or an incident responder without inviting them into your whole workspace.
• Ownership transfer means the agent can build the whole workspace during initial deployment and then hand it to the team that will operate it, while keeping admin access for itself so it can keep making changes. The free agent plan gives you 50GB of storage and 5,000 credits per month with no credit card, which is more than enough for this kind of small ops workspace. See storage for agents for the agent-side framing and pricing for the current plans.

S3 or a git repo can do some of this too. The reason a workspace tends to win for agent-driven ops is that you get search, chat-over-files, and human-readable version history in the same place, instead of stitching together a bucket, a log shipper, and a wiki.

The tunnel is up. Now make it boring.

Health checks. Run a simple ping from each gateway to a known host on the far LAN every 30 seconds. If three in a row fail, log it and page. Do not rely on WireGuard's handshake timer alone, because a tunnel can be "up" while routing on one side is broken.

Key rotation. Plan to rotate gateway keys at least yearly. The agent should generate the new keypair on the Pi, stage the new peer config in the workspace for review, and only then swap the active config. Rotating keys without a staged rollback is how you lock yourself out of a remote site.

Config drift. Compare the running config (wg showconf wg0) against the declared config in the workspace on a schedule. Any drift is either a manual change someone forgot to record or a sign the agent run failed partway through. Both are worth investigating.

Upgrade windows. Raspberry Pi OS updates occasionally replace the WireGuard kernel module in a way that requires a reboot. Do not run unattended upgrades on both gateways at the same time. Stagger them, and make sure the standby is actually standing by before you touch the active.

Bandwidth reality. A Pi 4 with stock cooling will push roughly 300 Mbps of WireGuard traffic before the CPU becomes the ceiling. A Pi 5 does better. If you need more, the bottleneck is the hardware, not the protocol, and a small x86 box will outclass the Pi for a similar price.