You manage 15 client networks. Each one has its own servers, its own workstations, its own security requirements. A support ticket comes in from Client A — you need to SSH into their file server. Ten minutes later, Client B calls with a printer issue and you need to access their internal dashboard.
With a traditional VPN, that means separate VPN configs for each client. Separate credentials. Maybe a folder full of .ovpn files or a spreadsheet tracking which client uses which IP range. It works until it doesn’t — until you accidentally connect to the wrong client network, or a technician leaves and you spend an afternoon rotating credentials across 15 different VPN gateways.
MSPs need something different from VPN solutions. You need multi-tenant isolation, fast switching between client environments, and the ability to onboard (and offboard) technicians without touching every client’s infrastructure.
What MSPs Actually Need from a VPN
Standard VPN guides target individual users or single-company teams. MSP requirements are fundamentally different:
Client isolation. Client A’s traffic and access should never touch Client B’s network. This isn’t just good practice; for clients in regulated industries (healthcare, finance), it’s a compliance requirement. Cross-client access is a liability.
Multi-tenant management. You need one control plane to manage access across all client networks. Logging into 15 separate dashboards to check connection status or update a policy isn’t sustainable.
Technician lifecycle. When you hire a new tech, they need access to the right client networks within hours, not days. When someone leaves, their access to every client network needs to die in one action. Anything slower than that is a security gap.
Granular permissions. Your Tier 1 helpdesk tech doesn’t need the same access as your senior infrastructure engineer. Within each client network, different technicians need different levels of access.
Audit trails. When a client asks “who accessed our network last Thursday at 3pm,” you need a real answer. Connection logs per client, per technician, with timestamps.
Option 1: NetBird (Best for Growing MSPs)
NetBird handles the multi-tenant problem cleanly. Each client gets their own network with isolated policies, and you manage everything from a single Control Center or through the API.
How It Works for MSPs
Per-client network segmentation. Create separate groups for each client’s infrastructure. Define policies that restrict each group to its own resources. Your tech connecting to Client A physically cannot reach Client B’s servers — the policy layer prevents it.
Identity-based access. Connect NetBird to your identity provider (Zitadel, Google Workspace, Azure AD). Technicians authenticate once through SSO. Their group membership determines which client networks they can reach.
Policy example for an MSP:
- Senior engineers: Access to all client networks, full port range
- Tier 2 support: Access to assigned client networks, SSH and RDP only
- Tier 1 helpdesk: Access to assigned client networks, RDP to workstations only
- Contractors: Access to one specific client, time-limited
Onboarding a new technician:
- Create their identity in your SSO provider
- Assign them to the right groups (client networks + permission level)
- They install the NetBird agent and authenticate
- Done. No VPN configs, no client-specific credentials, no firewall rules to update.
Offboarding:
- Disable their identity in the SSO
- They lose access to every client network instantly
That second step happens automatically. Disable the identity; NetBird enforces it. No hunting through 15 client VPN configs to remove their access.
API-Driven Management
For MSPs managing 20+ clients, the NetBird API opens up automation. You can script client onboarding: create groups, define policies, generate setup keys, and provision access programmatically. Pair this with your PSA or ticketing system and you can trigger access changes from service tickets.
# List all peers across your network
netbird api peers list
# Create a setup key for a new client deployment
netbird api setup-keys create --name "client-acme" --type reusable --expires-in 24h
For the full API and CLI reference, see our NetBird CLI and API guide.
Cost
NetBird’s free tier covers 5 users and 100 machines. For a small MSP with 3-4 techs and a handful of clients, this might be enough. Beyond that, paid plans scale with your user count. Self-hosting the management server eliminates per-user costs entirely, though you take on the hosting and maintenance.
Option 2: WireGuard + WG-Easy (Budget Option)
If you’re a solo MSP or a two-person shop, you might not need multi-tenant policies. A simple WireGuard server per client network gets the job done.
The Setup
Deploy a WG-Easy instance for each client (or one per client network segment). Each instance runs in Docker on the client’s server or on a cheap VPS:
docker run -d \
--name wg-client-acme \
-e WG_HOST=acme.yourmsp.com \
-e PASSWORD_HASH='$2a$12$...' \
-p 51820:51820/udp \
-p 51821:51821/tcp \
--cap-add=NET_ADMIN \
--restart unless-stopped \
ghcr.io/wg-easy/wg-easy
Each WG-Easy instance gives you a web UI for managing peer configs. Create a peer for each technician who needs access to that client.
When This Works
- Solo MSP or small team (1-3 techs)
- Fewer than 10 clients
- Simple access needs (connect/disconnect, no granular policies)
- Budget is the primary constraint
When This Breaks Down
- Offboarding. Technician leaves? You need to remove their peer from every client’s WG-Easy instance. With 10 clients, that’s 10 manual changes.
- No centralized view. You can’t see which technician is connected to which client from one dashboard.
- No identity integration. Each peer is a key pair, not a person. No SSO, no MFA at the VPN layer.
- No audit trail. WireGuard logs are minimal. You won’t easily answer “who accessed Client B’s network on Tuesday.”
For a deeper look at WireGuard deployment options, see our WireGuard setup guide.
Option 3: Headscale + Tailscale Clients (Tailscale Users)
If your team already runs Tailscale clients, Headscale lets you self-host the coordination server. You keep the Tailscale client experience but own the control plane.
MSP Considerations
ACLs for client isolation. Headscale supports Tailscale’s ACL format. Define tag-based policies to isolate client networks:
{
"acls": [
{"action": "accept", "src": ["group:tech-acme"], "dst": ["tag:client-acme:"]},
{"action": "accept", "src": ["group:tech-globex"], "dst": ["tag:client-globex:"]}
]
}
Limitation: Headscale’s multi-tenant story is less mature than NetBird’s. User management is more manual, there’s no built-in web UI (community options exist but lag behind), and the API surface is more limited. It works, but expect more YAML editing and CLI work.
Comparing MSP VPN Options
| Factor | NetBird | WG-Easy (per client) | Headscale |
|---|---|---|---|
| Multi-tenant isolation | Built-in policies | Separate instances | ACL-based |
| Central management | Control Center + API | None (per-instance) | CLI + community UI |
| SSO/OIDC | Yes | No | Yes |
| Technician onboarding | Add to group, done | Create peer per client | Create user, set ACLs |
| Technician offboarding | Disable identity | Remove from each instance | Disable user |
| Audit logging | Per-connection logs | Minimal | Connection logs |
| Self-hostable | Yes (full stack) | Yes | Yes |
| Best for | Growing MSPs (5+ techs) | Solo/small MSPs | Tailscale shops |
Pairing VPN with RMM
A VPN handles network connectivity. For endpoint management, monitoring, and remote support, you need an RMM alongside it.
The combination that works well for budget-conscious MSPs: NetBird for secure network access + TacticalRMM for endpoint management. Both are open source, both are self-hostable, and they complement each other without overlap.
NetBird gives your technicians secure access to client networks. TacticalRMM gives them visibility into what’s running on each endpoint, the ability to run scripts remotely, and alerting when something breaks. The VPN handles the “how do I get there” problem. The RMM handles the “what do I do when I arrive” problem.
Security Considerations for MSPs
MSPs are high-value targets. Compromise one MSP and you potentially access every client network they manage. The 2021 Kaseya attack proved this isn’t theoretical.
Zero-trust is not optional for MSPs. The traditional model — one VPN, broad access, trust the technician — is the exact attack surface that gets exploited. Identity-based access, least privilege, and per-client isolation aren’t enterprise luxuries. They’re baseline MSP hygiene.
Read our zero-trust networking guide for the implementation details.
Key practices:
- MFA on every technician account. No exceptions.
- Time-limited access for contractors and project-based work
- Separate admin credentials from day-to-day support credentials
- Review access logs monthly: who connected where, and was it expected?
- Offboard same-day. A departed technician with active VPN access is your biggest vulnerability.
Getting Started
If you’re an MSP currently juggling separate VPN configs per client:
- Deploy NetBird (or Headscale if you’re already on Tailscale clients). Connect it to your identity provider.
- Create client groups. One group per client network. Define policies for what each group can reach.
- Create technician tiers. Map your team’s roles to access levels. Senior engineers get broader access. Helpdesk gets targeted access.
- Migrate one client at a time. Start with your most-accessed client network. Install NetBird agents on their key servers. Test access through NetBird while keeping the old VPN as fallback.
- Roll out to all clients once the pattern is proven. Decommission the old VPN configs.
The migration doesn’t need to be a big-bang cutover. Run both systems in parallel until you’re confident, then switch.
For the full landscape of self-hosted VPN options, see our complete guide to self-hosted VPN solutions in 2026.