How Pangolin Works
Pangolin is a zero-trust access platform that provides secure, identity-centric access to applications and infrastructure - without opening firewall ports or deploying traditional VPNs. Let's walk through how the system works.
Pangolin is a zero-trust access platform that provides secure, identity-centric access to applications and infrastructure - without opening firewall ports or deploying traditional VPNs. Let's walk through how the system works: the control plane, how you connect networks and define resources, and how policy is enforced for users and devices. The result is a single platform for both web application access and private (VPN-style) access, with centralized policy, full auditability, and support for hybrid and multi-cloud environments.
Pangolin delivers zero-trust network access (ZTNA) for workforce and machine identity: users and systems only reach the applications and hosts you explicitly allow, based on identity, role, and context. Public resources provide secure web access to internal and SaaS applications via identity-aware reverse proxy. Private resources provide least-privilege access to specific hosts and network segments through an optional client. A unified policy model and integration with your identity provider (IdP) lets you manage access once and enforce it everywhere.
Let’s walk through the architecture and key concepts from the ground up:
Pangolin separates control plane and data plane. The Pangolin server is the control plane: it handles authentication, stores access policies, and coordinates authorization. It does not sit in the path of user or machine traffic. The data plane is made up of sites (connectors in your networks) and clients (on user devices or machines). Sites run a WireGuard peer; clients authenticate and then connect directly “peer-to-peer” to the appropriate sites to reach authorized resources. This gives you centralized policy and governance without a single choke point for traffic.
Access is deny-by-default. Deploying a site does not expose any resources. Defining a resource does not grant access until you assign users or roles. Zero-trust is enforced by explicit policy: you define what exists, who can access it, and under what conditions. Logs and audit trails support compliance and incident response.
Lets walk through how to setup the system:
Sites extend Pangolin’s secure access to your networks - office LANs, cloud VPCs, data centers, and edge locations. A site is a logical representation of a network segment connected via the Newt connector: a lightweight software component you install on a host that already has network access. Newt creates secure, outbound-only tunnels to the Pangolin control plane. No public IP addresses or inbound firewall rules are required; infrastructure remains behind the perimeter.
Sites run inside your perimeter. They maintain outbound connectivity to the server and, by default, do not allow any traffic until you define resources and assign access in policy. Adding a site does not expose the network; it registers the segment so you can later define resources and enforce who may access them. They also run a WireGuard peer sitting and waiting for clients to establish peer-to-peer connections.
Each site is provisioned with credentials (endpoint, ID, secret) and supported deployment options: Unix, Windows, Docker, Kubernetes, and others. Credentials can be rotated without re-deploying the connector.
Organizations typically deploy multiple sites - one or two per VPC, campus, or region. Each site is a policy enforcement point for the resources attached to it. Users and machines never connect “to a site” directly; they are authorized to resources that the site can see on the network. Sites provide connectivity; resources and policy define what can be accessed.
Resources are the applications, hosts, or network segments you expose for secure access. They are bound to sites and have no access until you define policy: which roles and users (or machine identities) may reach them. This application - and resource - level model supports least-privilege access and reduces the attack surface compared to network-wide VPN access.
Pangolin supports two resource types: public (browser-based, reverse proxy) and private (client-based, ZTNA-style access to specific hosts or CIDRs). Both share the same identity and policy framework.
Public resources provide secure web access to internal and third-party applications. They function as identity-aware reverse proxies: users access a URL in the browser, authenticate (via SSO, MFA, or password), and are routed to the backend based on policy. No client is required on the user device. Pangolin handles TLS termination, routing, and policy enforcement.
You configure backend targets (addresses and ports), path-based routing, optional path rewriting, and health checks. Traffic is sent only to healthy targets. Applications remain behind the firewall; only the site’s outbound tunnel is used.
Health status is visible per resource and per target, so operations teams can monitor availability and troubleshoot before user impact.
Policy for public resources can require authentication, enforce MFA, and apply rules based on user, role, group, geography, IP, or path. This supports secure access to internal tools, admin consoles, and SaaS-style applications with a consistent policy model.
Private resources provide access to specific hosts or network ranges - databases, SSH servers, internal APIs, or subnets - for users or machines that have the Pangolin client. Access is scoped to the resources you grant; there is no broad network access. This is zero-trust network access (ZTNA): only explicitly authorized resources are reachable.
For each private resource you define the destination (hostname, IP, or CIDR), optional internal DNS alias, and port policy (TCP, UDP, ICMP). Port-level restrictions limit exposure compared to full-network VPN access.
Access is granted per resource by roles and users (and optionally machine clients). Administrative roles retain access; all other access is explicitly assigned in policy.
In summary: public resources provide clientless, browser-based access with identity-aware policy; private resources provide client-based, least-privilege access to specific infrastructure. Both use the same identity store and policy engine.
Access is granted only after authentication and authorization. The Pangolin server enforces policy and typically integrates with your existing identity provider (IdP) so that workforce identity, SSO, and MFA are consistent across applications and infrastructure.
Users authenticate via the Pangolin login page or the client. Organizations can use a single identity provider - Microsoft Entra ID, Google Workspace, Okta, or another OIDC/SAML-compatible IdP - for SSO and MFA. It consumes identity from the IdP and applies the roles and resource entitlements you configure. Pangolin can also manage its own set of internal users if you are not working with an IdP.
Users and roles are managed in the admin console. Users are linked to an identity (e.g. email) and an IdP. You assign one or more roles per user. Roles define entitlements: which resources (public and private) can be accessed, plus SSH and other capability settings. This role-based access control (RBAC) keeps policy manageable at scale and supports compliance and audit requirements.
Roles can include SSH-specific policy: whether SSH is allowed, sudo level (none, full, or restricted commands), Unix groups, and home directory provisioning for use with Pangolin's ssh daemon which can run on the site or as a remote auth daemon on the same network the site can access. This gives a single place to define infrastructure access behavior for each role.
For private resource access, users (or automated systems) use the Pangolin client on supported endpoints (Mac, Windows, Linux, iOS, Android). The client authenticates, receives the set of authorized resources, and establishes encrypted tunnels directly to the appropriate sites. No per-application configuration is required; the client handles routing and tunnel management.
Device approval can be required so that new devices cannot access resources until an administrator approves them. This extends zero-trust to the endpoint: valid credentials alone are not sufficient without device trust.
Pending requests appear in a dedicated approvals queue so administrators can review device details and grant or deny access in one place.
Devices can be blocked (e.g. lost, stolen, or compromised) so that access is revoked immediately. The device record is retained for audit and compliance.
So to recap we have the:
For organizations that need both secure web application access and least-privilege infrastructure access under a single policy model - with full auditability and no open ports - Pangolin is designed for that requirement.
You can use Pangolin Cloud for a managed control plane, or self-host the server for full control over data and infrastructure. The same architecture and concepts apply: connect sites, define resources, assign users and roles, and enforce secure access across your environment.
