Documentation
An OpenVPN alternative: from central server to mesh
OpenVPN is a respected veteran: an open-source server-client VPN, proven by years of deployment. But its model means hosting and exposing a server, maintaining a PKI of certificates, and routing traffic through a central point. Looking for an OpenVPN alternative rarely means looking for "the same, but better": it usually means changing topology. This page gives an honest comparison of the server-client model and the VIGIL-MESH mesh model — direct connections encrypted with QUIC/TLS 1.3, zero inbound ports, zero certificates to manage yourself — and shows how to migrate without breaking anything.
What OpenVPN does well
Let's start by giving the original its due. OpenVPN is open source, studied and deployed for years, and it runs just about everywhere. Its model is crystal clear: a server that listens, clients that connect to it, a certificate authority that decides who gets in. When you want to host everything yourself, from the server to the certificates, it is a perfectly defensible choice.
- Battle-tested: years of production, an audited and extensively documented protocol.
- Open source end to end: the server, the clients and the PKI are yours, on your machines.
- Flexible transport: it runs over UDP or TCP (TLS), which helps on networks that only let TCP through.
- Full control over admission: your certificate authority signs — or revokes — every client.
What a mesh topology changes
A mesh VPN starts from a different premise: instead of funnelling every client toward a server, each machine becomes a peer of the network and talks to the others directly. Three chores of the server-client model disappear at once.
No server to host or expose
A server-client VPN needs a machine listening on a port reachable from the Internet: a port forward on the router, a stable address, a service exposed and scanned around the clock. With VIGIL-MESH, no node opens an inbound port: every machine establishes a single outbound flow on UDP 443, like a browser — including behind a home router, a corporate firewall or 4G/5G carrier-grade NAT.
No PKI to run yourself
The classic model relies on a certificate authority you create, and certificates you generate, distribute, renew and revoke. With VIGIL-MESH, each machine has an Ed25519 key identity and enrolls with a one-time key; revoking a member happens in the console and takes effect immediately. Nobody maintains a certificate authority.
Direct paths, not a central detour
In a hub-and-spoke layout, traffic between two machines climbs up to the server and back down: longer path, a server to size, a single point of failure. In a mesh, traffic goes directly machine to machine along the shortest path; while the direct path is not yet established, a blind relay — without the session keys — bridges the gap, then the session migrates over seamlessly.
Stable addresses and names
Each machine gets a stable address (in 100.64.0.0/10) that follows it across physical networks, and a short name via MagicDNS. Access policies (ACLs, deny by default) describe who may reach what, network by network.
Transport differences: QUIC versus OpenVPN
Beyond topology, the transport differs too. Every VIGIL-MESH session is a QUIC connection (TLS 1.3), the protocol that powers HTTP/3: encryption is built into the transport, and the session is identified independently of the IP address. The table compares facts, without value judgements.
| Criterion | VIGIL-MESH (QUIC) | OpenVPN |
|---|---|---|
| Topology | Mesh: peers with direct connections | Server-client (hub-and-spoke by default) |
| Transport | QUIC / UDP (TLS 1.3) | UDP or TCP (TLS) |
| Default port | UDP 443, like HTTP/3 | 1194 (configurable) |
| Looks like web traffic | Yes (like HTTP/3) | Partially (TLS) |
| Network or IP address change | Seamless session migration | Reconnection |
| Inbound port to open | None, anywhere | Yes, on the server side |
| Identities | Ed25519 keys per machine, one-time enrollment key | Certificates signed by your certificate authority |
| Post-quantum | Hybrid X25519 + ML-KEM768 by default | Not native |
Session migration deserves a word: when a laptop moves from Wi-Fi to 4G, the QUIC connection survives the address change — nothing reconnects, the traffic simply changes route. Transport details on /en/docs/vpn-quic, NAT traversal on /en/docs/vpn-sans-ouvrir-de-port.
Where OpenVPN remains the right fit
An honest page says it plainly: there are situations where OpenVPN remains the right choice, and where a mesh alternative would add nothing — or would take something away.
- You want full open-source control, end to end: with OpenVPN, the server, the clients and the PKI run entirely on your machines. With VIGIL-MESH, you can self-host the relay (a private vigie), but the control plane remains a managed service.
- You specifically want a central chokepoint: if your architecture requires all traffic to converge on a single point you operate, the server-client model does exactly that — it is its nature, not its flaw.
- Your network only lets TCP out: OpenVPN can run over TCP, whereas VIGIL-MESH relies on an outbound UDP 443 flow.
- Your PKI already exists and you intend to keep it: if the certificate authority is a deliberate part of your organisation, making it disappear is not a win.
Migrating gently, without breaking anything
The mesh operates at machine level, independently of your existing tunnel: both can coexist for as long as the transition takes. Enroll a few pilot machines first, verify the flows that matter, then expand — and decommission the OpenVPN server at whatever pace suits you.
- 1Create an account and a workspaceThis is the console's entry point: devices, networks and access policies are managed in one place. Free for personal use.
- 2Install the client on the machines involvedStart with a pilot scope: the server hosting the service and one or two machines that need to reach it. Clients are available for Windows, Linux, Android, NVIDIA Jetson and the browser.
- 3Enroll each machineIn the console: Networks → Machines → "Add a machine", then the one-time key on the machine itself. No certificate to generate, no certificate authority to create.
- 4Verify connectivityEach machine gets a stable address and a MagicDNS name: a ping between two peers is enough to confirm the mesh is up — while your OpenVPN tunnel keeps running alongside.
- 5Switch usage over, then decommissionReach services through the machine's stable address or name, just as on a local network. Once every use has moved to the mesh, the OpenVPN server can be switched off — and with it the exposed port and the PKI.