Standard WireGuard. Nothing custom.

SDWAN for the routers you already own.

MeshWG is an open-source SDWAN + ZTNA controller. Any router with WireGuard support — TP-Link, MikroTik, OpenWrt, Ubiquiti — becomes an SDWAN node. One self-hosted control plane manages orgs, sites, and ACL policies. No appliance, no agent, no proprietary protocol.

No new hardware Standard wg-quick configs Open-source · MIT licensed Self-hosted in ~5 minutes
Works with any router that ships WireGuard
TP-Link
Archer · Deco · ER
D-Link
DIR · COVR · DSR
Ubiquiti
UDM · EdgeRouter
MikroTik
RouterOS 7+
OpenWrt
19.07+
OPNsense
pfSense too
How it works

Three things. That's the whole product.

No magic. No vendor firmware. The controller speaks standard WireGuard to your routers, applies policy at the kernel level, and otherwise stays out of the way.

01

Create an org

Sign up the super admin. Create an organization — that's a tenant. Each tenant gets its own isolated Linux network namespace and a unique WireGuard hub keypair (private key AES-256 encrypted at rest).

# tenant
name = "acme-networks"
namespace = "qm_acme_networks"
hub_ip = "10.100.0.1/16"
02

Add sites

One site = one peer. The controller generates the WireGuard keypair, allocates an overlay IP, and returns a ready-to-paste wg-quick config. Drop it into your router's existing WireGuard interface.

# device
name = "branch-mumbai"
device_type = "site"
overlay_ip = "10.100.0.2"
lan_subnets = ["192.168.10.0/24"]
03

Set policies

Define which peers can reach which. Allow/deny, by protocol and port. Rules are written into the tenant namespace's iptables FORWARD chain in real time — no daemon to restart.

# access_policy
source_id = <site-A>
dest_id = <site-B>
dest_protocol = "tcp"
dest_ports = "443,8000-8100"
action = "allow"
Honest engineering

It's a wg-quick config. No agent. No daemon.

The controller generates standard WireGuard configuration. You paste it into your router's existing WireGuard interface — the same one TP-Link, MikroTik, OpenWrt and Ubiquiti already ship. The router keeps doing what it does. MeshWG just brokers the tunnel.

What it doesn't do

MeshWG is not a Cisco competitor. It doesn't replace firmware, run an agent on your AP, or invent a new tunnel protocol.

  • Standard WireGuard — works on any router that supports it.
  • You own the config. Export it. Audit it. Run it without MeshWG.
  • Private keys are generated at peer creation and never leave the controller's encrypted store.
  • If the controller is down, existing tunnels keep running — kernel WireGuard doesn't depend on it.
# wg0.conf — generated by the controller for site "branch-mumbai"
[Interface]
PrivateKey = (generated by controller, returned once)
Address    = 10.100.0.2/16
MTU        = 1420

[Peer]
# controller's hub for tenant "acme-networks"
PublicKey           = <tenant hub public key>
Endpoint            = vpn.your-domain.com:51820
AllowedIPs          = 10.100.0.0/16
PersistentKeepalive = 25
What it actually ships

Small surface. Picked for branch IT.

Everything below is in the codebase today and exercised by the end-to-end test harness on every release. No vapor.

Sites & user endpoints

Each peer is one row — site (with LAN subnets) or user endpoint. The controller generates the keypair, allocates the next overlay IP atomically, and returns a one-time wg-quick config.

internal/handlers/devices.go

L3/L4 access policies

Allow/deny rules between any two peers by protocol and port (single, comma list, or ranges). Rules are flushed and reapplied to the tenant namespace's iptables FORWARD chain in real time.

verified by e2e steps 8, 11, 14

Tenant isolation by namespace

Each org gets its own Linux network namespace. tcpdump in one tenant's namespace sees zero packets while another tenant floods — proved by step 12 of the e2e harness.

internal/namespace + step 12

Pure spoke-to-spoke through hub

The hub forwards overlay traffic between peers. It is explicitly not an internet exit — no MASQUERADE, no SNAT, only wg0+lo inside the tenant ns. Verified by step 17b.

HANDSOFF_GUIDE.md §2.1.1

Reboots are non-events

A startup reconciler walks every tenant in PostgreSQL and rebuilds the namespace, wg0, peers and routes from DB. Fresh deploy or host reboot: kernel state restores itself in seconds.

internal/wireguard/reconcile.go + step 15

Multi-tenant from day one

One controller, many orgs, per-tenant admin accounts, per-tenant private keys (AES-256-GCM at rest). No second deployment needed when you onboard a new customer.

internal/handlers/tenants.go
vs. SDWAN appliances

The cheapest SDWAN is the one you already deployed.

Box-based SDWAN appliances cost hundreds to thousands of dollars per site plus annual licensing. For 20 branches that is real money. MeshWG uses the WireGuard implementation that is already in your AP.

Box-based SDWAN Cisco Meraki MX, Fortinet, VeloCloud MeshWG Open-source · self-hosted
Hardware cost per site $400 – $2,000 list $0 — uses the WireGuard already in your router
Tunnel protocol Vendor-proprietary IPSec / GRE Standard WireGuard (RFC-equivalent)
Lead time to deploy Weeks (procure, ship, install) Minutes (paste a wg-quick config)
Lock-in Hardware + license + RMA dependencies None — config + keys are yours, MIT licensed code
Multi-vendor support Single vendor Anything that runs WireGuard
Site-to-site policy Yes Yes — iptables-enforced, kernel-level
Multi-port / port-range ACLs Varies by vendor / license tier Yes — `tcp 443,8000-8100` syntax
Tenant isolation VRFs or separate appliances Linux network namespaces — verified by tcpdump test
Internet egress through hub Configurable Explicitly not provided — pure overlay relay
If the vendor disappears Box becomes a brick wg-quick keeps running; source is on GitHub
Deploy

Open source. Self-hosted. No tiers.

MeshWG is MIT licensed. The full source is on GitHub. A fresh Ubuntu 22.04+ VM with 2 vCPU and 4 GiB RAM is enough for the controller. The whole install is a checklist you can read.

  1. 01
    Install deps
    apt install wireguard-tools iptables postgresql-16 caddy
  2. 02
    Build / fetch the controller binary
    go build ./cmd/quickmesh # or download a release
  3. 03
    Set secrets in /etc/quickmesh.env
    ENCRYPTION_KEY, JWT_SECRET, ADMIN_PASSWORD
  4. 04
    Install the systemd unit + Caddyfile
    systemctl enable --now quickmesh caddy
  5. 05
    Verify with the e2e harness
    bash /root/e2e_run.sh # 24 phases, ~3 min, exit 0
FAQ

Honest answers.

What is MeshWG today?

An open-source Go controller that manages WireGuard peers and L3/L4 access policies for one or more tenants. Self-hosted on a single Linux VM. No cloud relays, no agent, no SaaS — the dashboard is the whole product surface.

Is this really SDWAN, or just WireGuard with a UI?

It's WireGuard with a UI, plus per-tenant namespace isolation, kernel-enforced ACLs (iptables), a startup reconciler that rebuilds state from the database after a reboot, and an e2e test harness that validates every claim against real kernel oracles. If 'SDWAN' means a $1,500 box with a vendor sticker, this isn't that. If it means software-defined site-to-site networking with central policy, it is.

Which routers does it work with?

Any router that runs WireGuard. That's TP-Link Archer/Deco/ER, D-Link DIR/COVR/DSR, Ubiquiti UDM/EdgeRouter, MikroTik RouterOS 7+, OpenWrt 19.07+, OPNsense, and pfSense. The controller emits a stock wg-quick config; if your router accepts that, you're good.

Where do private keys live?

Tenant hub private keys are generated by the controller and stored encrypted at rest with AES-256-GCM (key from ENCRYPTION_KEY env). Per-peer private keys are returned exactly once when a site/user is created and not retained server-side after the .conf is shown.

Does the hub provide internet egress for peers?

No. By design and verified by the e2e harness: the tenant namespace has zero MASQUERADE rules, zero SNAT rules, only wg0 + lo interfaces, and 1.1.1.1 is unreachable from inside it. The hub forwards overlay traffic between peers only. Peers reach the internet via their own local network.

What happens if the controller VM goes down?

Existing tunnels keep running — WireGuard is a kernel feature on each peer, it doesn't depend on the controller. You lose the dashboard and the ability to change policies until the controller is back. The startup reconciler rebuilds kernel state from PostgreSQL when it comes back up.

How is this different from Tailscale or Twingate?

Tailscale and Twingate are agent-based — great for laptops and servers, less ideal when you want to mesh dumb branch routers. MeshWG works with the WireGuard interface already in your AP, so you can mesh sites without touching client devices. Different problem, different shape.

Is there a hosted / commercial offering?

Not today. The project is MIT licensed and self-hosted. If managed hosting or commercial support matters to you, open an issue on the GitHub repo so we can gauge demand before building it.

Mesh your branches in a few minutes.
On the hardware you already own.

Open source under MIT. Clone the repo, follow deploy/README.md, and you have a controller running on a Linux VM with a working end-to-end test suite to prove it.