Expose Internal Services Without a VPN

Make internal services reachable securely - without open ports and without a VPN for everyone? WZ-IT builds sovereign remote-management platforms with tunneled reverse proxies and SSO. See our remote-management platforms

Internal services such as web apps, dashboards and APIs can be exposed securely without opening a single inbound port or handing everyone a VPN. The pattern behind it is always the same: an outbound tunnel from your private network to a publicly reachable, identity-aware reverse proxy. The proxy terminates TLS and checks every request against identity and policy before it ever reaches the service. Instead of maintaining one firewall rule per service, running a jump host or issuing a VPN profile to everyone, you expose exactly one application - identity-bound and clientless in the browser. A mature open-source implementation of this pattern is Pangolin, at version 1.19.x as of mid-2026.

Table of Contents

• The pattern: tunnel, reverse proxy and auth at the proxy
• Why no open inbound port is needed
• Pangolin as a self-hosted Cloudflare Tunnel alternative
• Authentication at the proxy and IdP integration
• Internal or public exposure
• Cloudflare Tunnel, ngrok, frp and Inlets compared
• Reverse-proxy expose vs. mesh VPN: when to use which
• Security, sovereignty and how WZ-IT uses it
• Further guides

---

The pattern: tunnel, reverse proxy and auth at the proxy

Exposing services without a VPN relies on three building blocks that work together:

• Outbound tunnel: A lightweight agent runs at the site or inside the VPC, right next to the service. It establishes the connection actively to the outside - no port has to be reachable from the internet.
• Public reverse proxy: On a publicly reachable node (typically a small VPS) a reverse proxy accepts the requests, terminates TLS (automatic certificates) and forwards them through the tunnel to the internal service.
• Authentication at the proxy: Before a request reaches the service, the proxy enforces login and policy. Even an application with no user management of its own becomes identity-bound this way.

The key point: authentication sits in front of the service, not inside it. An internal dashboard with no login gets a fronting SSO without you touching its code. That is exactly what an identity-aware reverse proxy is for.

Why no open inbound port is needed

Traditionally you would expose a service by opening a port in the firewall or setting up port forwarding. That puts the application directly on the internet - including every unpatched vulnerability and automated scan.

With a tunneled reverse proxy the direction is reversed. The agent inside the private network initiates the connection outbound-only to the proxy. Only the public proxy still has to accept inbound connections, usually on port 443 for HTTPS and UDP 51820 for the WireGuard tunnels. Your internal network has zero open inbound ports. Even if an attacker knows the internal service, there is no path that does not first pass through the authenticating proxy. That is the same logic as the outbound-only mesh VPN we describe in What is NetBird? - just tailored to individual HTTP services.

Pangolin as a self-hosted Cloudflare Tunnel alternative

Pangolin by vendor Fossorial implements this pattern fully self-hosted and positions itself as an open-source alternative to Cloudflare Tunnel. The architecture combines four components - Pangolin's own building blocks are named after burrowing animals, plus the established Traefik reverse proxy:

• Pangolin itself: the central server with a dashboard that manages resources, users and policies.
• Traefik: the actual HTTP reverse proxy. It terminates TLS, obtains Let's Encrypt certificates and routes requests.
• Gerbil: the WireGuard management server on the public node that manages the tunnel peers.
• Newt: the user-space WireGuard tunnel client and TCP/UDP proxy that runs at the site and establishes the outbound connection. Because Newt operates entirely in user space (netstack), it needs neither root nor a kernel module.

The path of a request: browser to VPS over HTTPS, Traefik terminates TLS, the request travels through the WireGuard tunnel managed by Gerbil to Newt inside the private network, and Newt hands it to the target service. A built-in Traefik plugin called Badger authenticates each individual request against Pangolin.

On license and status: Pangolin is current at version 1.19.4 (26 June 2026) and dual licensed - the Community Edition under AGPL-3, the Enterprise Edition under the Fossorial Commercial License, which is free for personal/hobbyist use and for businesses under 100,000 USD gross annual revenue. More on operating it in our Pangolin expertise.

Authentication at the proxy and IdP integration

The value over a bare tunnel is identity-bound access control. Pangolin follows a zero-trust model: users get access to individual resources, not to the whole network. Per resource you can enforce different auth methods:

• SSO via the Pangolin session with organization-wide permissions,
• PIN or password as a simple gate in front of the service,
• email whitelist with OTP: only approved addresses receive a one-time passcode,
• temporary, self-destructing share links with an expiry time,
• plus access tokens and header auth for machine access.

For company-wide SSO, Pangolin connects to any OIDC/OAuth2 identity provider, including Authentik, Keycloak and Okta; in Cloud and Enterprise also Google and Microsoft Entra ID. With auto-provisioning, users are created and assigned roles on first login. So you use a single identity for all exposed services instead of maintaining accounts per application. Built-in users with email/password and 2FA (TOTP, WebAuthn) exist as a fallback.

Internal or public exposure

Not every service should be reachable by the public. The pattern has two tiers:

• Public but authenticated: The service hangs off the public proxy and is protected by SSO or one of the resource auth methods. Ideal for a customer portal, a status dashboard or an API with token access.
• Internal or private: Servers, databases or admin interfaces that nobody should reach publicly are connected via the Pangolin client. It exposes private resources such as SSH, RDP or databases only to authorized devices - with NAT traversal, without public exposure.

So you decide per service: clientless in the browser for web apps, or client-based for non-HTTP protocols. Both run over the same outbound tunnel.

Cloudflare Tunnel, ngrok, frp and Inlets compared

Cloudflare Tunnel is the best-known representative of the pattern, but cloud-bound: your traffic transits the Cloudflare edge, identity via Cloudflare Access. ngrok is strong for development and demos, but SaaS-bound as a permanent production solution. frp is open source and fast, but ships no identity layer - you have to front it with authentication yourself. Inlets is a commercial self-hosted tunnel. Pangolin is the option that bundles outbound tunnel, reverse proxy and built-in identity into one self-hosted stack.

Reverse-proxy expose vs. mesh VPN: when to use which

A tunneled reverse proxy and a mesh VPN solve related but different problems:

• Reverse-proxy expose (Pangolin): You want to expose individual web apps, dashboards or APIs specifically - clientless in the browser, with SSO at the proxy, often for external users without installed software. Access is HTTP-centric and resource-granular.
• Mesh VPN (NetBird): You want to give devices and servers full network access to arbitrary protocols - SSH, RDP, databases, internal tools - as if they sat on the local network. That is the right layer for administrators, CI runners or site-to-site connectivity.

In practice you combine both: the mesh VPN forms the encrypted network backend, the tunneled reverse proxy exposes individual services clientless and identity-bound. More on the clientless variant in Remote maintenance without a VPN client.

Security, sovereignty and how WZ-IT uses it

The pattern brings three tangible security advantages: no open inbound port at the site, identity-bound access instead of network-wide access, and a fronting SSO even for applications that cannot authenticate on their own. Run the proxy and identity provider self-hosted, and traffic, keys and identities stay in your own infrastructure - for example on a VPS in the EU. That matters for regulated environments and NIS2-compliant remote access. This article is general information and not legal advice.

At WZ-IT we combine exactly these building blocks in sovereign platforms: a mesh VPN as the encrypted backend, a tunneled reverse proxy for clientless web access and a central identity provider like Authentik for SSO across all services. The ABCO Water Systems case study shows what this looks like in production. On request we handle design, build and operation end to end as part of our remote-management platforms.

Further guides

• Pangolin expertise - tunneled reverse proxy in practice
• What is NetBird? - mesh VPN as the network backend
• Remote maintenance without a VPN client - clientless browser access
• Authentik expertise - self-hosted SSO and identity provider

Want internal services reachable without open ports and without a VPN for everyone? Get to know us or take a look at our remote-management platforms.