Pangolin | Building a Peer-to-Peer Alternative to Cloudflare Tunnels with TLS Termination at the Edge

CloseMenu

Get a demo

Book a demoSign up

Building a Peer-to-Peer Alternative to Cloudflare Tunnels with TLS Termination at the Edge

May 27, 2026

Discover PangolinBook a demo

The Two Tradeoffs of Reverse Proxies

When you deploy a standard reverse proxy, you typically opt into two things: terminating SSL at the server level, and exposing your service to the public internet. Generally speaking, there is nothing wrong with this.

The first major tradeoff emerges with cloud-brokered reverse proxies like Cloudflare Tunnels or Ngrok. Because they intercept your traffic in the cloud, they act as a mandatory man-in-the-middle decrypting your SSL before passing it down a tunnel to your network edge. While this allows them to inspect and block bad traffic, it breaks strict compliance rules like HIPAA, where sensitive data must remain completely unreadable by third parties between the client and the destination.

The second tradeoff is exposure. If you are hosting a sensitive internal site, like a password manager or a web panel for a legacy hardware controller, a standard reverse proxy leaves it discoverable to anyone with a web browser. Modern tools can throw an authentication page in front of it, but your resource is never truly "cloaked" from the public internet. Undetected vulnerabilities remain exploitable.

To solve both issues simultaneously, we have to flip the architecture: combine peer-to-peer networking with an edge reverse proxy. Instead of relying on public DNS and a cloud server to terminate connections, the client connects to a virtual private network (VPN) and resolves DNS entirely over the tunnels. The HTTPS traffic travels over a blind transport layer and decrypts all the way down at the local network edge. The result is a service that is fully functional with valid SSL, yet entirely cloaked and untraceable from the public internet.

All code is available on GitHub: https://github.com/fosrl/pangolin

Cloud-Terminated vs. Edge-Terminated

Briefly, to understand the difference, look at how the lifecycle changes in these two diagrams.

Traditional Cloud-based Tunneled Reverse Proxy:

Peer-to-Peer Tunneled Edge Reverse Proxy:

How Did We Build It?

A quick background on our architecture: Pangolin natively provides two core capabilities. First, a server-terminated, cloud-based reverse proxy (our direct alternative to Cloudflare Tunnels). Second, a client-to-site peer-to-peer VPN. In both setups, you deploy a lightweight site connector (which we sometimes nickname a Newt) on your local network to facilitate access.

To deliver this new "private HTTPS" modality, we smashed components from both products together.

Here is exactly how the layers come together under the hood to make the system work. (And yes, if you want to skip straight to the implementation, the code is all available on GitHub).

Hijack the OS DNS

To get traffic into a private tunnel without forcing the user to type in a raw IP address you have to capture their web traffic at the very beginning of its lifecycle: the DNS request.

If a user types https://vault.pangolin.net into their web browser, we cannot let that request escape to a public DNS server like 1.1.1.1 or 8.8.8.8. If it leaks, the request fails, or worse, reveals internal domain topography to the public internet. First, we had to build a mechanism that hijacks the operating system’s DNS routing without breaking the user’s normal internet traffic.

This is easily the most brittle and complex part of the codebase because every operating system handles DNS configuration differently. To make this seamless, we built native clients for macOS, Windows, Linux, iOS, and Android to tap into platform-specific networking APIs. For example, on macOS, we leverage the native System Extensions combined with scutil to dynamically set our private DNS server at the top of the network interface resolution order.

Local DNS Resolution and Logical Mapping

Once the OS-level hook is established, the Pangolin client starts a tiny local DNS server listening directly inside our virtual network interface (usually at 100.96.128.1). Because it lives right on the interface, the traffic never leaves your machine

When the OS pipes a private domain query to this interface resolver, we don’t resolve it to a physical IP on the local network. Instead, the local resolver maps that friendly domain to a unique, logical overlay address (within the 100.96.128.0/18 range) assigned to that resource. This is all under the hood and you never have to think about the overlay address space.

To the browser and the operating system, this looks like a completely standard networking event. The browser receives the logical IP, assumes it’s talking to a normal web server and initiates a standard TCP handshake. Behind the scenes, the Pangolin client intercepts those TCP packets destined to 100.96.128.20 and preps them to...