OpenVPN vs Zero Trust: Why the Perimeter Is Gone

“OpenVPN vs Zero Trust” is not really a fight between two products. It is a fight between two ideas about where trust lives. One says trust the network. The other says trust nothing until it proves itself. Understanding that difference is the whole point — the tooling follows from it.

Let’s walk through both, with pictures.

What OpenVPN Was Built For

OpenVPN is a battle-tested, open-source VPN protocol. It has secured remote access for two decades, and for good reason: it’s reliable, widely supported, and does exactly what it was designed to do — build an encrypted tunnel from a remote user into a private network.

The key phrase is into a network. Once the tunnel is up and you’ve authenticated, you are inside. The network treats you like any other machine on the LAN.

This is the “castle-and-moat” model. There’s a wall (the VPN gateway) with one guarded gate. Cross the gate and you can walk the whole castle: the database in the basement, the file share on floor 3, the admin panel, the CI server, the backups.

It worked beautifully when the world matched the assumption — a clear “inside” (the office) and a clear “outside” (the internet).

Where the Model Breaks

The assumption stopped being true. Today:

• Your engineers work from home, cafes, and airports.
• Your services run across two or three clouds, not one server room.
• Contractors need access to one specific thing for one week.
• Laptops get phished, passwords get reused, devices get lost.

In the castle model, a single compromised laptop is catastrophic. The attacker doesn’t get one room — they get the tunnel, and the tunnel gets them everything. This is, concretely, how a large share of real-world breaches escalate: initial foothold, then free lateral movement across a flat, trusted network.

OpenVPN isn’t broken. The perimeter is broken. There’s nothing left to draw a moat around.

What Zero Trust Changes

Zero Trust replaces one big trust decision with many small ones. Its entire philosophy fits in three words:

Never trust. Always verify.

Instead of “you’re on the VPN, so you can reach everything,” the question becomes: “Is this identity, on this device, allowed to reach this specific resource, right now?” Every connection is evaluated. Identity — not an IP address or network location — becomes the perimeter.

Four things change compared to the VPN model:

1. Every connection is verified, not just the initial login.
2. Access is granted per resource, not per network.
3. Identity is the perimeter (SSO/OIDC + device posture), not the subnet.
4. Every attempt is logged, so “who reached what, when” is always answerable.

A compromised laptop in this model reaches only what that user was explicitly entitled to — and every move it makes is on the record.

Side by Side

	OpenVPN (perimeter VPN)	Zero Trust (ZTNA)
Trust boundary	The network — once in, you’re trusted	The connection — re-checked every time
Access scope	The whole subnet	One host / port / protocol
Identity	Shared cert or credentials	Per-user SSO/OIDC + device posture
Blast radius of a stolen laptop	Entire internal network	Only that user’s granted resources
Contractor for a week	Full VPN account, hard to scope	Time-boxed policy to one service
Audit trail	”Connected to VPN at 14:03"	"user reached prod-db:5432 at 14:03”
Topology	Hub-and-spoke through a gateway	Direct, policy-gated peer connections

OpenVPN Isn’t “Wrong” — It’s a Different Era

If you have a single office, a single server room, and a stable set of employees, a perimeter VPN is a perfectly sensible tool. The problem is that almost nobody has that shape anymore. The moment your resources scatter across clouds and your people scatter across the map, the perimeter stops being a security control and starts being a liability — a flat, over-trusted space waiting for one bad click.

Zero Trust isn’t a heavier version of a VPN. It’s the opposite instinct: assume the network is hostile, and make every connection earn its access.

How meshr Does Zero Trust

A modern mesh VPN is a natural fit for Zero Trust, because it’s built on the pieces Zero Trust needs:

• Identity-based peers — every device authenticates via SSO/OIDC, not a shared secret.
• Per-connection encrypted tunnels — each pair of devices gets its own WireGuard tunnel; there’s no shared trusted subnet.
• Policy enforced at the edge — access rules are evaluated by the local agent, not funneled through one central gateway that becomes a chokepoint and a single point of failure.
• Complete audit logs — every connection attempt is recorded.

In meshr you write policies that read like the intent behind them:

Source:      group:engineering
Destination: group:prod-servers
Protocol:    tcp
Ports:       5432

That’s the difference in one block: not “engineering is on the VPN,” but “engineering can reach the Postgres port on prod-servers, and nothing else.” Everything unlisted is denied by default, and every attempt — allowed or blocked — lands in the audit log.

Moving From One to the Other

You don’t have to flip a switch. A practical migration looks like:

1. Inventory what’s actually reachable over your current VPN. The list is usually longer than anyone expects.
2. Map real access needs to groups — who genuinely needs which resource, and for how long.
3. Run mesh alongside the VPN, moving one service group at a time behind explicit policies.
4. Watch the audit logs to catch access nobody remembered granting.
5. Retire the flat tunnel once every path has a policy behind it.

Each step shrinks the blast radius. Even a partial migration — pulling your most sensitive systems behind per-connection policies — is a meaningful security win.

The Bottom Line

OpenVPN answers “how do I get a remote user onto the network?” Zero Trust answers a better question: “how do I let the right identity reach the right resource, and nothing more?”

The perimeter is gone. Zero Trust is what you build once you stop pretending it’s still there.

Want to see it in practice? Build a mesh for free and write your first per-connection policy in a few minutes, or read Zero Trust Network Access explained for a deeper dive on the model.