Zum Hauptinhalt springen
S-EDV news
← Alle News
Docker 02.10.2026 · 5 min Lesezeit

Pangolin 1.24: Exit Nodes machen den Tunnel-Proxy zum eigenen VPN-Gateway

Pangolin 1.24.0 ist seit dem 30. September 2026 verfügbar. Exit Nodes leiten den Internetverkehr der Clients über eine eigene Site, dafür braucht es Newt 1.18.0 und neue Clients. Ein Sicherheitsupdate ist es nicht, ein Backup vor der Migration aber Pflicht.

Mit KI erstellt – redaktionelle Prüfung ausstehend

Illustration: Mehrere Standorte laufen durch einen Tunnel zu einem Gateway, daneben die Überschrift Pangolin wird VPN-Gateway

Fossorial hat am 30. September 2026 Pangolin 1.24.0 veröffentlicht. Der selbst gehostete Tunnel-Reverse-Proxy auf WireGuard-Basis bekommt damit sogenannte Exit Nodes: Clients können ihren gesamten Internetverkehr über einen frei gewählten Standort ausleiten, Pangolin wird also zum selbst betriebenen VPN-Gateway. Dazu kommen HTTP-Methoden in Ressourcenregeln, anpassbare Response-Header, Subnet-Routing im Linux-Client und automatische Verbindungen auf Mac, iOS, Windows und Android.

Relevant ist das Update für alle, die Pangolin per Docker Compose betreiben, im Homelab wie im Unternehmen. Eine Sicherheitslücke nennen die Release-Notes nicht, nur allgemeine Dependency-Sicherheitsupdates. Heute handeln muss deshalb niemand; ein geplantes Wartungsfenster mit Backup reicht. Wer Exit Nodes nutzen will, muss zusätzlich Newt oder die Pangolin-CLI und die Endgeräte-Clients aktualisieren.

Was ist passiert?

Das GitHub-Release 1.24.0 ist laut API am 30. September 2026 um 20:23 Uhr UTC erschienen, das passende Image fosrl/pangolin:1.24.0 liegt seit 20:04 Uhr UTC auf Docker Hub. Der Tag latest zeigt auf denselben Digest, für die Enterprise Edition gibt es fosrl/pangolin:ee-1.24.0. heise berichtete am 1. Oktober 2026 und ordnet die Neuerung als „Selbstbau-VPN“ ein, das in Konkurrenz zu Tailscale oder dem in Routern eingebauten WireGuard-VPN tritt.

Bisher arbeitet Pangolin als Split Tunnel: Nur Verkehr zu den angebundenen Sites läuft durch den Tunnel, der Rest geht direkt ins Internet. Mit 1.24 legen Admins eine private Ressource vom Typ Exit Node an und hängen eine oder mehrere Sites an. Clients, die diese Ressource wählen, schicken ihren Verkehr über die Default-Routen 0.0.0.0/0 und ::/0 zur Site. Bei mehreren Sites wählt der Client laut Hersteller nach Latenz, Durchsatz und Verfügbarkeit. Auf der Kommandozeile genügt pangolin select exit-node.

Die weiteren Punkte aus den Release-Notes:

  • HTTP-Methoden als Bedingung in Ressourcenregeln.
  • Eigene Response-Header pro Ressource.
  • Overrides für die Badger-Konfiguration direkt in der Konfigurationsdatei.
  • Subnet-Router im Linux-Client: pangolin up client ... --subnet-router aktiviert Forwarding und setzt nftables-Regeln, damit Geräte ohne Client wie Drucker oder Kameras Pangolin-Ressourcen erreichen.
  • On-Demand-Verbindungen auf macOS und iOS, Always-on-VPN auf Android, Verbinden bei Anmeldung unter Windows.
  • Neue Bundle-Kennungen für die iPhone- und Mac-Clients; ob das bei MDM-verteilten Apps Nacharbeit erfordert, lassen die Release-Notes offen.

Für wen ist das relevant?

Betroffen vom Server-Update sind alle selbst gehosteten Pangolin-Instanzen, Community wie Enterprise Edition. Interessant sind Exit Nodes vor allem für Teams mit Außendienst, die in fremden WLANs arbeiten, und für Umgebungen, in denen Compliance-Vorgaben einen VPN-Zwang für mobile Geräte vorsehen. Wer Pangolin nur als Reverse Proxy für veröffentlichte Webdienste nutzt, bekommt mit Methodenregeln und Response-Headern zwei praktische Werkzeuge.

Exit Nodes setzen laut Release Newt ab 1.18.0 oder die Pangolin-CLI ab 0.18.0 an der Site voraus. Auf den Endgeräten nennt der Hersteller Windows 0.15.0, macOS 0.12.0, iOS 0.11.0, Android 0.8.0 und CLI 0.18.0. Ältere Clients sehen die Funktion nicht.

Wie kritisch ist das?

Es handelt sich um ein Feature-Release ohne gemeldete Schwachstelle; Dringlichkeit besteht nicht. Wichtig sind zwei Einschränkungen. Erstens unterstützen Exit Nodes laut Dokumentation derzeit nur IPv4, IPv6-Verkehr wird nicht über den Exit Node geführt. IPv6 kann damit am Tunnel vorbei laufen. Zweitens fließt sämtlicher Internetverkehr der Nutzer künftig über die Leitung der gewählten Site. Bandbreite, Logging und rechtliche Verantwortung für diesen Verkehr liegen damit beim Betreiber der Site.

Zum Update selbst warnt Fossorial wie bei jedem Release: Datenbankmigrationen laufen beim Start automatisch, ein Downgrade ist danach nicht ohne Weiteres möglich. Bei SQLite legt Pangolin vor der Migration selbst eine Kopie der Datenbank an, ein eigenes Backup des Konfigurationsverzeichnisses ersetzt das nicht.

Was sollten Admins jetzt tun?

  • Laufende Versionen prüfen: docker compose ps bzw. das image:-Feld in der docker-compose.yml für Pangolin, Gerbil und Traefik sowie die Badger-Version in config/traefik/traefik_config.yml notieren.
  • Vor dem Update das Konfigurationsverzeichnis samt Datenbank sichern, wie es die Release-Notes ausdrücklich verlangen.
  • Pangolin auf fosrl/pangolin:1.24.0 pinnen statt latest zu nutzen, dann docker compose pull und docker compose up -d, anschließend die Logs auf Migrationsfehler prüfen.
  • Eine neue Gerbil-Version nennt das Release nicht; aktuell ist auf GitHub Gerbil 1.5.2 vom 18. September 2026, Badger steht bei v1.7.0.
  • Für Exit Nodes zuerst die Site-Connectoren auf Newt 1.18.0 oder CLI 0.18.0 heben, danach die Clients verteilen. Die CLI hat am 1. Oktober mit 0.18.1 bereits einen Fix für Routen nachgeschoben.
  • Vor dem Freischalten von Exit Nodes klären, welche Rollen sie nutzen dürfen, und die IPv6-Lücke bei mobilen Geräten bewerten.

Einordnung für Unternehmen

Pangolin entwickelt sich vom Reverse Proxy mit Tunnel zu einer kompletten Zugangsplattform. Nach Hochverfügbarkeit in 1.23 und dem AI Gateway in 1.22 deckt Version 1.24 nun auch den klassischen Full-Tunnel-Einsatz ab, für den viele kleine Unternehmen bisher ein separates WireGuard-Setup oder einen kommerziellen Mesh-Dienst betreiben.

Der kurze Release-Takt (1.22 am 24. August, 1.23 am 15. September, 1.24 am 30. September) bedeutet aber auch regelmäßige Datenbankmigrationen ohne einfachen Rückweg. Unternehmen sollten Updates deshalb nicht automatisch über latest ziehen, sondern feste Versionen pinnen, vorher sichern und erst nach einem kurzen Test auf produktive Instanzen ausrollen. Für Exit Nodes empfiehlt sich ein Pilot mit wenigen Geräten, bis IPv6 unterstützt wird.

Passende Anleitungen auf S-EDV

Quellen

PangolinReverse ProxyWireGuardVPNDockerSelfhostingHomelab