The Open Source Path from VPN Sprawl to Zero Trust Access Source

1---
2title: "The Open Source Path from VPN Sprawl to Zero Trust Access"
3date: "2026-05-06"
4published: true
5tags: ["pangolin", "zero-trust", "ztna", "vpn", "tailscale", "headscale", "twingate", "kasm", "teleport", "access-control", "network-security"]
6author: "Gavin Jackson"
7excerpt: "My hands-on evaluation of Pangolin Community Edition as a possible production access layer for a small multi-team environment, including Enterprise Edition features and comparisons with Headscale, Tailscale, and Twingate."
8---
9
10# The Open Source Path from VPN Sprawl to Zero Trust Access
11
12![Pangolin logo](/assets/pangolin-logo.png)
13
14I have been spending time with **Pangolin** recently, using the open source Community Edition as a hands-on evaluation path for a possible production deployment of around 50 users across multiple teams.
15
16That framing matters.
17
18This is not a "global enterprise with thousands of users" deployment story, but it is also not just a hobby network exercise. My current use is small-scale because that is the best way to understand the product properly. The question I am really testing is whether Pangolin has the right shape for a modest production environment where different teams need different levels of access.
19
20The practical questions are:
21
22- Can we expose internal services safely?
23- Can we stop opening awkward firewall holes for individual applications?
24- Can users get access to the resources they need without receiving broad VPN routes?
25- Can different teams be given different access without turning firewall policy into archaeology?
26- Can the setup stay understandable enough that we will still trust it six months from now?
27
28So far, Pangolin sits in a very useful middle ground. It is not just another reverse proxy, and it is not just another VPN. It combines identity-aware web access with client-based private access, which makes it feel more like a practical zero trust access layer than a traditional "connect to the network and hope for the best" VPN.
29
30## The old VPN habit
31
32Traditional VPNs solved a real problem: "I am outside the network, but I need to reach something inside it."
33
34The classic answer was:
35
361. Put a VPN concentrator on the edge.
372. Authenticate the user.
383. Drop that user onto an internal IP range.
394. Use firewall rules to decide what the VPN subnet can reach.
40
41That worked well enough when the network perimeter was clear and most important systems lived inside it. But it also created a security habit that has aged badly: once a user is on the VPN, they often become network-adjacent to far more than they actually need.
42
43Even when you tighten the firewall, the model is still subnet-first:
44
45- VPN users can reach this VLAN.
46- Admin VPN users can reach that management subnet.
47- Contractors get a smaller subnet.
48- Exceptions accumulate because one person needs one port on one host.
49
50Over time the firewall rule base becomes a historical document of every temporary access decision that became permanent.
51
52Zero trust networking asks a better question: **what exact resource should this user, role, device, or service be allowed to reach right now?**
53
54That is the shift.
55
56## Where Pangolin fits
57
58Pangolin describes itself as an open source, identity-based remote access platform built on WireGuard. The useful part is the combination of two access patterns in one place:
59
60- **Public resources** for browser-based access to web applications.
61- **Private resources** for client-based access to specific hosts, ports, or network ranges.
62
63The public resource model is what you would expect from an identity-aware reverse proxy. A user opens a URL, authenticates, and Pangolin brokers access to the backend service. That is a natural fit for things like:
64
65- Kasm Workspaces
66- observability dashboards
67- internal documentation
68- Git services
69- internal admin portals
70- business web apps that should not be naked on the internet
71
72The private resource model is closer to a zero trust VPN. A user installs a Pangolin client, authenticates, and can then reach only the private resources their identity is allowed to access. This is where SSH, databases, RDP, VNC, internal APIs, or non-HTTP services come into play.
73
74The key difference from a normal VPN is that the unit of access is not "the private network." The unit of access is the resource.
75
76In Pangolin terms, those resources live behind **sites**. A site is the connection into the network where your services live. In the common deployment, the Newt connector runs inside that network and establishes outbound connectivity back to Pangolin. That means the private side can stay behind a firewall, NAT, or CGNAT without exposing inbound ports directly to the internet.
77
78That is the part I like most for production evaluation. It changes the default posture from:
79
80```text
81Internet -> open port -> service
82```
83
84to:
85
86```text
87Internet -> Pangolin -> authenticated resource -> outbound tunnel -> service
88```
89
90The service is no longer the thing negotiating with the open internet. Pangolin becomes the access broker.
91
92## Zero trust networking, minus the slogans
93
94Zero trust is an abused phrase, but the underlying idea is very practical.
95
96NIST SP 800-207 frames zero trust as a move away from static, network-based perimeters toward protecting users, assets, and resources. The important bit is that network location should not grant implicit trust. Being "on the LAN" or "on the VPN" should not be enough.
97
98For networking, that translates into a few very concrete design choices.
99
100### 1. Authenticate before access
101
102The user should prove who they are before the resource is reachable.
103
104With a conventional VPN, authentication gets the user onto the network. After that, many applications still rely on their own credentials, host firewalls, or private IP obscurity. In a zero trust access pattern, the access layer asks:
105
106- Who is the user?
107- Which role or group are they in?
108- Which device or client are they using?
109- Which resource are they trying to reach?
110- Is that resource allowed for this identity?
111
112That check happens before the session is established.
113
114### 2. Authorize the resource, not the subnet
115
116This is where fine-grained access control becomes real.
117
118Instead of allowing a VPN pool to reach `10.10.20.0/24`, you define access to the thing a person needs:
119
120- `proxmox.example.net` for an infrastructure admin role
121- `kasm.example.net` for isolated browsing
122- `grafana.internal` for an operations role
123- `db.internal:5432` for a service or admin role
124- `ssh://linux-host` only for the people who administer it
125
126That sounds like a small distinction. It is not. It changes how you reason about risk.
127
128If a laptop is compromised, the attacker does not automatically inherit a flat route into everything behind the VPN. They inherit whatever that identity and device can reach.
129
130### 3. Make the default deny visible
131
132Good zero trust systems make denial boring.
133
134If a user has no policy for a resource, the answer should simply be no. Pangolin's resource model fits this well: a site being online does not automatically expose the network. An administrator still has to define resources and grant access.
135
136That default matters because it lets you add connectors without accidentally publishing entire environments.
137
138### 4. Keep access close to identity
139
140Firewall rules are still important, but firewalls do not know enough about human context on their own. A firewall can usually tell you source IP, destination IP, port, and protocol. It may not know that the source represents Gavin on a trusted laptop trying to access Kasm after MFA.
141
142Zero trust access brokers bring that identity context closer to the network decision.
143
144This is why ZTNA products have become popular. The access decision is no longer just "can this IP reach that IP?" It becomes "can this identity reach this resource under this policy?"
145
146### 5. Reduce lateral movement
147
148The best firewall rule is the one you never had to create.
149
150If users only receive explicit access to specific resources, lateral movement becomes harder. An attacker who lands on one endpoint still has to fight through identity checks, client authorization, resource policy, and whatever application-level controls exist beyond that.
151
152That is not magic. It is blast-radius reduction.
153
154## How this simplifies firewall rules
155
156Pangolin does not remove the need for firewalls. I would not trust any product that made that promise.
157
158What it can do is simplify the shape of the firewall problem.
159
160In a conventional remote access design, you often end up with rules like:
161
162```text
163VPN subnet -> management subnet -> TCP 22, 443, 8006
164VPN subnet -> server subnet -> TCP 443, 5432, 3306
165VPN subnet -> storage subnet -> TCP 445, 2049
166contractor VPN subnet -> app subnet -> TCP 443
167```
168
169Then the exceptions arrive:
170
171```text
172temporary vendor VPN -> one host -> one port
173temporary admin VPN -> all lab hosts -> SSH
174legacy user VPN -> file share -> SMB
175```
176
177With Pangolin, the edge firewall can often become much simpler:
178
179- allow the Pangolin server to receive the public traffic it needs
180- allow site connectors to make outbound connections to Pangolin
181- keep the private network closed to inbound internet traffic
182- allow the connector to reach only the backend targets it is meant to publish
183
184On the inside, you still use host firewalls, segmentation, and egress controls. But you do not have to publish broad VPN routes just so one user can reach one service.
185
186That is the practical win: **fewer network-wide exceptions, more resource-level intent.**
187
188> **The VPN Support Tax**
189>
190> One of the least glamorous costs in remote access is not licensing. It is support.
191>
192> In one environment I worked with, the largest support cost from the MSP was user support around **WatchGuard VPN links**. That is not a criticism of WatchGuard specifically; it is a pattern I have seen across several engagements. Once client VPN becomes the default access method, the operational burden starts to sprawl.
193>
194> Someone has to:
195>
196> - build VPN profiles for different user groups
197> - distribute client installers and configuration bundles
198> - help users through certificate, password, MFA, and profile issues
199> - diagnose split-tunnel, DNS, route, and local network conflicts
200> - support client behaviour across Windows, macOS, and mobile devices
201> - maintain access exceptions as teams and applications change
202> - remove or rotate access when staff, contractors, or vendors leave
203>
204> That work does not always look dramatic on an architecture diagram, but it shows up in tickets, escalations, delays, and user frustration. It also scales poorly. Each new team, contractor group, or application tends to create another access profile, another firewall exception, or another slightly different set of instructions.
205>
206> The more painful part is that you still do not necessarily get fine-grained access control at the end of it.
207>
208> A traditional client VPN often answers the wrong question. It answers "can this user join this network?" when the better question is "can this user reach this specific resource?" You can tighten that with firewall rules, but then you are paying for complexity in a different place. The VPN profile gets the user near the network, and the firewall rule base becomes the real access policy.
209>
210> That is not sustainable for many small and mid-sized environments.
211>
212> Pangolin and its zero trust peers change the shape of the support problem. You still have administration to do, and private resource clients still need care, but the model becomes more resource-centric:
213>
214> - web applications can be exposed through an authenticated browser path
215> - private resources can be granted by role instead of broad subnet reachability
216> - team access can be changed in the access layer rather than by redistributing VPN profiles
217> - firewall rules can become simpler and more stable
218> - users can be denied access to everything they were never meant to see
219>
220> That is the operational argument for ZTNA that often lands harder than the security slogan. It is not just "zero trust is more secure." It is "the old VPN operating model is expensive to keep alive, and it still gives you a blunt access control tool."
221
222## Community Edition is a good proving ground
223
224For evaluation, Pangolin Community Edition is the interesting part of the story.
225
226As of 6 May 2026, Pangolin's own documentation says Community Edition is AGPL-3 compliant and includes the core Pangolin features. In practice, that gives you enough to test the access model properly:
227
228- self-hosted control
229- public web resources
230- private resources through the Pangolin client
231- sites and outbound tunnels
232- role-based access to resources
233- an identity-aware front door for internal services
234
235That is enough to replace a lot of casual VPN usage and, more importantly, enough to validate whether the access pattern fits your environment.
236
237For my purposes, the appeal is that I can think in terms of "which service should be reachable?" instead of "which subnet should I route?" That is a cleaner mental model before you even get to the commercial features.
238
239At around 50 users across multiple teams, the important questions quickly move beyond "does the tunnel work?"
240
241They become:
242
243- How will identity provider integration work?
244- Can roles map cleanly to teams and responsibilities?
245- How are new devices approved or denied?
246- Who can change resources and how is that audited?
247- What happens when the access layer is down?
248- Can operators see failed resources, unhealthy sites, and policy changes quickly?
249
250That is where the Enterprise Edition feature set becomes much more relevant.
251
252## What Enterprise Edition adds
253
254The Enterprise Edition story is worth calling out because Pangolin's Community Edition is not the whole feature set.
255
256As of 6 May 2026, the self-hosted Enterprise Edition is a separate image, distributed under the Fossorial Commercial License, and requires a license key. Pangolin's licensing page says individuals and small businesses below $100,000 USD gross annual revenue can use Enterprise features at no cost, but still need a valid key. Larger businesses need a paid license.
257
258The important point: **Enterprise is not a different core product so much as the operationally mature version of the product.**
259
260The enhanced features that stand out are:
261
262| Area | Enterprise capability | Why it matters |
263|------|------------------------|----------------|
264| Identity | Organization-scoped identity providers, built-in Google and Azure Entra ID options, and multiple roles per user | Better fit for real organizations with multiple teams, tenants, and role mappings |
265| Device trust | Device approvals | Lets admins approve new client devices before they can access resources |
266| SSH | Built-in certificate-based SSH access | Removes long-lived SSH key handling and gives short-lived, identity-bound access |
267| Resource publishing | Wildcard public resources | Useful for Kubernetes ingress, nested reverse proxies, or app platforms with many hostnames |
268| Audit | Action logs for administrative changes | Helps answer who changed what and when |
269| Alerting | Alert rules for sites, resources, and health checks | Turns access infrastructure into something operators can monitor properly |
270| MFA | Organization-level 2FA enforcement for internal users | Helps enforce stronger authentication where users are Pangolin-managed |
271| User experience | Branding and maintenance pages | Useful when users depend on the platform and need clear failure states |
272| Resilience | Clustering for high availability | Required when Pangolin becomes production access infrastructure rather than a single-node convenience |
273
274That is a sensible split.
275
276Community Edition gives you the core access model. Enterprise Edition adds the controls that matter when the platform becomes shared infrastructure: stronger identity integration, device governance, auditability, operational alerting, certificate-based SSH, and high availability.
277
278For a small production environment, I would treat those as evaluation criteria rather than nice-to-have extras. Community Edition can prove the access model; Enterprise Edition is where Pangolin starts to look like shared operational infrastructure.
279
280## Quick comparison: Headscale, Tailscale, Twingate
281
282Pangolin overlaps with several tools, but it is not a clone of any one of them.
283
284| Tool | Best description | Where it shines | Where Pangolin feels different |
285|------|------------------|-----------------|--------------------------------|
286| **Headscale** | Self-hosted implementation of the Tailscale control server | Self-hosted mesh networking using Tailscale clients | Headscale is about controlling a tailnet; Pangolin is more resource-publishing and identity-aware proxy plus ZTNA |
287| **Tailscale** | Managed WireGuard-based mesh connectivity platform | Peer-to-peer device connectivity, subnet routing, low-friction setup, excellent clients | Tailscale is brilliant for connecting devices; Pangolin feels more natural when the main job is publishing specific internal apps behind an auth layer |
288| **Twingate** | Commercial ZTNA platform | Polished enterprise VPN replacement with resource-level access, connectors, device policies, and SaaS management | Twingate is the mature commercial path; Pangolin is attractive when self-hosting and open source control matter |
289
290### Headscale
291
292Headscale is the right comparison if your main desire is a self-hosted Tailscale-style control plane.
293
294It is excellent when you want control of the coordination server while still using the familiar Tailscale client ecosystem.
295
296That client compatibility is a real advantage. Headscale aims to support recent official Tailscale client releases across the major platforms, so a self-hosted control plane does not necessarily mean giving up the polished commercial Tailscale client experience.
297
298But Headscale is not trying to be an identity-aware reverse proxy for web applications. It is a mesh networking control plane. That makes it a better fit when the problem is "connect my devices securely" rather than "publish these services through authenticated resource policies."
299
300### Tailscale
301
302Tailscale is still the benchmark for making WireGuard-based connectivity feel easy.
303
304It gives you a mesh network, strong client support, subnet routers, exit nodes, ACLs, and now grants for more expressive policy. If I want to connect laptops, servers, phones, cloud workloads, and branch resources with minimal fuss, Tailscale is hard to beat.
305
306The trade-off is control plane trust. Tailscale is managed. For most people that is a feature, not a bug. For people who want self-hosted infrastructure as a design requirement, it is a consideration.
307
308Pangolin also feels more app-front-door oriented. If I want `photos.example.net`, `kasm.example.net`, or `admin.example.net` behind login without users thinking about a mesh network, Pangolin maps more directly to that problem.
309
310### Twingate
311
312Twingate is probably the closest conceptual competitor for the ZTNA side.
313
314It is resource-oriented, denies access by default, uses connectors in private networks, and gives users access to authorized resources without exposing those resources publicly. It has a strong enterprise story around identity providers, device posture, audit, policy, and operational maturity.
315
316If I were buying for a company that wanted a supported, polished, commercial VPN replacement, Twingate would absolutely be on the shortlist.
317
318Pangolin's appeal is different: open source Community Edition, self-hosting, and a combined public-resource plus private-resource model that works nicely when you want direct control of the access layer.
319
320## The Clean Room Pattern: Pangolin, Kasm and Teleport
321
322This is where Pangolin gets especially interesting.
323
324I have written before about [building secure cross-domain solutions with Kasm and Teleport](/post/cross-domain-solutions-kasm-teleport), and I also called out [Kasm as a practical isolation control in the Essential Eight user application hardening article](/post/essential-eight-linux-user-application-hardening).
325
326Pangolin fits neatly into that same pattern.
327
328Think about the layers:
329
330- **Pangolin** is the front door for selected services and private resources.
331- **Kasm** is the clean room where risky browsing or isolated work happens.
332- **Teleport** is the privileged access layer for SSH, Kubernetes, databases, and administrative sessions.
333
334That gives you a powerful architecture:
335
336```text
337User
338  -> Pangolin authenticated public resource
339    -> Kasm workspace
340      -> isolated browser or desktop
341        -> internal app, research target, or admin portal
342
343User
344  -> Teleport
345    -> short-lived privileged access
346      -> SSH, Kubernetes, database, or application session
347```
348
349There are a few good ways to combine them.
350
351### Put Kasm behind Pangolin
352
353Kasm is browser-delivered, so it is a natural Pangolin public resource.
354
355Instead of exposing Kasm directly, publish it through Pangolin and require authentication at the edge. Then use Kasm's own controls for the workspace:
356
357- no downloads for high-risk browsing
358- no uploads where data leakage matters
359- no clipboard for sensitive domains
360- disposable sessions for unknown sites
361- separate workspace images for different trust levels
362
363That gives you a clean split: Pangolin controls who can reach Kasm, Kasm controls what the session can do.
364
365### Keep Teleport as the admin lane
366
367Teleport should not disappear just because Pangolin exists.
368
369Pangolin is excellent for brokering network access to resources. Teleport is still stronger when the problem is privileged administrative access with short-lived credentials, session recording, approvals, and deep audit trails.
370
371That is why I would keep Teleport as the admin lane for Linux-heavy environments, as discussed in the [restricted administrative privileges article](/post/essential-eight-linux-restrict-administrative-privileges).
372
373For example:
374
375- Pangolin publishes the Kasm manager or internal admin web UI.
376- Kasm provides disposable workspaces for risky browsing and separated workflows.
377- Teleport brokers SSH, Kubernetes, and database access with stronger privileged access controls.
378
379You do not have to force one tool to do every job. The architecture is cleaner when each layer has a purpose.
380
381### Use Pangolin to reduce exposed management surfaces
382
383The best immediate win is boring and valuable: stop putting management UIs directly on the internet.
384
385Put these behind Pangolin:
386
387- Kasm
388- Grafana
389- Proxmox
390- Home Assistant
391- Portainer
392- internal documentation
393- operations dashboards
394
395Then put SSH, Kubernetes, and database administration behind Teleport where session-level audit and privileged access controls matter more.
396
397That is a practical zero trust pattern for a small production environment: publish user-facing management surfaces through Pangolin, keep privileged administration in Teleport, and use Kasm where browser or workspace isolation is the point.
398
399## A few cautions
400
401Pangolin is moving quickly, so I would treat dated feature lists with care. The Community versus Enterprise split in this article is based on the published documentation I checked on 6 May 2026.
402
403I would also be careful with raw TCP/UDP public resources. Pangolin's docs note that protocol-aware HTTPS resources can use identity and context policies, while raw public TCP/UDP resources are not protocol aware in the same way. For most non-web services, private resources through the client are the cleaner zero trust pattern.
404
405And finally: do not let the access broker become the new unprotected crown jewel.
406
407For a self-hosted Pangolin deployment:
408
409- patch it
410- back it up
411- protect the admin account
412- enforce MFA where available
413- keep the host firewall tight
414- monitor access logs
415- document what each published resource is for
416
417Zero trust is not a product you install. It is a discipline you make less painful with the right product.
418
419## The bottom line
420
421Pangolin is compelling because it gives smaller production environments a practical path away from broad VPN habits.
422
423Community Edition is already enough to make private services cleaner to expose and easier to reason about. For a 50-user multi-team deployment, Enterprise Edition is where the operational story becomes more serious: stronger identity integration, device approvals, SSH certificates, audit logs, alerting, wildcard resources, branding, maintenance pages, and clustering.
424
425Compared with Headscale, Pangolin is less about owning a Tailscale-style mesh control plane and more about publishing resources safely. Compared with Tailscale, it is less device-mesh-first and more application-front-door-first. Compared with Twingate, it is less polished commercial ZTNA and more self-hosted open source access platform.
426
427That is a nice niche.
428
429For a small production rollout, Pangolin gives me the thing I actually want to evaluate: fewer exposed services, fewer broad VPN routes, and a clearer answer to the question "who can reach what?"
430
431## References
432
433- [Pangolin introduction](https://docs.pangolin.net/)
434- [Pangolin resources](https://docs.pangolin.net/manage/resources/understanding-resources)
435- [Pangolin sites](https://docs.pangolin.net/manage/sites/understanding-sites)
436- [Pangolin system architecture](https://docs.pangolin.net/development/system-architecture)
437- [Pangolin vs. reverse proxy vs. VPN](https://docs.pangolin.net/about/pangolin-vs-reverse-proxy-vs-vpn)
438- [Pangolin Enterprise Edition](https://docs.pangolin.net/self-host/enterprise-edition)
439- [Pangolin identity providers](https://docs.pangolin.net/manage/identity-providers/add-an-idp)
440- [Pangolin device approvals](https://docs.pangolin.net/manage/access-control/approvals)
441- [Pangolin SSH access](https://docs.pangolin.net/manage/ssh)
442- [Pangolin action logs](https://docs.pangolin.net/manage/analytics/action)
443- [Pangolin alert rules](https://docs.pangolin.net/manage/alerting/alert-rules)
444- [Pangolin clustering](https://docs.pangolin.net/self-host/advanced/clustering)
445- [NIST SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final)
446- [Headscale documentation](https://docs.headscale.org/)
447- [Headscale client support](https://headscale.net/stable/about/clients/)
448- [Tailscale: What is Tailscale?](https://tailscale.com/docs/concepts/what-is-tailscale)
449- [Tailscale grants](https://tailscale.com/docs/features/access-control/grants)
450- [Twingate resources](https://www.twingate.com/docs/resources/)
451- [Twingate architecture](https://www.twingate.com/docs/how-twingate-works/)
452