Engineering

Mesh networking shouldn’t require a PhD in routing tables

How we made every device on your network just work — without forwarding a single port.

I spent two weeks last January staring at iptables rules on a rented VPS, trying to get my laptop in a Toronto coffee shop to reach my home NAS. Every option felt either enterprise-heavy or brittle, and that frustration shaped Meshlink's control plane.

The three-second connection

When someone runs meshlink up for the first time, it should feel like joining Wi-Fi: no subnet math, no firewall punching, no IP forwarding checklist. The control server assigns a 100.x.x.x address, exchanges keys, and your device joins the mesh.

A VPN you can't inspect is a VPN you can't trust. We open-sourced every line of the Meshlink client on day one because security software gains adoption through transparency.

Why we open-sourced the client

The trick was moving all the complexity out of the user's hands and into a centralized coordination server. Every node talks to the control plane, which distributes an encrypted map of the entire network. NAT traversal and relay fallback are handled silently. The user sees one green dot.

If a sysadmin at a hospital can't audit what's running on their network, they won't deploy it. That's not ideology — it's procurement reality. Publishing the client source was the single highest-leverage decision we made for adoption, above any feature or partnership. It changed the sales conversation from “trust us” to “verify us,” and that shift made all the difference.