The traditional small-office remote access setup: a VPN server on the firewall, a forwarded port, a client on every laptop, and a support burden that arrives every time someone’s home ISP changes something.
WireGuard-based mesh overlays — Tailscale, Netbird, Headscale, or plain WireGuard if you enjoy maintaining config — have made that architecture largely unnecessary for businesses under a few hundred users. Worth understanding why, and where the old model still wins.
What actually changes
No inbound port. Mesh clients establish outbound connections to a coordination service and NAT-traverse to each other. There is no listening port on your perimeter, which removes an entire class of exposure: nothing to scan, nothing to brute-force, nothing to be caught by a VPN appliance CVE. Given the last few years of critical vulnerabilities in exactly those appliances, this is not a small point.
Identity instead of network location. Access is tied to a user in your existing SSO — Google Workspace, Microsoft 365 — not to whoever holds a shared key. Someone leaves, you disable the account, and their access is gone everywhere at once. Compare that to rotating a pre-shared key across every remaining user.
Direct paths. Traffic goes peer-to-peer where NAT allows, falling back to a relay only when it must. A laptop in Whitefield reaching a server in the office takes the direct route rather than hairpinning through a concentrator.
Per-service access, not “you’re on the network now.” The traditional VPN drops the user onto the LAN, and from there they can reach everything the LAN can reach. Mesh overlays let you grant one user access to one server on one port. That’s the same default-deny principle as network segmentation, applied to remote users.
Where it doesn’t fit
Be honest about these:
- You need a specific client for compliance reasons. Some contracts and some auditors name the technology. Argue if it’s worth arguing; otherwise the requirement is the requirement.
- You depend on a coordination service you don’t run. The hosted control planes are reliable and they only handle key exchange, not your traffic — but it’s a dependency, and for some organisations that’s disqualifying. Self-hosting the coordinator (Headscale, Netbird’s server) removes it, at the cost of running it.
- Broadcast-dependent legacy applications. Old line-of-business software that expects to discover a server by broadcast on the local subnet will not work over an overlay, and usually can’t be made to. This is the most common practical blocker in Indian small businesses, where a surprising amount of accounting and inventory software still works this way.
- Site-to-site with heavy throughput. Mesh handles this, but a plain WireGuard tunnel between two known endpoints is simpler and one less moving part when both ends are fixed.
Practical notes from running it
A few things worth knowing before you deploy:
- Set up key expiry deliberately. Default key rotation will disconnect an unattended server at an inconvenient moment. Machines that must stay reachable need their keys marked non-expiring, consciously, with a note about why.
- Advertise routes rather than installing clients everywhere. A single subnet router in the office exposes the printer, the NAS and the legacy appliance to the mesh without putting an agent on each. This is usually the fastest path to “it works.”
- Decide about exit nodes explicitly. Routing all internet traffic through the office is occasionally what you want and usually not — it costs bandwidth and adds latency for no security benefit if the destination is already HTTPS.
- Watch DNS. Split-horizon setups where internal names must resolve differently over the overlay are where most of the confusing failures come from.
For a business under a few hundred people that mostly needs “our staff can reach our server from home, securely, without me maintaining a VPN appliance,” a mesh overlay is now the sensible default and the old model needs a specific justification.