Agentless WireGuard Mesh VPN on Existing Routers

Related Reading: WireGuard NAT Traversal: Connecting Peers Behind CGNAT & Firewalls (2026)

Related Reading: How WireGuard Site-to-Site VPN Works (2026 Protocol Guide)

Key takeaways

• Agentless means the router is the endpoint. WireGuard runs natively in router firmware; the mesh platform only supplies coordination, not software.
• The control plane replaces the config file. Key distribution, peer state, and revocation move from a hand-edited wg0.conf to a cloud service each branch dials outbound.
• NAT traversal is solved by dialing out. Every branch initiates an outbound connection, which makes carrier-grade NAT and dynamic IPs a non-issue.
• Onboarding is a two-minute step, not a project. No hardware to ship, no firmware to flash, no installer to schedule.
• The model suits 5-to-50-branch businesses with mixed router fleets and generalist IT teams; it is not built for packet-level WAN optimisation.
• Security is inherited from WireGuard’s audited crypto — X25519, ChaCha20-Poly1305, Poly1305 — with the control plane adding per-org isolation and fast policy revocation.

Why “without an agent” matters now

Every multi-branch business has a version of the same conversation. The IT generalist — the person who also handles the email, the ERP, the Wi-Fi passwords, and the printer that keeps jamming — is asked to connect five, ten, or forty locations into one private network. The options they are handed all seem to require something they do not have: a dedicated appliance, a specialist installer, or a fleet of software agents to manage.

The agentless WireGuard mesh removes the last of those three. It does not ask the business to install anything on the routers, because the routers already speak the protocol. It does not ask for a specialist, because the coordination layer does the work a specialist would otherwise do. And it does not ask for new hardware, because the existing router fleet is the hardware.

The result is a private network that comes online at the pace the business moves, not the pace the network team can schedule. A retail chain opening a seasonal store, a clinic group adding a neighbourhood practice, a distributor reshuffling a godown footprint — each of these becomes a two-minute step rather than a procurement project. That is the operational reality the agentless model was built for.

What changed between 2018 and 2026

Understanding why agentless mesh is possible now requires understanding what was not possible before. Three things shifted between the SD-WAN era and today, and each one made the current model viable.

WireGuard entered the kernel. WireGuard was merged into the Linux kernel in 2020, and from there it proliferated into the router firmware most businesses already run. OpenWrt, MikroTik RouterOS, TP-Link, Ubiquiti, OPNsense — the major firmware families all ship native WireGuard support today. That single fact is the foundation of the agentless model: the tunnel technology is already on the device, maintained by the firmware vendor, updated with the firmware. There is nothing for the business to install.

Fibre broadband became the default. Consumer and small-business fibre is now affordable and reliable across the markets where multi-branch SMBs operate. The old argument for dedicated appliances — that broadband could not carry production traffic without intelligent path selection — has weakened as the underlying transport improved. The transport is no longer the bottleneck the appliance was built to solve.

Carrier-grade NAT became the norm. CGNAT is now the default on consumer and small-business connections. This changed the shape of how branches can connect. A branch behind CGNAT cannot accept an inbound tunnel; it can only dial out. The agentless mesh is designed around exactly that constraint — every branch dials outbound, so CGNAT stops being a problem and becomes the expected condition.

The combined effect is that the value proposition of the old model — sophisticated orchestration delivered through dedicated appliances — now competes with a lighter proposition: cloud coordination running on the routers organisations already operate. For businesses whose reality still resembles 2018, the old model holds. For the 5-to-50-branch segment that drives most growth, the new conditions favour the new model.

What “agentless WireGuard mesh” actually means

Let me be precise about the term, because “agentless” gets used loosely.

An agent-based mesh installs a software client on each device. The client handles the tunnel, the key management, the policy enforcement, and the reporting. This is the model used by most zero-trust access platforms for laptops and workstations — the agent is the endpoint.

An agentless mesh, in the sense this guide uses the term, installs nothing on the router. The router’s native WireGuard implementation is the endpoint. What the mesh platform provides is the coordination layer — the service that tells each router which peers to trust, what keys to use, and where to send traffic. The router does the encryption and forwarding; the platform does the orchestration.

This distinction matters for three reasons.

1. It removes the software lifecycle problem. An agent is software you must deploy, update, patch, and troubleshoot across a fleet. A router’s WireGuard support is part of the firmware — it updates with the firmware, and it is maintained by the firmware vendor. There is no separate agent to keep current.
2. It removes the endpoint coverage problem. An agent only protects devices you install it on. A router-based mesh protects the entire network behind that router — every server, every POS terminal, every camera, every workstation — without touching any of them. The branch becomes the unit of connectivity, not the device.
3. It changes who can operate the network. Agent-based mesh often still requires someone to install and manage the client fleet. Agentless mesh moves that work to the control plane, which a generalist IT team can operate. The operational tax that used to live on a network engineer’s weekly schedule is automated.

The honest caveat: agentless mesh is the right model for site-to-site connectivity. If the goal is securing individual remote workers on arbitrary laptops, an agent-based zero-trust client is the appropriate tool. The two models are complementary, not competing — and the best deployments use both, with the router mesh carrying site-to-site traffic and an agent carrying remote-work traffic.

Architecture: the control plane and the data plane

Every mesh VPN, agentless or not, separates two planes of operation. Understanding this separation is the key to understanding how the whole thing works.

The data plane is the encrypted traffic path between branches. In an agentless WireGuard mesh, the data plane runs entirely on the routers. Branch A encrypts traffic with WireGuard and sends it directly to Branch B over UDP. The mesh platform is not in this path — it does not see the traffic, it does not relay it (except in the fallback cases described below), and it does not add latency. The data plane is peer-to-peer.

The control plane is the coordination service. It holds the state that makes the data plane possible: which routers belong to the organisation, what their public keys are, what their current public endpoints are, and what policy applies to each. When a branch comes online, it dials outbound to the control plane, authenticates, and receives its peer list and configuration. The control plane is the brain; the routers are the muscles.

The critical design decision in an agentless mesh is that the control plane is out-of-band from the data plane. Traffic between branches never touches the coordination service. This is what keeps the mesh fast and what keeps the platform from becoming a bottleneck or a single point of failure for throughput.

To picture it: every branch router dials out to the cloud control plane, which holds the keys, peer list, and policy. The control plane then tells each branch where the others are, and the branches talk directly to one another over encrypted peer-to-peer WireGuard tunnels. The control plane coordinates; the routers carry the traffic. That separation is the whole design.

The control plane also handles the NAT-traversal problem. Because every branch dials outbound, the control plane learns each branch’s current public endpoint — the IP and port the branch appears to come from. It then shares those endpoints with the other branches, so they can attempt direct peer-to-peer connections. This is the same principle STUN uses, applied at the mesh level.

When direct peer-to-peer is impossible — typically when both ends sit behind symmetric NAT — the mesh falls back to a relay. The relay forwards encrypted traffic between the two branches. It still does not decrypt anything; it is a dumb pipe for already-encrypted packets. This fallback is the exception, not the rule, and it is the only case where the platform touches the data path.

Internal working: how the mesh forms

Let me walk through the actual sequence of events when a branch comes online. This is the part that usually surprises people, because it is so much simpler than the old IPsec dance.

Step 1 — The router dials out. The router, running its native WireGuard client, initiates an outbound connection to the control plane’s coordination endpoint. This is a single UDP connection. Because it is outbound, it works from behind CGNAT, behind a dynamic IP, behind a firewall that blocks inbound — none of that matters, because the router is the one reaching out.

Step 2 — Authentication. The router authenticates to the control plane. In WireGuard terms, this is a cryptographic handshake using the router’s private key and the control plane’s public key. The control plane verifies the router belongs to the organisation and is authorised to join.

Step 3 — Configuration delivery. The control plane sends the router its peer list: the public keys of every other branch it should talk to, plus their current public endpoints. This is the moment where the control plane replaces the hand-edited wg0.conf. In a manual WireGuard setup, you would SSH into the router and paste a config with every peer’s key and endpoint. The control plane does that for you, and keeps it current.

Step 4 — Peer discovery. The router now knows who it should talk to and where they are. It attempts a WireGuard handshake with each peer. Because both sides have dialed out to the control plane, both sides know each other’s current endpoints, so the handshake can succeed even through NAT.

Step 5 — Persistent keepalive. Once the tunnel is up, the router sends periodic keepalives to keep the NAT mapping alive. This is what keeps the tunnel stable across the NAT rebinding that happens on consumer connections. Without keepalive, a NAT mapping can expire and the tunnel silently drops.

Step 6 — Continuous reconciliation. The control plane keeps watching. If a branch’s IP changes, if a key is rotated, if a peer is revoked, the control plane pushes the update. The router applies it and re-establishes as needed. This is the automation that would otherwise live on a network engineer’s weekly schedule.

The whole sequence, from the router dialing out to the tunnel being up, takes seconds. The two-minute onboarding figure in the marketing is dominated by the human step — logging into the router and entering the coordination endpoint — not by the protocol.

Components: what runs where

An agentless WireGuard mesh has a small number of moving parts. Naming them clearly helps when something goes wrong, because it tells you where to look.

• The router’s WireGuard client. This is the data-plane endpoint. It is native to the firmware — OpenWrt’s wireguard package, MikroTik’s /interface/wireguard, TP-Link’s WireGuard VPN menu, Ubiquiti’s WireGuard support, OPNsense’s WireGuard plugin. It handles the encryption, the handshake, and the forwarding. It is the only component that touches traffic.
• The coordination endpoint. This is the address the router dials out to. It is a single UDP endpoint on the control plane. The router needs this configured once, during onboarding. Everything else is delivered.
• The control plane service. This is the cloud service that holds organisation state: peers, keys, policy, and current endpoints. It is where you manage the mesh — add a branch, revoke a branch, view status. It is the component that makes the mesh manageable by a generalist team.
• The relay (fallback). This is the component that forwards encrypted traffic when direct peer-to-peer is blocked by symmetric NAT. It is only in the path in that specific case. It does not decrypt; it forwards.
• The management interface. This is the dashboard or API you use to operate the mesh. It talks to the control plane, not to the routers directly. This is what lets a generalist team run a multi-branch network without SSHing into forty routers.

The key insight is that the routers are interchangeable. Because the coordination lives in the control plane, a router can be replaced — a TP-Link swapped for a MikroTik, an old OpenWrt box replaced with a new one — and the rest of the mesh is unchanged. The new router dials out, receives its config, and joins. This is the strategic flexibility that a hardware-locked platform cannot offer.

Workflow: onboarding a branch in two minutes

The onboarding workflow is where the agentless model proves itself. Here is the sequence, step by step, as it actually happens.

1. Add the branch in the control plane. In the dashboard, you create a new site. The control plane generates a keypair for it and marks it as pending.
2. Get the coordination details. The control plane gives you the coordination endpoint and the router’s configuration — either a config snippet or a QR code, depending on the firmware.
3. Enter it on the router. You log into the router’s admin interface, open the WireGuard section, and enter the coordination endpoint and the generated key. On firmware that supports it, you scan a QR code instead of typing.
4. The router dials out. The router connects to the control plane, authenticates, and receives its peer list.
5. The mesh forms. The router establishes tunnels to the other branches. The control plane shows the new branch as online.
6. Verify. You check the dashboard, confirm the branch is green, and move on.

The human step is step 3, and it is the only one that requires touching the router. On most firmware it is a two-minute task that a local manager can do — which is why the model works for retail chains where store managers handle the on-site step, and clinic groups where clinical staff do.

The important detail is that the branch does not need a static IP, does not need port forwarding, and does not need a public IP at all. It dials out, and that is sufficient. This is the property that makes the model work at the scale of real-world small-business fibre, where CGNAT and dynamic IPs are the norm rather than the exception.

Configuration: real examples on real firmware

The configuration surface is small because the control plane does the heavy lifting. But it is worth showing what the router-side step actually looks like on the firmware families most businesses run. These are the coordination details you enter once; the control plane delivers the peer list.

OpenWrt

OpenWrt ships WireGuard as a standard package. The router-side step is creating a WireGuard interface and pointing it at the coordination endpoint.

# Install the package (one-time)
opkg update && opkg install wireguard-tools luci-proto-wireguard

# The control plane provides the private key and the coordination endpoint.
# In LuCI: Network → Interfaces → Add new interface → Protocol: WireGuard VPN
#   Private key:  (provided by control plane)
#   Listen port:  51820
#   Peers:        (delivered automatically by the control plane)

The peer list is delivered by the control plane, so you do not hand-enter peers. You enter the interface’s private key and the coordination endpoint, and the control plane handles the rest.

MikroTik RouterOS

MikroTik has native WireGuard support in RouterOS 7. The router-side step is creating a WireGuard interface and adding the coordination peer.

/interface wireguard
add name=mesh private-key="<provided-by-control-plane>" listen-port=51820

/interface wireguard peers
add interface=mesh public-key="<control-plane-public-key>" \
    endpoint-address=<coordination-endpoint> \
    allowed-address=0.0.0.0/0 persistent-keepalive=25s

The persistent-keepalive=25s is important — it keeps the NAT mapping alive so the tunnel stays up. The control plane then pushes the other branch peers.

TP-Link

TP-Link’s business and Omada routers include a WireGuard VPN client. The router-side step is creating a WireGuard tunnel and entering the coordination endpoint and key. On firmware that supports it, you scan a QR code from the control plane instead of typing the details.

Ubiquiti

Ubiquiti’s UniFi and EdgeRouter lines support WireGuard. On UniFi, you create a WireGuard client tunnel and enter the coordination endpoint and key. On EdgeRouter, you configure the WireGuard interface via the CLI or the config tree.

OPNsense

OPNsense has a WireGuard plugin. You create a WireGuard instance with the private key from the control plane, then add the coordination peer. The control plane delivers the remaining peers.

The pattern is identical across all five: enter the coordination endpoint and the generated key, and let the control plane deliver the peer list. The firmware differences are cosmetic; the model is the same.

Examples: three deployments that work

Concrete scenarios make the model tangible. These are the shapes of business where agentless mesh is the natural fit.

Example 1 — A retail chain with seasonal stores

A retail chain operates 12 permanent stores and opens 4 seasonal stores for the festive period. The IT team is two people. Each store runs a TP-Link business router on consumer fibre, most behind CGNAT.

With agentless mesh, the permanent stores are already connected. When a seasonal store opens, the store manager logs into the router, scans the QR code from the control plane, and the store is on the mesh in two minutes. The POS system, the inventory terminal, and the CCTV all reach the head-office systems over the encrypted tunnel — without any of those devices being touched. When the season ends, the store is revoked from the control plane, and the tunnel disappears. The IT team never visits the site.

Example 2 — A clinic group expanding by acquisition

A clinic group grows by acquiring smaller practices. Each acquired practice has its own router — a mix of MikroTik and OpenWrt boxes accumulated over the years. The group’s clinical systems must be reachable from every practice, and patient data must stay in-region.

The agentless mesh connects each acquired practice without replacing its router. The existing MikroTik or OpenWrt box dials out, joins the mesh, and the practice’s clinical workstations reach the central systems over the encrypted tunnel. The mixed router fleet is not a problem because the coordination lives in the control plane, not in the hardware. Data residency is satisfied by an in-region control plane.

Example 3 — A distributor with a reshuffling footprint

A distributor operates godowns that open, close, and move as demand shifts. The network must follow the business, not the other way around.

With agentless mesh, adding a godown is a self-service step. The local manager enters the coordination details on the router, and the godown joins the mesh. When a godown closes, it is revoked. The footprint reshuffles at the pace of the business, and the IT team’s workload does not scale with the churn.

Performance: what the mesh actually costs

The performance story of an agentless WireGuard mesh is the performance story of WireGuard itself, because the data plane is pure WireGuard on the routers. The control plane is not in the traffic path, so it adds no per-packet latency and no throughput ceiling.

WireGuard’s performance advantages are well documented. It runs in the kernel on Linux-based firmware, which means the encryption happens in kernel space rather than in a userspace process. It uses ChaCha20-Poly1305, a cipher that is fast on modern CPUs and, critically, fast on the modest CPUs found in small-business routers. The result is that a router that would struggle with a userspace VPN can often handle WireGuard at line rate.

The practical numbers depend on the router hardware. A low-end router might push a few hundred megabits per second through WireGuard; a mid-range business router can push gigabit. For the traffic patterns of most multi-branch SMBs — POS traffic, ERP, file access, CCTV — this is far more than enough.

The latency story is equally good. Because traffic goes peer-to-peer between branches, it does not hairpin through a central hub. Branch A to Branch B is a direct path, not a detour through a data centre. For latency-sensitive workloads, this direct path is a real advantage over hub-and-spoke models.

The one performance caveat is the relay fallback. When two branches cannot connect peer-to-peer because of symmetric NAT, traffic relays through the platform, which adds latency and consumes relay bandwidth. This is the exception, and it is worth designing around — but for most branch-to-branch traffic, direct peer-to-peer is the norm.

Security: what the control plane does and does not see

The security model of an agentless WireGuard mesh has two halves: the cryptography and the trust boundary.

The cryptography is WireGuard’s. The data plane uses X25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, and Poly1305 for authentication. This is the audited, widely reviewed crypto stack that has made WireGuard the default for modern VPNs. The mesh does not replace or weaken it; it uses it as-is. Traffic between branches is encrypted end-to-end, and the control plane cannot read it.

The trust boundary is the control plane’s. The control plane holds the organisation’s keys and peer state. This is where the security model concentrates, and it is why the design choices of the platform matter. Strict per-org isolation means one organisation’s keys and peers are never visible to another. Fast-acting policy means a revoked branch stops being able to connect immediately, not after a config refresh. Audit-friendly logging means the platform can demonstrate what happened, which matters for compliance reviews.

The important distinction for anyone evaluating the model: the control plane is a coordination trust boundary, not a data trust boundary. It can see who is talking to whom and when — the metadata of the mesh. It cannot see the content of the traffic, because the traffic is encrypted end-to-end and never passes through the control plane (except in the relay fallback, where it passes through encrypted and undecryptable).

This is a materially different posture from a cloud proxy that terminates and inspects traffic. An agentless WireGuard mesh is closer to a managed key-distribution service than to a security gateway. That is a feature for organisations that want encrypted site-to-site connectivity without handing their traffic to a third party to inspect.

Troubleshooting: the failures you will actually hit

The agentless model removes a lot of failure modes, but it does not remove all of them. These are the problems that actually show up, and where to look.

• A branch shows offline in the dashboard. The first thing to check is the router’s outbound connectivity. Because the branch dials out, an offline branch usually means the router cannot reach the coordination endpoint — a firewall rule blocking UDP, a DNS failure, or the router being genuinely offline. Check the router’s WireGuard interface status and whether it can reach the coordination endpoint.
• A tunnel is up but traffic does not flow. This is usually a routing or firewall issue on the router, not a WireGuard issue. Check that the router is forwarding traffic between the LAN and the WireGuard interface, and that the LAN firewall allows the traffic. WireGuard being up does not mean the router is routing.
• Intermittent drops on a consumer connection. This is typically NAT rebinding. The fix is a persistent keepalive — most firmware defaults to a sensible interval, but if drops persist, check that keepalive is enabled. The control plane also helps here by tracking current endpoints and pushing updates when they change.
• Two branches cannot connect peer-to-peer. This is the symmetric-NAT case. The mesh falls back to the relay, which keeps the branches connected but adds latency. If this is a persistent pattern for a specific pair, it is worth checking whether one of the branches has a firewall that is interfering with the WireGuard handshake.
• A replaced router does not rejoin. When a router is replaced, the new router needs the coordination details entered again. The control plane treats it as a new endpoint. This is expected behaviour, not a bug — the old router’s key should be revoked, and the new one onboarded.

The common thread: most troubleshooting is router-side, not platform-side. The control plane is simple and reliable; the routers are where the real-world variability lives.

Best practices

These are the habits that keep an agentless WireGuard mesh running smoothly over years, not just at launch.

• Use persistent keepalive on every branch. It keeps NAT mappings alive and prevents silent tunnel drops on consumer connections.
• Revoke branches promptly. When a site closes or a router is replaced, revoke the old key in the control plane immediately. Fast revocation is a security feature; use it.
• Keep firmware current. WireGuard support improves with firmware. A router on old firmware may miss performance or stability fixes.
• Standardise the onboarding step. Document the two-minute router step so local managers can do it consistently. The model only scales if the on-site step is repeatable.
• Design for the relay fallback. Know which branch pairs are likely to need the relay, and account for the added latency in your expectations.
• Separate site-to-site from remote-work. Use the router mesh for site-to-site traffic and an agent-based zero-trust client for individual remote workers. They are complementary.
• Monitor from the control plane. Use the dashboard as your single source of truth for branch status, rather than SSHing into routers.

Common mistakes

The failures in agentless mesh deployments are usually the same few, and they are all avoidable.

• Treating the control plane as a data plane. Expecting the platform to inspect or filter traffic. It does not — it coordinates. If you need traffic inspection, that is a different tool.
• Skipping keepalive. Assuming the tunnel will stay up on its own. On consumer connections, it will not.
• Forgetting to revoke. Leaving a closed branch’s key active. This is both a security and a hygiene problem.
• Over-buying the model. Expecting packet-level WAN optimisation or application-aware QoS from a mesh VPN. Those are SD-WAN features; the mesh does not pretend to be SD-WAN.
• Under-buying the model. Choosing a DIY WireGuard setup with hand-edited configs and no control plane, then discovering the operational tax of maintaining forty configs by hand. The control plane is the point.
• Ignoring the relay. Not accounting for the branch pairs that will need the relay, then being surprised by latency on those paths.

Alternatives: agent-based mesh, IPsec, SD-WAN

The agentless WireGuard mesh is not the only answer, and it is not the right answer for everyone. The honest comparison is against the three alternatives that dominate the conversation.

Agent-based mesh (zero-trust access). This installs a client on each device. It is the right tool for securing individual remote workers and for device-level policy enforcement. It is the wrong tool for site-to-site connectivity, because it only protects devices you install it on. The best deployments use both: the router mesh for sites, the agent for remote work.

IPsec. The mature foundation. It remains the right choice for interoperating with non-WireGuard endpoints — partner networks, vendor firewalls, cloud gateways that mandate IPsec. Its configuration surface is substantial, and NAT traversal through CGNAT adds complexity that the agentless mesh handles natively. For organisations with deep IPsec muscle memory and stable site counts, it remains a legitimate choice.

SD-WAN. The enterprise platform. It delivers application-aware routing, packet deduplication, and carrier-managed SLAs — capabilities the mesh does not attempt. It carries appliance-per-site capital cost and a procurement cycle measured in months. For large enterprises with hundreds of sites and dedicated network operations teams, it earns its place. For the 5-to-50-branch segment, the gap between what SD-WAN provides and what the deployment actually exercises is where budget could go further elsewhere.

The productive framing: the agentless mesh is the modern abstraction on top of WireGuard’s cryptographic principles, optimised for a specific shape of organisation. The alternatives are not wrong; they are built for different shapes.

Comparison tables

Agentless mesh vs. the alternatives

Dimension	Agentless WireGuard mesh	Agent-based mesh (ZTNA)	IPsec	SD-WAN
Endpoint	Router (native WireGuard)	Installed client per device	Router/firewall	Vendor appliance
Software to deploy	None	Agent on every device	Config on each endpoint	Appliance + licensing
Site-to-site	Native	Weak (device-scoped)	Strong	Strong
Remote workers	Not covered	Native	Possible	Possible
NAT traversal	Native (dial-out)	Native	Complex	Varies
Operational fit	Generalist IT	Generalist IT	Specialist	Specialist
Traffic inspection	No (encrypted P2P)	Varies	Varies	Yes (app-aware)
Capital cost	None	None	None	Appliance per site

Router firmware support for agentless WireGuard

Firmware	WireGuard support	Onboarding step
OpenWrt	Native package	Create WG interface, enter coordination endpoint
MikroTik RouterOS 7	Native	Create WG interface + coordination peer
TP-Link (business/Omada)	Native client	Create WG tunnel, enter endpoint/key or scan QR
Ubiquiti (UniFi/EdgeRouter)	Native	Create WG client tunnel, enter endpoint/key
OPNsense	Plugin	Create WG instance + coordination peer

Enterprise deployment

The agentless model scales to enterprise use, but the deployment pattern changes. At enterprise scale, the questions shift from “how do I connect a branch” to “how do I govern, audit, and integrate.”

It is not the right answer for every organisation. Enterprises that need packet-level WAN optimisation and carrier-managed SLAs have a legitimate home in SD-WAN. Organisations that must interoperate with non-WireGuard endpoints have a legitimate home in IPsec. But for the 5-to-50-branch businesses that drive most growth — retail chains, clinic groups, distributors, professional services — the agentless mesh delivers the outcomes that matter at a fraction of the cost and a fraction of the operational burden.

The most informative way to evaluate the model is to run it on real branches. Two machines are included free forever, with no card and no time limit, so the model can be validated against the organisation’s actual environment before any commitment. The question is no longer whether the routers can do it — they already can. The question is whether the business is ready to stop treating multi-branch networking as a project and start treating it as a two-minute step.

---

MeshWG — hosted WireGuard mesh + zero-trust access. Strict per-org isolation, fast-acting policies, works with the routers you already own.

Common questions

Q1. What does "without an agent" actually mean?

It means no software is installed on the router. The router's native WireGuard support is the endpoint; the mesh platform provides only the coordination layer — keys, peers, and policy. The router does the encryption and forwarding; the platform does the orchestration.

Q2. Does the mesh work behind carrier-grade NAT?

Yes. Every branch dials outbound to the control plane, so CGNAT and dynamic IPs are non-issues. The router initiates the connection, which works from behind any NAT that allows outbound UDP.

Q3. Is the control plane in the traffic path?

No. Traffic between branches is peer-to-peer and encrypted end-to-end. The control plane coordinates but does not relay, except in the fallback case where two branches cannot connect peer-to-peer due to symmetric NAT.

Q4. Can the mesh read my traffic?

No. Traffic is encrypted end-to-end with WireGuard's crypto (X25519, ChaCha20-Poly1305, Poly1305). The control plane can see coordination metadata — who is talking to whom — but not the content of the traffic.

Q5. Which routers are supported?

Any router with native WireGuard support — OpenWrt, MikroTik RouterOS 7, TP-Link business/Omada, Ubiquiti, OPNsense, and others. The coordination lives in the control plane, so the router fleet can be mixed and routers can be replaced without reconfiguring the mesh.

Q6. How long does onboarding take?

Under two minutes per site. The human step is entering the coordination endpoint and key on the router — or scanning a QR code on supported firmware. The control plane delivers the peer list automatically.

Q7. Is agentless mesh the same as SD-WAN?

No. Agentless mesh delivers encrypted site-to-site connectivity with central policy and a dashboard. SD-WAN adds application-aware routing, packet deduplication, and carrier-managed SLAs — capabilities the mesh does not attempt. They are built for different shapes of organisation.

Q8. Does agentless mesh cover remote workers?

No. It covers sites. For individual remote workers on arbitrary laptops, an agent-based zero-trust client is the appropriate tool. The two models are complementary.

Frequently Asked Questions (FAQ)

How does a [mesh VPN](/blog/how-to-set-up-a-wireguard-mesh-vpn/) differ from a traditional VPN?

A traditional VPN routes all traffic through a central gateway, creating a bottleneck. A [mesh VPN](/blog/how-to-set-up-a-wireguard-mesh-vpn/) establishes direct, peer-to-peer connections between all devices (like branch offices or cloud servers), reducing latency and eliminating a single point of failure.

Does MeshWG require installing software on every device?

No. MeshWG can be deployed directly on your existing edge routers (like TP-Link, MikroTik, or OpenWrt). This provides agentless, site-wide protection for all devices behind the router without installing VPN clients on individual laptops or IoT devices.

How does WireGuard [NAT Traversal](/blog/wireguard-nat-traversal-behind-cgnat-2026/) work?

WireGuard doesn't have native [NAT traversal](/blog/wireguard-nat-traversal-behind-cgnat-2026/), which is why MeshWG provides a cloud coordination plane. It handles UDP hole punching, PersistentKeepalives, and automatic endpoint discovery to seamlessly connect peers behind CGNAT or strict enterprise firewalls.

---