Traditional VPN vs VPNnet
A good VPN starts with the right design for your people, applications and networks. Here is how a typical gateway deployment compares with the mesh approach behind VPNnet.
Typical gateway architecture
The same 12 employee computers connect through one or more VPN gateways to approved resources. Gateway policy can also separate employees, services and support. Central forwarding and granular access are compatible.
Payload path: employee computer → VPN gateway → company resource. Support sessions follow the configured gateway and access rules.
VPNnet, built on NetBird
The same company can use direct permitted peer paths, with a separate coordinating controller and encrypted relay fallback. Inspect the three connection diagrams below; mesh capability does not require all-to-all permissions.
Follow the actual connections
Lines show permitted connections, not a measurement of active tunnels. Connections may be established on demand; direct connectivity is preferred, with encrypted relay fallback when needed. These are illustrations, not live policy changes.
Every employee computer has a permitted link to each of the other eleven. All 66 unique links are drawn. No HQ gateway is included in this diagram.
Solid green: employee mesh linksDashed charcoal: explicit HQ links
Each employee: 11 other employee peers. Total enrolled peers shown: 12.
Each employee computer has one permitted link to the additional HQ gateway. There are no employee-to-employee links. Traffic for HQ resources follows the gateway path.
Solid green: employee mesh linksDashed charcoal: explicit HQ links
Each employee: 1 HQ peer. HQ: 12 employee peers. Total enrolled peers shown: 13.
Each four-computer group has all six internal links, for eighteen total. Every one of the twelve employee computers also has its own direct permitted link to the additional HQ gateway. There are twelve HQ links and thirty links overall. No employee-to-employee links connect different groups.
Solid green: employee mesh linksDashed charcoal: explicit HQ links
Each employee: 3 peers within its group + 1 HQ peer. HQ: 12 employee peers. Total enrolled peers shown: 13.
Fred’s computer could reach accounting HTTPS on port 443; Bill’s could reach NMS HTTPS on port 443 and selected printing LAN resources using required printing protocols. These are more granular policy examples, not extra links silently added to the diagrams. A gateway can reach printers or an internal AD/domain controller without installing a client on each resource. AD needs appropriate DNS, routes and service ports; network access does not replace OS or application authentication.
A designated support group can have explicit permitted connections to employee computers. Such support peers may have many allowed peers. Relevant joins and policy changes are distributed through Management updates; permitted peers differ from active connections. This does not promise directory synchronization. Home full mesh remains a proposed preset, not a live enforced tier restriction.
References: NetBird access policies and allow-rule behavior.
The practical differences
Typical traditional VPN
A common design sends private traffic through a VPN gateway. Split tunneling can leave other internet traffic local, and larger deployments can use multiple gateways.
VPNnet mesh approach
Authorized peers prefer direct encrypted paths. Management coordinates identity and policy separately. A fallback relay forwards encrypted payloads when a direct path cannot be established.
Typical traditional VPN
A gateway can be a dedicated appliance, virtual machine or hosted service. Isolation depends on the chosen deployment.
VPNnet mesh approach
Our design uses a separate controller VM and control plane for each company. That is virtual-instance isolation, not a claim of dedicated physical hardware.
Typical traditional VPN
Reachability and performance depend on gateway placement, capacity, client configuration and the surrounding network.
VPNnet mesh approach
Direct paths can avoid central forwarding, but they are not guaranteed. NAT restrictions, relay paths, endpoint capacity and internet links all affect performance. Mesh is not a promise of superior speed.
Typical traditional VPN
Full-tunnel access can send configured internet traffic through a gateway and its separately configured security tools.
VPNnet mesh approach
A customer-owned peer can provide an exit route through the customer connection. Existing firewall or DNS-filtering tools need their own setup; filtering is not added merely by enabling the exit route.
Typical traditional VPN
Well-designed VPNs can use strong authentication, MFA, device checks and granular policy. Traditional does not mean insecure.
VPNnet mesh approach
NetBird provides identity-aware access controls and encrypted mesh connections. VPNnet builds on those capabilities; enrollment, application authentication and least-privilege policy still need care.
Typical traditional VPN
Your team or provider maintains gateways, clients, routing, authentication and availability according to the service arrangement.
VPNnet mesh approach
The intended offering separates company-controller operations from your device, LAN and policy responsibilities. Self-service support and separately scoped white-glove work serve different needs.
Typical traditional VPN
Forwarded traffic uses gateway connectivity. Hosting limits and internet transit costs depend on where gateways run.
VPNnet mesh approach
Peer-to-peer payloads normally avoid the controller. Customer exit traffic uses their internet link, while any hosted relay leg still consumes hosting transfer and relay capacity.
Questions worth asking
No. Routing peers are useful for reaching LAN resources that cannot run a client, and exit gateways provide a chosen route to the internet. Mesh changes the available traffic paths; it does not make routing design disappear.
Our focus is private access to your resources and company networks. A customer-owned exit gateway can use that customer’s public IP. We are not promising a worldwide catalog of VPN exit locations.
No. Client routes, DNS, IPv6, policy and failure behavior need verification. Gateway filtering is separately configured software, and HTTPS inspection requires additional setup.
VPNnet is in early access. The examples describe standard NetBird capabilities and our intended dedicated-controller offering. Automated company provisioning and custom appliance features remain planned. Deployment and support scope are agreed separately.
Read how VPNnet works, or consult the underlying NetBird architecture and exit-node documentation.
A practical conversation
Bring your requirements, including the systems you already run. We will discuss fit, responsibilities and early-access scope without assuming every network needs the same answer.
For current Alpha scope and clearly marked future services, see VPNnet offerings and availability.