Pangolin Deployment Overview

What Are Pangolin Tunnels?

#

In this series, I will be exploring the deployment and setup of Pangolin, an open source identity aware reserve proxy and remote access platform built on the Wireguard protocol that enables browser based web application to private resources. In essence, it’s an opensource version of the popular Cloudflare tunnels that enables you to share on-prem (self hosted) applications externally without directly exposing the applications or needing to port forward. While also adding in extra security measures in the form of identity access controls, WAF intergration and monitoring.

Check out the repo: Pangolin and the offical site here

We will be going over the architecture, application deployment, use cases, how to harden the VPS, configuring monitoring and alerting and my overall thoughts on the application and it’s uses.

Deployment Architecture

#

Before we get to deploying and configuring this application, it’s always a good idea to understand what is being deployed, how they function and what is required for everything to work in this case we’re going to need the following here:

Cloud VPS / VM

#

The cloud vm acts as the public access point for the deployment, it is the public ingress point to the services being served via Pangolin.

Here we will deploy,

• Pangolin This is the main control plane and application that serve as the web interfact, the websocket server and the authentication system alongside a database for configuration, user data and system state
• Traefik: This is the reverse proxy which will handle incoming request and routes them accordlingly while also handling SSL termination, SSL certs as well as any middleware services need
• Crowdsec: This is the main security engine and WAF of the application, this will handle any unwanted behaviors, block bad IPs and implement remediation actions, i.e blocking bots, dropping IPs that are spamming etc

Along with this, we will be deploying a Wazuh Agent, a hardened SSH config, Firewall ruling and a backup solution.

Edge Server (On-Prem)

#

The edge server is the on-prem server that will host the Newt application, this is essentially the wireguard tunnel that will communicate with Pangolin and give access to the on-prem applications/services. In my set up, i am treating this as a external facing server and placing it in my exposed Vlan. This vlan is completely segmented from the rest of the network, i will then add specific firewall rules to allow access to only the applications on their specific ports im serving over Pangolin.

High Level Diagram

#

This is what it will look like at a high level once we have deployed and configured everything

---
config:
  theme: forest
  look: neo
---
flowchart TB
 subgraph CLOUD["Public Cloud VM — Ingress & Control"]
    direction TB
        CLOUD_TOP[" "]
        SEC["Security Layer: CrowdSec / WAF"]
        RP["Reverse Proxy: Traefik"]
        PANG["Pangolin: Control Plane / Portal"]
  end
 subgraph EDGE["On-Prem — Exposed Edge"]
    direction TB
        NEWT["Newt: Tunnel Endpoint"]
  end
 subgraph LAN["On-Prem — Private Resources"]
    direction TB
        APPS["Private Apps / Services"]
        OBS["Monitoring & Logging Platform"]
  end
    CLOUD_TOP L_CLOUD_TOP_SEC_0@=== SEC
    SEC L_SEC_RP_0@<==> RP
    RP L_RP_PANG_0@<==> PANG
    EU(["End Users / Browsers"]) L_EU_CLOUD_TOP_0@== HTTP Requests === CLOUD_TOP
    CLOUD -. WireGuard Tunnel .-> NEWT
    NEWT --> APPS
    SEC L_SEC_NEWT_0@-. Security events .-> NEWT
    RP L_RP_NEWT_0@<-. Access logs .-> NEWT
    PANG L_PANG_NEWT_0@<== Audit / auth logs ==> NEWT
    NEWT -. Logs / Metrics .-> OBS

    style CLOUD_TOP fill:transparent,stroke-width:1px,stroke-dasharray: 0,stroke:none
    style SEC color:none
    style EU color:#000000
    style CLOUD stroke:#2962FF,fill:transparent,color:#FFFFFF
    style EDGE fill:transparent,stroke:#00C853,color:#FFFFFF
    style LAN fill:transparent,stroke:#AA00FF,color:#FFFFFF
    linkStyle 0 stroke:#C8E6C9,fill:none
    linkStyle 1 stroke:#C8E6C9,fill:none
    linkStyle 2 stroke:#C8E6C9,fill:none
    linkStyle 3 stroke:#C8E6C9,fill:none
    linkStyle 4 stroke:#C8E6C9,fill:none
    linkStyle 5 stroke:#C8E6C9,fill:none
    linkStyle 6 stroke:#C8E6C9,fill:none
    linkStyle 7 stroke:#C8E6C9,fill:none
    linkStyle 8 stroke:#C8E6C9,fill:none
    linkStyle 9 stroke:#C8E6C9,fill:none

    L_CLOUD_TOP_SEC_0@{ animation: slow } 
    L_SEC_RP_0@{ animation: slow } 
    L_RP_PANG_0@{ animation: slow } 
    L_EU_CLOUD_TOP_0@{ animation: fast } 
    L_SEC_NEWT_0@{ animation: none } 
    L_RP_NEWT_0@{ animation: none } 
    L_PANG_NEWT_0@{ animation: slow }

In essence, when a end user attempts to access a application Pangolin is tunneling to, they will make a request to the cloud VM, this will then go via Traefik where security rules/blocklists will be checked by Crowdsec, if the traffic is legit then the traffic will forward to Pangolin.

Within Pangolin there is multiple sub applications being ran, gerbil and badger. Badger is middleware tied to Traefik and is responsible for user access control, authentication checks and redirecting unauthenticated users to log in system. Gerbil is handling the contious wireguard tunnel connecting to the local edge server, traffic is routed to this local node, which then routes the traffic to the internal application. This is then passed through the wireguard tunnel, back to Pangolin and Traefik then served to the end user.

See the offical System Architecture for more details: Pangolin System-Architecture

Next Steps

#

Now we understand what Pangolin is, and what it requires we can now look at deploying the application stack, hardening certain aspects and ensuring each componant is working togather.

In the next part of this series we will be deploying a cloud VM, configuring Pangolin, Traefik and Crowdsec as well as connecting up a Newt edpoint (The public cloud and on-prem aspects above)