Pangolin – une alternative open source à Cloudflare Tunnels

• Serveur de gestion de proxy inverse tunnelisé auto-hébergé offrant des fonctionnalités similaires à Cloudflare Tunnels
• Permet d’exposer en toute sécurité des ressources de réseau privé vers l’extérieur, sans port forwarding, grâce à des tunnels chiffrés basés sur WireGuard
• Propose diverses fonctions d’authentification et de sécurité, notamment proxy inverse, authentification inverse et contrôle d’accès, ainsi que la prise en charge d’OAuth2/OIDC, avec un tableau de bord web intuitif
• Déploiement basé sur Docker Compose pour une installation et une exploitation simplifiées, avec API et intégration de plugins pour l’automatisation et l’extensibilité
• Permet de contourner les contraintes réseau et de gérer les ressources en toute sécurité dans divers environnements comme l’IoT, les homelabs, le multicloud ou les services d’entreprise

---

Présentation de Pangolin

• Pangolin est un serveur de proxy inverse basé sur des tunnels pouvant être auto-hébergé, qui fournit des fonctions centralisées d’authentification et de contrôle d’accès
• Il s’intègre au client userspace WireGuard (Newt) ainsi qu’à divers clients WireGuard, ce qui permet des connexions sécurisées même dans des environnements contraints par des pare-feu et du NAT
• Il permet d’exposer des ressources internes vers l’extérieur sans port forwarding, ce qui aide à masquer l’IP publique et à protéger le réseau
• Son tableau de bord permet de gérer facilement sites, utilisateurs, rôles et ressources, avec une interface prenant en charge le mode sombre et le mobile

Fonctionnalités principales

• Proxy inverse via des tunnels WireGuard

  • Permet d’exposer des ressources réseau sans ouvrir le pare-feu (aucun port à ouvrir)
  • S’intègre à son propre client WireGuard (Newt) et prend en charge tous les clients WireGuard
  • Prend en charge l’émission automatique de certificats SSL (Let's Encrypt) ainsi que les services HTTP/HTTPS et TCP/UDP
  • Fonction de load balancing intégrée

• Authentification et contrôle d’accès

  • Système d’authentification centralisé (SSO de la plateforme, OAuth2/OIDC, intégration avec des IdP externes)
  • Contrôle d’accès basé sur les rôles (RBAC), avec définition d’IP/URL/plages par ressource
  • Nombreuses options d’authentification supplémentaires : OTP par e-mail, TOTP, code PIN, liens de partage temporaires, etc.
  • Gestion structurée via l’organisation de sites, utilisateurs et rôles

• Tableau de bord intuitif

  • Interface claire pour gérer d’un coup d’œil sites/ressources/utilisateurs/rôles
  • Supervision en temps réel de l’utilisation et de l’état des connexions
  • Modes clair/sombre, compatibilité mobile

• Déploiement simple et extensibilité

  • Installation basée sur Docker Compose, prise en charge du cloud comme de l’on-premise
  • Fournit une API et une documentation Swagger, avec possibilité d’intégrer l’automatisation et des scripts personnalisés
  • Intégration avec des plugins Traefik (CrowdSec, Geoblock) pour appliquer un WAF et du géoblocage
  • Gestion centralisée de plusieurs sites depuis un seul serveur central

Cas d’usage représentatifs

• Exposition de services web dans des environnements où le port forwarding est limité (homelab / restrictions FAI)
• Publication sécurisée vers l’extérieur d’applications internes/on-premise et cloud
• Gestion unifiée de réseaux IoT : connexion et accès sécurisés à des sites IoT distribués depuis un serveur central
• Utilisation comme proxy inverse / load balancer unifié pour des environnements multicloud et hybrides

Différences avec des projets similaires

• Cloudflare Tunnels : service de proxy inverse de type SaaS similaire, mais Pangolin offre un auto-hébergement avec un contrôle total sur l’infrastructure
• Authelia : source d’inspiration pour l’authentification centralisée et la gestion des rôles

Déploiement et licence

• Guide étape par étape pour déployer le serveur central avec Docker Compose, connecter un domaine, relier des sites et exposer des ressources
• Politique de double licence : AGPL-3 et licence commerciale Fossorial

[ng0301]

Ce n’est pas si simple à utiliser confortablement en quelques clics.

[ndrgrd]

Tout est bien, mais si vous utilisez ça, le système ne peut pas contrôler WireGuard. Si vous voulez l’utiliser séparément des tunnels, il faut le déployer dans une VM distincte.

[GN⁺]

Commentaires sur Hacker News

• Bonjour, je suis l’autre mainteneur principal de ce projet. Je voulais donner un peu plus de détails sur les autres composants du système. Pangolin utilise Traefik en interne pour le fonctionnement du proxy HTTP. Un plugin appelé Badger délègue à Pangolin l’authentification de toutes les requêtes. Le deuxième service, Gerbil, est le serveur de gestion qui permet à Pangolin de créer des pairs WireGuard pour les connexions. Enfin, il y a Newt, un outil CLI et un conteneur Docker qui exploite pleinement WireGuard en espace utilisateur, communique avec Gerbil et sert de proxy pour les ressources locales. Cela évite d’avoir à exécuter des processus avec les droits root ou des conteneurs privilégiés pour exposer des services
  • J’utilise ça depuis quelques mois pour faire transiter du trafic depuis un petit VPS Hetzner vers chez moi. L’expérience a été très fluide et stable. J’ai cru avoir un problème une fois, mais il n’avait rien à voir avec Pangolin. Les détails sont disponibles ici
  • Avoir un mini-tutoriel dans la documentation pour chacun des cas d’usage mentionnés ici permettrait probablement de tester rapidement et de voir si ça peut aider
• C’est vraiment intéressant. Le fait d’être dépendant de Cloudflare Tunnel m’a toujours dérangé, donc voir une alternative open source est vraiment rafraîchissant. Je me demande comment Pangolin gère les aspects compliqués comme l’instabilité réseau, les problèmes d’authentification ou le passage à l’échelle. Si des gens l’ont utilisé en conditions réelles, j’aimerais bien savoir comment ça se compare au côté « ça marche tout simplement » de Cloudflare. Je suis surtout curieux de savoir si ça fonctionne bien pour l’auto-hébergement à la maison. Pour contexte, j’héberge chez moi un blog et divers projets perso sur un Raspberry Pi. Des retours d’expérience concrets seraient vraiment utiles
• Ça a l’air vraiment intéressant pour gérer plusieurs box de développement à distance ou des usages similaires. En fait, je n’ai jamais été très impliqué dans ce genre d’infra, donc ma question est peut-être assez basique. Je n’ai jamais utilisé de tunnel CF et jusqu’ici je me suis surtout contenté de tunnels de reverse proxy via SSH ou de Tailscale. Je faisais ça parce que certains services internes de test n’existaient que sur un appareil précis, comme une instance EC2 ou un portable à la maison. En bref, pourrais-tu expliquer en quoi Pangolin diffère d’une solution comme Tailscale ?
  • Le SSH ou Tailscale que tu utilises sont de très bons choix pour cet objectif. En général, Pangolin se rapproche davantage d’un tunnel statique et permanent vers un service, plutôt que d’un tunnel temporaire comme avec SSH. C’est adapté si tu veux exposer des applications internes pour qu’elles soient accessibles depuis un navigateur web par des personnes extérieures, comme ta famille. Par exemple, si tu veux rendre accessibles depuis l’extérieur, via le navigateur, une application interne d’entreprise ou des services de homelab comme Immich ou Grafana, cet outil peut être très utile. J’espère que c’est plus clair
  • J’utilise largement les tunnels CF sur mon serveur unraid à la maison. En résumé, quand je veux exposer une appli précise sans ajouter un nœud Tailscale de plus — par exemple pour mon frère qui utilise mon serveur Plex — je crée un sous-domaine dans CF et je le fais pointer vers un tunnel CF. Il suffit de remplir trois champs de formulaire par site ou service, et le certificat SSL est généré automatiquement. Donc jusqu’ici, j’en suis content
  • Tailscale (et headscale) sont excellents pour accéder à des ressources internes qui ne sont pas joignables depuis l’extérieur. Par exemple, on peut les utiliser si on veut qu’un NAS reste bloqué côté externe et accessible seulement en interne. Les tunnels Cloudflare permettent d’exposer un service vers l’extérieur tout en ajoutant un peu de protection. Certains font en sorte que le backend ne soit accessible que via Tailscale, tandis que la partie publique passe uniquement par un tunnel Cloudflare. Il est aussi tout à fait possible de raccorder directement un tunnel Cloudflare à un nginx proxy manager central. Bien sûr, Tailscale peut aussi servir à router vers des services publics, mais Cloudflare offre une protection un peu plus robuste. Pangolin a aussi l’air suffisamment intéressant pour mériter des tests ; on pourrait commencer par le mettre derrière un tunnel Cloudflare, puis le placer devant si besoin
• Question de vrai débutant en sécurité : quand on utilise ce type de solution, quel est le pire scénario du point de vue sécurité ? J’imagine que si l’authentification est contournée, même des ports internes pourraient devenir exposés, mais y a-t-il d’autres points de vigilance importants ?
• Étant donné la portée potentielle d’un service d’authentification, je suis curieux de savoir s’il y a eu un audit de sécurité professionnel et s’il existe un programme officiel de tests d’intrusion ou de divulgation de vulnérabilités
  • Je pense que si un audit avait été fait, ce serait indiqué dans la documentation
• Ça a l’air vraiment bien. J’ai moi aussi récemment mis en place quelque chose de similaire avec une box OPNSense qui fournit DNS, une instance WireGuard et des certificats à un reverse proxy Nginx sur Synology. Côté client, j’active uniquement le tunnel WG sur la plage d’IP interne et je le fais fonctionner uniquement avec le DNS interne, afin d’éviter d’exposer mon IP sur des certificats publics. Ça marche très bien pour un réseau domestique, mais si on gère plusieurs sites, Pangolin a l’air plus élégant et plus simple à configurer. Je me demande si Newt est une implémentation distincte du serveur WireGuard, et s’il a déjà fait l’objet d’un audit de sécurité
• Je me demande quelle est la différence entre Pangolin et NetBird. NetBird est aussi auto-hébergeable et entièrement open source. Lien GitHub de NetBird
  • Sauf erreur de ma part, NetBird n’inclut pas toutes les fonctionnalités dans la version open source. Au final, c’est surtout le coût du SSO qui m’a fait renoncer à l’utiliser
  • Moi aussi, j’aimerais en savoir plus. Les cas d’usage se ressemblent, mais techniquement c’est différent. NetBird est une alternative à Tailscale basée sur WireGuard, tandis que Pangolin utilise Traefik. J’utilise NetBird et j’en suis très satisfait. Le design de l’interface se ressemble aussi pas mal entre les deux
• Je me demande en quoi c’est différent d’autres projets open source comme zrok
• Très beau projet. J’ai exposé mes applis vers l’extérieur avec tailscale et nginx proxy manager installé sur un VPS, et j’ai décrit tout ça ici. Pangolin semble offrir quelque chose de similaire, mais avec une meilleure interface et davantage de contrôle, donc je vais clairement l’essayer. Une question quand même : est-ce qu’il gère plusieurs domaines ? Aujourd’hui, je fais pointer plusieurs domaines vers mon VPS puis je les proxy via nginx proxy manager ; est-ce que Pangolin prend aussi en charge ce type de configuration ?
• Il existe déjà pas mal d’alternatives open source à Cloudflare Tunnels : lien GitHub awesome-tunneling. Parmi elles, je pense que Pangolin est l’une des solutions les plus abouties et les plus soignées