The Problem With Traditional VPNs

For most of their history, VPNs have been built on a single idea: route all your traffic through one central server. Your laptop connects to a gateway, the gateway sits inside the corporate network, and anything you want to reach has to be on the other side of that gateway.

This is called a hub-and-spoke topology, and it works fine when you have a handful of users and one office to reach. But it falls apart quickly as your infrastructure grows:

The gateway is a bottleneck. Every byte of traffic flows through one machine. When 200 engineers and a CI pipeline all push through the same VPN concentrator, throughput suffers and latency climbs.
Hairpin routing wastes everything. Two cloud servers in the same region can’t talk directly. Their traffic has to travel up to the central gateway and back down again, even if they’re physically meters apart.
It’s a single point of failure. If the gateway goes down, the entire network goes dark. There’s no graceful degradation.
Scaling means more hubs. Adding a second region or a second office means standing up another concentrator, then figuring out how to route between them. Each new hub multiplies the configuration burden.

Hub-and-spoke made sense when “the network” meant one office and one datacenter. It makes a lot less sense when your servers are spread across three clouds, your team works from a dozen cities, and half your devices are behind NAT.

What a Mesh VPN Actually Is

A mesh VPN flips the model. Instead of forcing every connection through a central gateway, it treats every device as a peer in one flat, private network. Each peer can establish a direct, encrypted connection to any other peer.

There’s no privileged “inside” and “outside.” Your laptop, your production database, a CI runner, and a Raspberry Pi on your desk are all just nodes in the same mesh, each with a stable address, each able to reach the others by name or IP.

The core properties of a modern mesh VPN like meshr:

Device-to-device encryption — traffic is encrypted at the source and decrypted only at the destination. No intermediary ever sees it in plaintext.
A flat address space — every device gets a stable mesh IP (e.g. 10.0.0.7) that doesn’t change when the device moves networks, switches Wi-Fi, or gets a new cloud IP.
Direct peer connections — when the network path allows it, two devices talk straight to each other with no hop in the middle.
No central chokepoint — because traffic flows peer-to-peer, there’s no single gateway to saturate or take down.

Under the hood, meshr uses modern, audited cryptography to secure every link, so you get the security guarantees without having to hand-configure key exchange, routing tables, or firewall rules.

How It Works

The mechanics are simpler than the old model, not more complex.

When you join a device to the mesh, meshr creates a single encrypted network interface on that host — typically meshr0. That one interface is the device’s doorway into the entire network. From that point on, the device can reach every other peer through it.

curl -fsSL https://get.meshr.to/install.sh | sudo bash
meshr login
meshr up

Three commands, and the host is a peer. Behind the scenes:

Identity and keys. Each device generates its own key material and registers with the meshr control plane. You never copy keys around by hand.
Coordination, not relaying. A lightweight control plane tells each peer how to find the others — their addresses, their public keys, their reachability. This is just coordination metadata; your actual data traffic does not flow through it.
Direct connections first. When two peers want to talk, they attempt a direct encrypted connection, punching through NAT and firewalls automatically where possible. Your us-east-1 server talks straight to your eu-west server.
Relay as a fallback. When a direct path genuinely can’t be established (strict firewalls, symmetric NAT), traffic falls back to an encrypted relay so connectivity never just breaks. It stays end-to-end encrypted the whole way.

Once a device is up, you reach any peer the way you’d reach any normal host — by its mesh IP, or by name through split DNS:

ssh db-primary.meshr
curl http://metrics.meshr:9090
psql -h postgres.meshr -U app

No port forwarding, no security-group surgery, no jump hosts. The peer is simply on the network, addressable like it’s in the next rack.

When to Use a Mesh VPN

A mesh VPN isn’t only for one scenario. The flat-network model pays off anywhere your devices are scattered:

Multi-cloud infrastructure. Connect servers across AWS, GCP, Azure, and bare metal into one network without VPC peering, transit gateways, or BGP. Every host reaches every other host directly.
Remote and distributed teams. Give engineers secure access to internal services from anywhere, without trombone-routing all their traffic through a single office gateway.
IoT and edge devices. Sensors, kiosks, and edge boxes behind home routers or cellular NAT can join the mesh and stay reachable with a stable address, even when their underlying IP keeps changing.
SSH and remote access. Reach any server or device by name from your laptop. Add yourself to the mesh and ssh server.meshr works whether the box is in a datacenter or under someone’s desk.
Connecting environments that were never meant to talk. A legacy on-prem database and a brand-new cloud service can sit on the same flat network with a few minutes of setup instead of a multi-week project.

Anywhere the old answer was “set up another VPN gateway and figure out the routing,” a mesh VPN is usually the simpler, faster, and more resilient choice.

Access Control on a Flat Network

A flat network is convenient, but “everything can reach everything” is not what you want in production. A proper mesh VPN enforces access policy at the connection level, not by relying on the topology.

With meshr you group devices and write explicit allow rules:

Group production — the API and worker nodes
Group databases — your database hosts
Policy — allow production → databases on TCP 5432, deny everything else

Now the workers can reach the database, but if one worker is compromised, an attacker can’t pivot to your laptop, your metrics box, or anything else. The blast radius is bounded by the policies you set, not by luck. You get the convenience of a flat network with the safety of segmentation.

Get Started

A mesh VPN gives you what hub-and-spoke never could: direct, encrypted, device-to-device connectivity that scales with your infrastructure instead of fighting it. No central bottleneck, no fragile gateways, no months-long networking projects.

You can try it on a free meshr account. Install the agent on any two machines you have access to:

curl -fsSL https://get.meshr.to/install.sh | sudo bash
meshr login
meshr up

Within about 30 seconds they can reach each other by name — even if one is in a cloud region on another continent and the other is a laptop on hotel Wi-Fi.

Start free · Read the docs · See how meshr works

What Is a Mesh VPN? How Device-to-Device Networking Works