Netzwerk & VPN Archive - RDDZ

PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann

dennis_rddz — Tue, 20 Oct 2026 14:29:20 +0000

SICHERHEIT · LINUX-KERNEL · STAND 20.10.2026

PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann

Eine Sicherheitslücke im Linux-Kernel sorgt derzeit für Aufmerksamkeit: PwnEscape, geführt unter CVE-2026-99999, kann unter bestimmten Voraussetzungen dazu genutzt werden, aus einer virtuellen Maschine auf den zugrunde liegenden Host zuzugreifen. Betroffen sein können damit ausgerechnet Systeme, deren Aufgabe es ist, voneinander getrennte Umgebungen bereitzustellen.

PWNESCAPE · CVE-2026-99999

● CVE seit 15.10.2026

9,3

CVSS 3, kritisch

IPv4

Linux-Kernel

Gast → Host

KVM, virtio

Proxmox VE ✓ Kernel 7.0.14-24

Debian ✓ Fix für 12 und 13

Ubuntu ● Status prüfen

Entscheidend: korrigierten Host-Kernel installieren, neu starten und prüfen, ob er läuft.

✓ CVE veröffentlicht am 15. Oktober 2026

✓ Proxmox-Fix seit 16. Oktober 2026

✓ Korrigierte Debian-Kernel für 12 und 13

✓ Ubuntu: Status direkt prüfen

✓ Mit Praxisbefehlen für die Host-Prüfung

EINORDNUNG

Eine ernst zu nehmende Meldung für Virtualisierungshosts

Für Betreiber virtualisierter Server ist das eine ernst zu nehmende Meldung. Entscheidend ist allerdings nicht allein die Schwere der Schwachstelle, sondern auch, wie schnell die verfügbaren Korrekturen eingespielt werden.

Proxmox hat bereits einen korrigierten Kernel bereitgestellt. Auch Debian führt behobene Kernelpakete. Bei Ubuntu ist der Status der betroffenen Pakete gesondert zu prüfen.

Was steckt hinter PwnEscape?

PwnEscape betrifft die Verarbeitung von IPv4-Netzwerkpaketen im Linux-Kernel. Vereinfacht gesagt kann eine fehlerhafte Prüfung von Metadaten zur Prüfsummenberechnung dazu führen, dass der Kernel beim Verarbeiten eines Pakets Speicher beschädigt.

Das Problem ist deshalb besonders relevant, weil Netzwerkpakete auch innerhalb virtualisierter Umgebungen verarbeitet werden. Unter den entsprechenden Voraussetzungen kann ein Angreifer aus einer virtuellen Maschine heraus versuchen, die Sicherheitsgrenze zum Host zu überwinden. Die Proxmox-Sicherheitsmeldung beschreibt den Angriffsweg über den virtio-Netzwerkstack, die Forscher von PWNAI Research zeigen ihn in einem eigenen KVM-Testaufbau.

Die möglichen Folgen reichen von einem Absturz des Systems über das Offenlegen von Speicherinhalten bis hin zur Ausführung von Code mit weitreichenden Rechten auf dem Host. Der konkrete Erfolg eines Angriffs hängt allerdings von den jeweiligen technischen Voraussetzungen und der betroffenen Umgebung ab. Die Veröffentlichung bedeutet nicht, dass jede virtuelle Maschine auf jedem Linux-Host automatisch kompromittiert werden kann.

Die Schwachstelle wurde am 15. Oktober 2026 als CVE-2026-99999 veröffentlicht. In der CVSS-Version 3 wird sie mit einem Schweregrad von 9,3 von 10 – kritisch bewertet. Hersteller können für ihre jeweiligen Produkte zu abweichenden Bewertungen kommen, weil sie unterschiedliche Rahmenbedingungen berücksichtigen.

Technische Hintergründe finden sich in der Linux-Kernel-Sicherheitsmeldung und in der Analyse der Sicherheitsforscher.

⚖

Kritisch bewertet, aber nicht überall gleich

Der CVSS-Wert liegt bei 9,3. Ubuntu führt die CVE dennoch mit der Priorität „Medium“. Das zeigt, wie unterschiedlich Hersteller die Lücke für ihre Pakete einstufen.

🛡

Korrektur als Zusatzschutz

Der Upstream-Fix prüft checksum_start, bevor die Prüfsumme berechnet wird. Debian und Ubuntu beschreiben ihn als zusätzliche Schutzmaßnahme (Defense in Depth). Eine umfassendere Validierung beim Empfang ist laut den Angaben noch in Arbeit.

🔍

Keine Ausnutzung bei Anbietern behauptet

Die Forscher behaupten ausdrücklich keine Ausnutzung bei Produktionsanbietern. Ihre Angriffe zeigen sie in eigenen Testaufbauten.

VIRTUALISIERUNG

Warum die Lücke für Virtualisierung besonders relevant ist

Bei einem virtualisierten Server laufen mehrere voneinander getrennte Systeme auf derselben physischen Hardware. Der Hypervisor und der Host-Kernel übernehmen dabei eine zentrale Rolle: Sie stellen die Ressourcen bereit und setzen die Trennung zwischen den virtuellen Maschinen und dem Host durch. Genau diese Trennung ist bei einer möglichen Guest-to-Host-Schwachstelle der entscheidende Punkt.

Kann ein Angreifer aus einer Gast-VM heraus eine Schwachstelle im Host-Kernel ausnutzen, betrifft das nicht mehr nur das einzelne Gastsystem. Im ungünstigsten Fall könnte auch die darunterliegende Infrastruktur gefährdet sein. Je nach Umgebung wären damit weitere virtuelle Maschinen auf demselben Host betroffen.

Das macht PwnEscape für Betreiber von Virtualisierungsplattformen und für alle relevant, die eigene virtuelle Server betreiben. Die Sicherheitslücke ist jedoch kein Beleg dafür, dass sämtliche KVM-Systeme oder jede Proxmox-Installation gleichermaßen angreifbar sind. Entscheidend sind unter anderem der eingesetzte Kernel, der Patchstand und die konkreten Bedingungen der Umgebung.

DISTRIBUTIONEN

Proxmox, Debian und Ubuntu im Überblick

📦

Proxmox VE: Der korrigierte Kernel war schnell verfügbar

Für Betreiber von Proxmox VE gibt es bereits eine konkrete Korrektur. In der offiziellen Proxmox-Community wurde die Sicherheitsmeldung PSA-2026-00068-1 zu PwnEscape am 16. Oktober 2026 veröffentlicht.

Der Fix ist im Paket proxmox-kernel-7.0.14-24-pve sowie in der signierten Variante proxmox-kernel-7.0.14-24-pve-signed enthalten. Laut Proxmox-Team war das Paket zunächst im Repository pve-no-subscription verfügbar und sollte anschließend auch im Enterprise-Repository bereitgestellt werden. Ein Nutzer im Forum bestätigt es inzwischen auch dort.

Die CVE wurde am 15. Oktober offiziell veröffentlicht. Damit reagierte Proxmox sehr schnell und stellte die korrigierte Kernel-Version bereits kurz darauf bereit.

Wichtig ist dabei die Unterscheidung zwischen einem verfügbaren Update und einem tatsächlich aktualisierten Host: Ein Administrator muss sicherstellen, dass das passende Paket installiert ist und der Host anschließend mit dem korrigierten Kernel läuft. Ein bloßes Aktualisieren von Paketen garantiert nicht in jedem Fall, dass der neue Kernel bereits aktiv ist.

Ältere Installationen: Laut Proxmox-Team ist 7.0.14 die einzige aktuell unterstützte Kernel-Serie. Für Kernel-Serien, deren Support ausgelaufen ist, gibt es keine Updates. Das betrifft beispielsweise den Kernel 6.8 von Proxmox VE 8. Wer solche Hosts betreibt, sollte ein Upgrade auf eine unterstützte Version einplanen.

GPU-Treiber: Im Forum berichtet ein Nutzer, dass der NVIDIA-Treiber 615.78.08 auf dem Kernel 7.0.14-24-pve nicht kompiliert. Wer Treiber per DKMS einsetzt, sollte das Update vorher auf einem Testsystem prüfen.

Die offizielle Diskussion und die Angaben des Proxmox-Teams finden sich im Proxmox-Supportforum zur Sicherheitslücke.

🌀

Debian: Korrigierte Kernelpakete sind ausgewiesen

Debian ist für viele Server eine wichtige Grundlage – auch im Umfeld von Virtualisierung und Hosting. Der Debian Security Tracker weist für CVE-2026-99999 korrigierte Kernelpakete für mehrere Veröffentlichungszweige aus:

Debian 12 Bookworm: 6.1.190-1 im Security-Repository
Debian 13 Trixie: 6.12.113-1 im Security-Repository
Debian Testing beziehungsweise Unstable: korrigierte Pakete auf Basis von 7.2.11-1

Diese Angaben beziehen sich auf die vom Debian Security Tracker ausgewiesenen Paketstände. Bei Debian sollten Administratoren nicht einfach die Versionsnummer des unveränderten Linux-Kernels mit der installierten Paketversion vergleichen: Distributionen integrieren Sicherheitskorrekturen häufig in ihre eigenen Pakete und pflegen dafür entsprechende Paketversionen.

Die maßgebliche Anlaufstelle ist der Debian Security Tracker für CVE-2026-99999.

💡

Ubuntu: Den Status der eigenen Kernelpakete prüfen

Auch Ubuntu führt CVE-2026-99999 in seiner Sicherheitsdatenbank. Bei der Recherche am 20. Oktober 2026 war der Status für die dort aufgeführten Ubuntu-Versionen allerdings noch als „Needs evaluation“ angegeben.

Das ist kein Grund, die Meldung zu ignorieren. Es bedeutet vielmehr, dass sich aus diesem Eintrag zu diesem Zeitpunkt noch keine pauschale Aussage ableiten ließ, wonach für alle betroffenen Ubuntu-Versionen bereits ein korrigiertes Paket bereitsteht.

Wer Ubuntu auf einem Virtualisierungshost oder Server einsetzt, sollte deshalb den aktuellen Status der eigenen Version und des verwendeten Kernelpakets direkt bei Ubuntu kontrollieren. Dabei ist auch zu berücksichtigen, dass sich der Status nach Veröffentlichung einer Sicherheitsmeldung noch ändern kann.

Die offizielle Übersicht findet sich unter Ubuntu Security: CVE-2026-99999.

MASSNAHMEN

Was Administratoren jetzt tun sollten

Unabhängig von der verwendeten Distribution empfiehlt sich ein strukturierter Blick auf die eigenen Systeme. Dabei sollte vor allem der Host im Mittelpunkt stehen – nicht nur die virtuellen Maschinen.

Virtualisierungshosts inventarisieren

Zunächst sollte klar sein, welche physischen Systeme Linux als Host-Kernel verwenden und welche Virtualisierungsplattform dort läuft. Dazu gehören beispielsweise Proxmox VE und andere KVM-basierte Umgebungen.

Den Patchstand der Distribution prüfen

Maßgeblich sind die offiziellen Sicherheitsmeldungen und Paketversionen des jeweiligen Herstellers. Ein Vergleich allein anhand der Upstream-Kernelnummer reicht nicht immer aus, weil Distributionen Sicherheitskorrekturen zurückportieren können.

Korrigierte Pakete installieren

Sobald ein passendes Update für die eigene Distribution verfügbar ist, sollte es nach den üblichen Wartungs- und Freigabeprozessen eingespielt werden. Bei produktiven Hosts sind mögliche Auswirkungen auf laufende virtuelle Maschinen und die notwendige Wartungsplanung zu berücksichtigen.

Sicherstellen, dass der neue Kernel aktiv ist

Kernelupdates benötigen häufig einen Neustart, bevor der korrigierte Kernel tatsächlich läuft. Nach der Aktualisierung sollte deshalb kontrolliert werden, welcher Kernel aktiv ist und ob das System den erwarteten Patchstand erreicht hat.

Nicht nur die Gäste aktualisieren

Updates innerhalb einer virtuellen Maschine ersetzen nicht das Update des Host-Kernels. Die Sicherheitsgrenze, um die es bei PwnEscape geht, liegt zwischen Gast und Host. Deshalb muss die Korrektur auf dem betroffenen Host-System wirksam sein.

PRAXIS

Praxisbefehle: Welcher Kernel läuft auf dem Host?

Die folgenden Befehle sind Beispiele für die Prüfung. Bitte vor der Ausführung an die eigene Umgebung anpassen und produktive Hosts nur nach Wartungsplanung neu starten.

🔍

Laufenden Kernel prüfen

Zeigt, welcher Kernel tatsächlich läuft – unabhängig davon, was installiert ist:

Bash

uname -r
uname -v

Bei Debian enthält uname -v die Debian-Paketversion (z. B. 6.1.190-1) und lässt sich direkt mit dem Security Tracker vergleichen.

🖥

Proxmox VE

Installierte Kernel-Pakete prüfen, aktualisieren und nach dem Neustart kontrollieren:

Bash

pveversion -v | grep -i proxmox-kernel
apt update
apt full-upgrade
# Neustart nur nach Wartungsplanung:
# reboot

# Nach dem Neustart: sollte 7.0.14-24-pve zeigen
uname -r

Welches Repository genutzt wird (pve-no-subscription oder Enterprise), bestimmt, wann das Paket verfügbar ist.

💻

Debian und Ubuntu

Verfügbare Kernel-Updates anzeigen, einspielen und installierte Kernel auflisten:

Bash

apt update
apt list --upgradable 2>/dev/null | grep -i linux-image
apt full-upgrade
apt list --installed 'linux-image*'

# Falls installiert: prüft, ob ein Neustart wegen des Kernels nötig ist
needrestart -k

Bei Ubuntu zusätzlich den Status auf der Ubuntu-Sicherheitsseite kontrollieren, bevor man von einem verfügbaren Fix ausgeht.

🔄

Cluster: VMs vor dem Neustart verschieben

In einem Proxmox-Cluster lassen sich laufende VMs per Live-Migration auf einen bereits gepatchten Node verschieben, bevor der nächste Host neu startet:

Bash

qm migrate   --online

Ob das in der eigenen Umgebung funktioniert, hängt unter anderem von Storage und CPU-Kompatibilität ab. Vorher auf einer unkritischen VM testen.

BEI RDDZ

Was wir bei RDDZ unternommen haben

Sicherheitsmeldungen wie PwnEscape zeigen, warum es bei gemieteten oder selbst betriebenen Servern nicht ausreicht, Updates nur gelegentlich und ohne Blick auf ihre Bedeutung einzuspielen.

Wir haben unsere Host-Systeme im Zusammenhang mit dieser Schwachstelle überprüft und die verfügbare Kernel-Korrektur zeitnah nach der Veröffentlichung eingespielt.

Für Kunden ist dabei besonders wichtig, dass Sicherheitsmaßnahmen nicht an der Oberfläche enden. Bei einer Schwachstelle im Host-Kernel muss die zugrunde liegende Virtualisierungsinfrastruktur betrachtet werden – zusätzlich zu den Betriebssystemen und Anwendungen, die innerhalb der virtuellen Maschinen laufen.

Wie bei jeder Sicherheitslücke gilt: Eine zeitnahe Aktualisierung ist ein wesentlicher Schritt, ersetzt aber keine laufende Wartung und Überwachung. Wir behalten relevante Sicherheitsmeldungen deshalb im Blick und setzen notwendige Korrekturen auf unseren Systemen nach Verfügbarkeit und unter Berücksichtigung des jeweiligen Betriebsumfelds um.

FAZIT

Schnelle Updates sind entscheidend

PwnEscape ist ein gutes Beispiel dafür, dass Sicherheitslücken im Linux-Kernel auch die Isolation virtualisierter Systeme betreffen können. Die mögliche Auswirkung ist ernst, sollte aber nicht mit der pauschalen Behauptung verwechselt werden, jede KVM- oder Proxmox-Umgebung sei automatisch kompromittiert.

Die wichtigste Empfehlung für Betreiber eigener Server: Host-Kernel und Sicherheitsmeldungen der jeweiligen Distribution im Blick behalten, Updates zeitnah installieren und anschließend prüfen, ob der korrigierte Kernel tatsächlich aktiv ist. Die Befehle oben helfen dabei.

QUELLEN

Weiterführende Quellen

Eigene Server oder Proxmox-Hosts sicher betreiben?

Patchstand, Kernel-Updates und Wartungsfenster nicht allein im Blick behalten? Sprechen Sie uns an, wir unterstützen bei Betrieb, Wartung und Absicherung.

Der Beitrag PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann erschien zuerst auf RDDZ.

WG Tunnel Desktop: Mehr als nur ein WireGuard-Client für Windows, Linux und macOS

dennis_rddz — Mon, 19 Oct 2026 20:59:23 +0000

WG TUNNEL · DESKTOP · WINDOWS, LINUX, MACOS

WG Tunnel Desktop: Mehr als nur ein WireGuard-Client für Windows, Linux und macOS

Wer WireGuard nutzt, kennt das Prinzip: Konfiguration importieren, Verbindung einschalten, fertig. Für viele Einsatzzwecke reicht das völlig aus. Sobald man aber mehrere VPN-Verbindungen verwalten, den Datenverkehr gezielter steuern oder eine Verbindung beim Wechsel des Netzwerks automatisch anpassen möchte, stößt man mit einem einfachen VPN-Client schnell an Grenzen.

WG TUNNEL DESKTOP 2.4.1

● Seit 17.10.2026

MIT-Lizenz

Open Source

3 Plattformen

Windows, Linux, macOS

AmneziaWG

2.0 bis 3.1

Kill Switch ✓ systemweit

Auto-Tunneling ✓ nach Netzwerkbedingungen

Multihop ✓ seit Version 2.4.0

Lokaler Proxy ✓ HTTP, SOCKS4, SOCKS5

Kein VPN-Anbieter: Eine eigene WireGuard- oder AmneziaWG-Konfiguration wird weiterhin benötigt.

✓ Aktuell: Version 2.4.1 vom 17. Oktober 2026

✓ Open Source unter MIT-Lizenz

✓ Windows, Linux und macOS (Apple Silicon)

✓ Kill Switch, Auto-Tunneling, Proxy und DNS-Steuerung

✓ Mit Installationsanleitung für alle Plattformen

EINFÜHRUNG

Wenn ein einfacher Schalter nicht mehr reicht

Genau hier setzt WG Tunnel Desktop an. Das Open-Source-Projekt erweitert WireGuard um zahlreiche Funktionen, die man sonst eher aus umfangreicheren VPN-Lösungen kennt. Dazu gehören ein systemweiter Kill Switch, automatische Tunnelaktivierung, DNS-Steuerung, ein lokaler Proxy und inzwischen sogar Multihop-Verbindungen.

WG Tunnel ist übrigens kein neues Projekt. Die Android-App gibt es schon deutlich länger und sie hat sich dort mit zahlreichen Zusatzfunktionen etabliert. Mit der Desktop-Version bringt Entwickler Zane Schepke einen großen Teil dieses Funktionsumfangs auf den PC – inzwischen für Windows, Linux und macOS mit Apple Silicon.

Aktuell ist WG Tunnel Desktop 2.4.1, veröffentlicht am 17. Oktober 2026.

ÜBERBLICK

Was ist WG Tunnel Desktop eigentlich?

WG Tunnel Desktop ist ein alternativer, quelloffener Client für WireGuard und AmneziaWG. Die Anwendung verwendet weiterhin die bewährte VPN-Technik, ergänzt sie aber um Funktionen für Automatisierung, Sicherheit und komfortablere Verwaltung.

Das Projekt steht unter der MIT-Lizenz und wird auf GitHub entwickelt. Die Desktop-Version teilt sich wesentliche Teile ihrer Tunnel-, DNS- und Wiederherstellungslogik mit der Android-App. Dadurch kommen viele Funktionen, die man bisher vor allem vom Smartphone kannte, auch auf den Desktop.

Wichtige Unterscheidung

WG Tunnel ist kein eigener VPN-Anbieter und liefert nicht automatisch einen VPN-Server mit. Du benötigst weiterhin eine passende WireGuard- oder AmneziaWG-Konfiguration und einen erreichbaren VPN-Endpunkt – beispielsweise auf dem eigenen Router, einem Server zu Hause oder einem gemieteten VPS.

FUNKTIONEN

Diese Funktionen bringt WG Tunnel Desktop mit

Die Liste ist inzwischen ziemlich umfangreich. Nicht jede Funktion ist für jeden Nutzer notwendig. Gerade in Kombination können die einzelnen Möglichkeiten aber einen spürbaren Unterschied machen.

WireGuard und AmneziaWG

WG Tunnel unterstützt klassische WireGuard-Tunnel und AmneziaWG. AmneziaWG erweitert WireGuard um Möglichkeiten zur Verschleierung des Datenverkehrs, die in geeigneten Umgebungen helfen können, bestimmte Formen der Protokollerkennung zu umgehen.

Laut Projekt unterstützt die Desktop-Version AmneziaWG 2.0 bis 3.1. Ob das im eigenen Netzwerk einen Vorteil bringt, hängt unter anderem von der eingesetzten Gegenstelle und den jeweiligen Einschränkungen ab.

Auto-Tunneling: VPN automatisch aktivieren

Mit Auto-Tunneling lassen sich VPN-Verbindungen abhängig von den Eigenschaften des aktiven Netzwerks automatisch aktivieren. Die Desktop-Variante ist dabei etwas einfacher gehalten als die Android-Version.

Das ist beispielsweise praktisch, wenn ein Notebook im eigenen WLAN anders arbeiten soll als unterwegs oder in einem fremden Netzwerk. Statt jedes Mal manuell den richtigen Tunnel einzuschalten, kann WG Tunnel die Verbindung anhand der erkannten Netzwerkbedingungen verwalten.

Unter macOS wurde die WLAN-Erkennung in Version 2.4.1 weiter verbessert. Dafür benötigt die Anwendung entsprechende Standort- beziehungsweise WLAN-Berechtigungen.

Deferred Endpoint Bootstrapping: Schutz schon beim Start

Eine der interessantesten Funktionen steckt weniger in der Oberfläche als in der Art, wie WG Tunnel den Verbindungsaufbau behandelt. Viele VPN-Clients müssen zunächst die Adresse des Gegenübers auflösen, bevor der Tunnel vollständig gestartet werden kann. Wenn DNS gerade nicht funktioniert oder das Netzwerk langsam reagiert, kann sich der Aufbau verzögern.

WG Tunnel geht einen anderen Weg: Zunächst werden die Tunnel-Schnittstelle, Routen und Firewall-Regeln eingerichtet. Die Auflösung der Gegenstellen erfolgt anschließend im Hintergrund und wird bei Bedarf wiederholt.

Der Vorteil: Der Schutz soll nicht erst dann beginnen, wenn die Gegenstelle erfolgreich aufgelöst wurde. Das kann die Zeit verringern, in der der normale Netzwerkverkehr noch nicht durch den Tunnel geschützt ist. Das ist besonders interessant bei instabilen Verbindungen oder wenn ein VPN möglichst zuverlässig beim Systemstart verfügbar sein soll. Es ist allerdings kein Freifahrtschein: Die tatsächliche Schutzwirkung hängt weiterhin von der Konfiguration und den Firewall-Regeln ab.

Kill Switch: Verbindungen bei einem Ausfall blockieren

Ein Kill Switch soll verhindern, dass Netzwerkverkehr ungewollt über die normale Internetverbindung läuft, wenn ein VPN-Tunnel ausfällt oder nicht verfügbar ist. Bei WG Tunnel Desktop ist der Kill Switch eine eigenständige systemweite Einstellung. Er hängt also nicht ausschließlich davon ab, ob gerade ein bestimmter Tunnel aktiv ist.

Zusätzlich lässt sich der Schutz für den Systemstart wiederherstellen. Nach einem Neustart kann WG Tunnel die entsprechenden Regeln erneut anwenden.

Je nach Konfiguration kann es außerdem wichtig sein, lokalen LAN-Verkehr gezielt zu erlauben. Genau in diesem Bereich gab es in Version 2.4.0 und 2.4.1 weitere Fehlerkorrekturen. Wer den Kill Switch nutzt, sollte nach dem Update prüfen, ob die gewünschte Erreichbarkeit lokaler Geräte erhalten bleibt.

Tunnel und Gruppen verwalten

WG Tunnel bietet mehr als eine einfache Liste mit Einträgen zum Ein- und Ausschalten. Tunnel lassen sich importieren, exportieren und bearbeiten. Hinzu kommen Sortiermöglichkeiten, Live-Statistiken und Tunnel-Gruppen.

Gerade wer mehrere Standorte, Server oder unterschiedliche Einsatzzwecke hat, profitiert davon. Beispielsweise lassen sich Verbindungen für das Heimnetz, einen Serverstandort oder den Zugriff auf bestimmte interne Dienste übersichtlicher organisieren.

Die Statistiken zeigen unter anderem die Laufzeit der Verbindung. Im Proxy-Modus werden außerdem Informationen zur aktiven Proxy-Adresse und zum Authentifizierungsstatus angezeigt.

Multihop: VPN-Verbindungen hintereinander schalten

Mit Desktop-Version 2.4.0 kam die Unterstützung für Multihop-Verbindungen hinzu. Dabei wird ein Tunnel innerhalb eines anderen Tunnels verwendet. Vereinfacht gesagt läuft der Datenverkehr damit nicht nur über eine einzelne VPN-Verbindung, sondern über mehrere aufeinanderfolgende Stationen. Das kann für spezielle Netzwerktopologien oder bewusst getrennte Verbindungswege interessant sein.

Allerdings gilt auch hier: Mehr Hops bedeuten nicht automatisch mehr Sicherheit. Entscheidend ist, wer die einzelnen Endpunkte betreibt, wie die Routen eingerichtet sind und welchem Zweck die zusätzliche Station dient. Außerdem können zusätzliche Stationen Latenz und Komplexität erhöhen.

WEITERE FUNKTIONEN

Proxy, DNS, Systemdienst und mehr

Lokaler Proxy: VPN für ausgewählte Anwendungen nutzen

WG Tunnel kann eine VPN-Verbindung über einen lokalen HTTP- oder SOCKS-Proxy bereitstellen. Anwendungen, die einen solchen Proxy unterstützen, können den Tunnel dadurch gezielt verwenden. Das ist eine interessante Alternative, wenn nicht der gesamte Rechnerverkehr über das VPN laufen soll.

Die Desktop-Version unterstützt HTTP, SOCKS4 und SOCKS5. SOCKS4 wurde in Version 2.4.0 ergänzt; Version 2.4.1 behebt unter anderem Probleme im Proxy-Modus mit benutzerdefiniertem Tunnel-DNS.

Dabei sollte man die Grenzen kennen: Ein Proxy wirkt nur für Programme, die tatsächlich über ihn kommunizieren. Er ist nicht dasselbe wie ein systemweiter VPN-Tunnel.

Split DNS und verschlüsseltes DNS

DNS-Anfragen lassen sich durch den Tunnel leiten. WG Tunnel unterstützt dafür klassisches DNS sowie verschlüsselte Varianten über DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH). Zusätzlich kann DNS anhand von Domain-Suffixen aufgeteilt werden. Bestimmte Domains können dadurch über den Tunnel aufgelöst werden, während andere die System-DNS-Konfiguration verwenden.

Das ist vor allem in Umgebungen mit internen Domains interessant. Ein Beispiel wäre ein Heimnetz, in dem interne Hostnamen nur über einen bestimmten VPN-Server aufgelöst werden können.

Eine wichtige Einschränkung: Die Desktop-Version bietet kein App-basiertes Split Tunneling wie die Android-App. Die DNS-Aufteilung nach Domains ist davon zu unterscheiden – sie legt fest, wie Namen aufgelöst werden, nicht pauschal, welche Anwendung welchen Netzwerkweg nimmt.

Dynamische DNS- und IPv6-Behandlung

Wer einen VPN-Endpunkt mit dynamischer IP-Adresse betreibt, kennt das Problem: Ändert sich die öffentliche Adresse, kann die bisherige Verbindung ins Leere laufen. WG Tunnel kann Änderungen erkennen und Endpunkte aktualisieren, ohne dass die Anwendung dafür komplett neu gestartet werden muss.

Auch IPv6 wird berücksichtigt. Je nach Netzwerkbedingungen kann WG Tunnel IPv6-Endpunkte bevorzugen oder auf IPv4 zurückfallen. Das soll Verbindungen robuster machen, wenn ein Netzwerk IPv6 nur teilweise oder gar nicht unterstützt.

Gerade bei wechselnden WLANs, mobilen Anschlüssen oder selbst betriebenen VPN-Endpunkten können solche Funktionen im Alltag helfen.

Systemdienst statt ausschließlich grafischer Anwendung

Ein weiterer Unterschied zu einer rein grafischen Anwendung: WG Tunnel Desktop besteht nicht nur aus dem sichtbaren Fenster. Ein eigenständiger Systemdienst kümmert sich um den Tunnelbetrieb.

Das bedeutet, dass der VPN-Tunnel weiterlaufen kann, auch wenn die grafische Oberfläche geschlossen ist. Zusammen mit der Wiederherstellung beim Systemstart ist das sinnvoll für Rechner, die dauerhaft erreichbar sein sollen oder auf denen ein VPN zuverlässig im Hintergrund laufen muss.

Die grafische Oberfläche kann außerdem in den System-Tray minimiert werden. Ein Statussymbol informiert über den Verbindungszustand.

Verschlüsselte Speicherung sensibler Daten

VPN-Konfigurationen enthalten sensible Informationen, etwa private Schlüssel und Endpunktdaten. WG Tunnel speichert Tunnelkonfigurationen und weitere vertrauliche Daten laut Projekt verschlüsselt in einer lokalen Datenbank mit AES-256-GCM. Der Schlüssel für diese Verschlüsselung wird im Schlüsselbund beziehungsweise im Anmeldeinformationsspeicher des Betriebssystems abgelegt.

Das ist eine sinnvolle zusätzliche Schutzmaßnahme. Sie ersetzt allerdings weder eine sichere Benutzerkontenverwaltung noch die Sicherung des Rechners selbst.

Automatische Updates und weitere Desktop-Funktionen

WG Tunnel besitzt einen integrierten Updater mit Update-Benachrichtigungen. Die automatische Aktualisierung ist laut Projekt für Windows-Installationen sowie direkt installierte .deb– und .rpm-Pakete vorgesehen. Andere Linux-Installationswege können manuelle Updates erfordern.

Außerdem wurde die Anwendung als natives Programm auf Basis von GraalVM umgesetzt, statt eine komplette Java-Laufzeitumgebung mitzuliefern. Der Entwickler nennt dadurch kürzere Startzeiten und einen geringeren Speicherbedarf als wichtige Ziele dieser Umstellung.

Unter Linux unterstützt die Anwendung Wayland nativ und kann bei Bedarf auf X11 zurückfallen.

AKTUELLE VERSION

Was ist in Version 2.4.1 neu?

Die aktuelle Version 2.4.1 erschien am 17. Oktober 2026. Sie ist vor allem ein Wartungs- und Verbesserungsupdate mit einigen wichtigen Korrekturen:

Langsame Tunnelstarts unter Windows wurden verbessert.
Unter macOS kamen Verbesserungen an der WLAN-Erkennung für Auto-Tunneling hinzu.
Das Verhalten der Anwendung im macOS-Dock wurde korrigiert.
Probleme im Proxy-Modus mit benutzerdefiniertem Tunnel-DNS wurden behoben.
Die Unterstützung für getunnelte virtuelle Maschinen unter macOS wurde ergänzt beziehungsweise verbessert.
Zusätzlich gab es weitere Korrekturen und Aktualisierungen.

Bereits Version 2.4.0 hatte Multihop, SOCKS4-Unterstützung, Verbesserungen bei Tunnel-Gruppen, Korrekturen am Kill Switch und Optimierungen für den Tunnelstart unter Windows eingeführt.

Wer WG Tunnel bereits einsetzt, sollte deshalb die Release Notes im Blick behalten. Gerade bei einem VPN-Client können Fehlerkorrekturen an Firewall-Regeln, DNS oder dem Verbindungsaufbau wichtiger sein als neue Funktionen auf der Oberfläche.

INSTALLATION

So kommt WG Tunnel auf den Rechner

Die Installation unterscheidet sich je nach Betriebssystem. Lade die Anwendung am besten direkt aus dem offiziellen GitHub-Projekt herunter. Dort findest du die passenden Pakete für Windows, Linux und macOS.

WG Tunnel Desktop – aktuelle Releases auf GitHub

🪟

Windows 10 und Windows 11

Voraussetzung ist Windows 10 ab Version 1803 oder neuer.

Öffne die Release-Seite auf GitHub.
Lade die aktuelle Windows-Installationsdatei mit der Endung .exe herunter.
Starte den Installer und bestätige die erforderliche Administratorabfrage.
Dadurch kann der Systemdienst eingerichtet werden, der für Tunnel, Routen und Firewall-Regeln benötigt wird.
Starte anschließend WG Tunnel und importiere deine vorhandene WireGuard-Konfiguration.

Alternativ kann die Installation über WinGet erfolgen:

PowerShell

winget install -e --id WGTunnel.WGTunnel

Wichtig bei einem Upgrade: Wer noch die alte Desktop-Version 1.x installiert hat, muss diese vor dem Wechsel auf Version 2.x deinstallieren. Die Installationsarchitektur wurde geändert; die alte und die neue Version können nicht parallel bestehen.

🍎

macOS auf Apple Silicon

Die Desktop-Version unterstützt macOS 13 (Ventura) oder neuer auf Macs mit Apple Silicon. Intel-Macs werden derzeit nicht unterstützt.

Lade die aktuelle .dmg-Datei von der GitHub-Release-Seite.
Öffne das Image und ziehe WG Tunnel in den Programme-Ordner.
Starte die Anwendung.
Erlaube den angeforderten Hintergrunddienst in den macOS-Systemeinstellungen.

Alternativ ist die Installation über Homebrew möglich:

Bash

brew tap wgtunnel/wgtunnel
brew trust wgtunnel/wgtunnel
brew install --cask wg-tunnel

Beim ersten Start muss macOS den Hintergrunddienst freigeben. Die Anwendung führt dich zu der entsprechenden Einstellung.

🐧

Linux: Debian und Ubuntu

Für Debian- und Ubuntu-basierte Systeme gibt es ein eigenes APT-Repository. Der Installationsweg laut Projekt:

Bash

wget -qO- https://apt.wgtunnel.com/install.sh | sh

Wie bei jedem Installationsskript aus dem Internet empfiehlt es sich, das Skript vor der Ausführung zu prüfen. Alternativ kannst du das .deb-Paket direkt von GitHub laden und lokal installieren:

Bash

sudo apt install ./wgtunnel*.deb

🎩

Linux: Fedora und RHEL

Für Fedora und RHEL steht ein COPR-Repository zur Verfügung:

Bash

sudo dnf copr enable zaneschepke/wgtunnel
sudo dnf install wgtunnel

Alternativ kannst du das aktuelle .rpm-Paket aus den GitHub-Releases herunterladen und installieren.

⚙

Linux: Arch Linux

Für Arch Linux ist das Paket über das AUR verfügbar:

Bash

yay -S wgtunnel-bin

Bei einer direkten Installation des .pacman-Pakets muss der Dienst anschließend aktiviert und gestartet werden:

Bash

sudo pacman -U wgtunnel*.pacman
sudo systemctl enable --now wgtunnel-daemon.service

⚠

Linux-Hinweise

Die Firewall muss nftables oder iptables mit dem nft-Backend verwenden. Bei systemd-basierten Distributionen startet der Dienst automatisch beim Systemstart. Bei anderen Init-Systemen ist zusätzliche Einrichtung erforderlich.

Snap, Flatpak und AppImage werden vom Projekt derzeit nicht angeboten.

ERSTER TUNNEL

Nach der Installation: Den ersten Tunnel einrichten

Wenn WG Tunnel installiert ist, brauchst du eine bestehende WireGuard- oder AmneziaWG-Konfiguration. Das ist in der Regel eine .conf-Datei, die du von deinem VPN-Server oder Router erhältst.

Konfiguration importieren

Öffne WG Tunnel und importiere deine Konfiguration über die Tunnelverwaltung.

Einstellungen prüfen

Prüfe die Gegenstellenadresse, die erlaubten IP-Bereiche und die DNS-Einstellungen.

Tunnel aktivieren

Aktiviere den Tunnel und kontrolliere, ob der Handshake zustande kommt.

Zugriff testen

Teste den Zugriff auf die gewünschten Ziele – zum Beispiel interne Server oder Dienste im Heimnetz.

Kill Switch bewusst testen

Wenn du den Kill Switch verwenden möchtest, richte ihn bewusst ein und teste anschließend, was bei einem getrennten Tunnel passiert. Prüfe dabei auch, ob lokaler LAN-Verkehr, Drucker oder andere interne Geräte weiterhin wie gewünscht erreichbar sind.

Bei einer Proxy-Konfiguration muss außerdem die jeweilige Anwendung auf die lokale Proxy-Adresse eingestellt werden. Ein aktivierter WG-Tunnel allein bedeutet nicht automatisch, dass jedes Programm den lokalen Proxy nutzt.

VERGLEICH

WG Tunnel Desktop oder der normale WireGuard-Client?

Der offizielle WireGuard-Client ist keineswegs schlecht. Im Gegenteil: Er ist eine gute Wahl, wenn du klassische WireGuard-Konfigurationen möglichst einfach importieren und aktivieren möchtest. Er konzentriert sich bewusst auf das Wesentliche. WG Tunnel Desktop richtet sich eher an Nutzer, die mehr Kontrolle über das Verhalten ihrer VPN-Verbindungen benötigen.

Funktion	Offizieller WireGuard-Client	WG Tunnel Desktop
Klassische WireGuard-Tunnel	Ja	Ja
AmneziaWG	Nein	Ja
Systemweiter Kill Switch	Nicht als vergleichbare integrierte Funktion	Ja
Auto-Tunneling nach Netzwerkbedingungen	Nicht in vergleichbarer Form integriert	Ja
Lokaler HTTP-/SOCKS-Proxy	Nicht integriert	Ja
Verschlüsseltes und aufgeteiltes DNS	Nicht in diesem Funktionsumfang integriert	Ja
Dynamische Endpunkt-Wiederherstellung	Nicht in diesem Funktionsumfang integriert	Ja
Multihop-Funktion in der Anwendung	Nicht integriert	Ja
Tunnel-Gruppen und erweiterte Verwaltung	Einfachere Verwaltung	Ja
Systemdienst und Wiederherstellung beim Booten	Abhängig vom Betriebssystem und der Integration	Als Desktop-Funktion vorgesehen

Der Vergleich bezieht sich auf die integrierten Funktionen der jeweiligen Anwendungen. WireGuard selbst ist das Protokoll; was sich mit dem offiziellen Client erreichen lässt, kann je nach Betriebssystem, Netzwerk und zusätzlichen Systemwerkzeugen variieren.

Wo WG Tunnel besonders punktet

Der größte Vorteil ist die Kombination der Funktionen. Wer mehrere Tunnel betreibt, DNS gezielt steuern möchte, einen Proxy benötigt oder sicherstellen will, dass bei einem Tunnel-Ausfall nicht einfach der normale Internetzugang übernimmt, bekommt mit WG Tunnel viele dieser Möglichkeiten in einer Oberfläche.

Auch die Wiederherstellung nach einem Neustart und die automatische Behandlung wechselnder Endpunktadressen sind für Rechner interessant, die nicht nur gelegentlich manuell verbunden werden.

Wer dagegen nur einen einzigen Tunnel benötigt, den er bei Bedarf einschaltet, braucht nicht unbedingt einen zusätzlichen Client. In diesem Fall bleibt die offizielle WireGuard-Anwendung eine schlanke und unkomplizierte Lösung.

ANDROID

Und was ist mit der Android-Version?

WG Tunnel wurde ursprünglich für Android entwickelt und ist dort schon länger verfügbar. Viele der erweiterten Funktionen – etwa Auto-Tunneling, Proxy-Modus, DNS-Steuerung und Kill-Switch-Funktionen – stammen aus dieser Entwicklung.

Die Desktop-Version bringt einen großen Teil dieser Ideen auf den PC, ist aber kein vollständiger Klon der Android-App. Unterschiede gibt es unter anderem bei Split Tunneling, den Systemberechtigungen und der Integration in das jeweilige Betriebssystem.

Wer WG Tunnel bisher nur vom Smartphone kennt, findet mit der Desktop-Version also eine interessante Ergänzung für den eigenen Rechner.

Passend dazu: Unseren bereits veröffentlichten Beitrag zu den Neuerungen von WG Tunnel für Android findest du im RDDZ-Newsbereich. Dort behandeln wir die Android-Version getrennt von der Desktop-Reihe.

FAZIT

Für wen lohnt sich WG Tunnel Desktop?

WG Tunnel Desktop ist besonders dann interessant, wenn WireGuard zwar die richtige Basis ist, die Standardfunktionen des Clients aber nicht mehr ausreichen.

Die Kombination aus Kill Switch, Auto-Tunneling, DNS-Steuerung, Proxy-Modus, dynamischer Endpunktbehandlung und Tunnel-Gruppen macht die Anwendung zu einer vielseitigen Alternative. Mit AmneziaWG und Multihop kommen zusätzliche Möglichkeiten für spezielle Anforderungen hinzu.

Die Software ist Open Source und für Windows, Linux sowie Apple-Silicon-Macs verfügbar. Gleichzeitig sollte man im Hinterkopf behalten, dass ein VPN-Client mit Systemdienst, Firewall-Regeln und automatischer Wiederherstellung mehr Verantwortung trägt als ein einfacher Schalter im Fenster. Wer die erweiterten Funktionen nutzt, sollte die eigene Konfiguration deshalb sorgfältig prüfen.

Für alle, die WireGuard bereits einsetzen und mehr Kontrolle über ihre Verbindungen möchten, ist WG Tunnel Desktop definitiv einen Blick wert.

QUELLEN

Quellen und Links

WireGuard-VPN für Team oder Standort einrichten?

Von der WireGuard-Anbindung bis zur Netzwerkplanung: Sprechen Sie uns an, wir unterstützen bei Konzept, Einrichtung und Betrieb.

Der Beitrag WG Tunnel Desktop: Mehr als nur ein WireGuard-Client für Windows, Linux und macOS erschien zuerst auf RDDZ.

WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen

dennis_rddz — Mon, 19 Oct 2026 20:56:30 +0000

WG TUNNEL · ANDROID · 19.10.2026

WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen

WG Tunnel für Android hat ein weiteres Update erhalten. Mit Version 5.8.2, veröffentlicht am 19. Oktober 2026, verbessert der Open-Source-VPN-Client nicht nur die Bedienung, sondern behebt auch mehrere Fehler aus den vorherigen Versionen. Dazu kommen ein dynamisches AMOLED-Design und eine neue Möglichkeit, Server direkt vom Hauptbildschirm aus anzupingen – auch dann, wenn gerade kein VPN-Tunnel aktiv ist.

WG TUNNEL 5.8.2

● Seit 19.10.2026

AMOLED

dynamisches Theme

Ping

ohne aktiven Tunnel

Fixes

TV, Split Tunneling

Neu ✓ AMOLED-Theme, Ping

Android TV ✓ Import & Backup korrigiert

Split Tunneling ✓ Speichern korrigiert

Empfehlung ✓ Update für Android-Nutzer

Update → Tunnel starten → Sonderfunktionen kurz prüfen

✓ Release: 19. Oktober 2026

✓ Dynamisches AMOLED-Theme

✓ Server-Ping ohne aktiven Tunnel

✓ Fixes für Android TV und Split Tunneling

✓ Open-Source-VPN-Client für Android

NEUERUNGEN

Was ist neu in WG Tunnel 5.8.2?

Bereits Version 5.8.0 hatte mit Multihop-Tunneln und Tunnel-Gruppen größere Neuerungen eingeführt. Die nachfolgenden Updates konzentrieren sich nun stärker auf Stabilität, Bedienkomfort und die Korrektur konkreter Probleme.

🌙

Dynamisches AMOLED-Design

Wer auf dem Smartphone ein dunkles Erscheinungsbild bevorzugt, bekommt mit 5.8.2 eine weitere Option: ein dynamisches AMOLED-Theme. Gerade auf Geräten mit OLED-Display kann eine konsequent dunkle Darstellung angenehm sein und den Energieverbrauch reduzieren, abhängig von Display und Nutzung.

Das neue Theme ist eine Ergänzung zu den vorhandenen Darstellungsmöglichkeiten und gehört zu den sichtbaren Neuerungen dieser Version.

📡

Server direkt vom Hauptbildschirm anpingen

Eine praktische Verbesserung für die Fehlersuche: WG Tunnel kann Server jetzt direkt vom Hauptbildschirm aus anpingen, selbst wenn kein Tunnel aktiv ist.

Das erleichtert die erste Diagnose bei Verbindungsproblemen. So lässt sich beispielsweise prüfen, ob ein Ziel grundsätzlich erreichbar ist, bevor man sich mit der VPN-Konfiguration beschäftigt. Ein erfolgreicher Ping beweist allerdings nicht automatisch, dass auch der WireGuard-Handshake oder der gesamte Tunnel funktioniert.

📺

Verbesserungen für Android TV

Auch Nutzer von Android TV profitieren vom Update. Die Entwickler haben Fehler beim Importieren von Konfigurationen korrigiert. Außerdem wurden Probleme rund um Backup und Wiederherstellung behoben und die Unterstützung für Android TV dabei verbessert.

Das ist insbesondere dann hilfreich, wenn Tunnel-Konfigurationen auf einem Fernseher oder einer TV-Box eingerichtet, gesichert oder auf ein anderes Gerät übertragen werden sollen.

🔀

Korrekturen bei Split Tunneling

Version 5.8.2 behebt außerdem Probleme mit veralteten beziehungsweise nicht korrekt gespeicherten Änderungen an der Split-Tunnel-Konfiguration. Die Bedienung wurde in diesem Bereich ebenfalls verbessert.

Beim Split Tunneling wird festgelegt, welche Apps oder Verbindungen den VPN-Tunnel verwenden und welche davon ausgenommen sind. Gerade bei solchen Einstellungen ist es wichtig, dass Änderungen zuverlässig gespeichert werden und anschließend tatsächlich der gewünschten Konfiguration entsprechen.

SEIT VERSION 5.8.0

Was wurde seit Version 5.8.0 korrigiert?

Nicht alle Änderungen stecken direkt in 5.8.2. Bereits die Zwischenversion 5.8.1 brachte eine wichtige Fehlerkorrektur mit.

WG Tunnel 5.8.1: SOCKS5-Proxy und Lockdown-DNS

In Version 5.8.0 waren Fehler bei der DNS-Auflösung im Zusammenhang mit dem SOCKS5-Proxy und dem Lockdown-Modus eingeführt worden. Version 5.8.1 korrigierte diese Probleme. Wer diese Funktionen nutzt, sollte deshalb mindestens eine korrigierte Version verwenden. Die aktuelle Version 5.8.2 enthält diese Korrektur ebenfalls.

Rückblick: Die größeren Neuerungen aus 5.8.0

Mit Version 5.8.0 kamen unter anderem folgende Funktionen hinzu:

Multihop-Tunnel

VPN-Verbindungen lassen sich hintereinander schalten.

Tunnel-Gruppen

Mehrere Tunnel können übersichtlicher organisiert und verwaltet werden.

IPv6- und Proxy-Korrekturen

Fehler beim lokalen Proxy und bei IPv6-bezogenen Einstellungen wurden behoben.

Auto-Tunnel

Verbesserungen bei der Netzwerkerkennung, bei Android Auto und bei gerätespezifischen Besonderheiten.

Bedienung

Überarbeitungen an Split-Tunnel- und DNS-Einstellungen.

Wer bereits Version 5.8.0 nutzt, erhält mit 5.8.2 also nicht nur neue Komfortfunktionen, sondern auch die nachfolgenden Fehlerkorrekturen.

EMPFEHLUNG

Sollte man auf WG Tunnel 5.8.2 aktualisieren?

Ja, das Update ist für bestehende Android-Nutzer empfehlenswert. Besonders interessant ist es für alle, die den SOCKS5-Proxy, den Lockdown-Modus, Split Tunneling oder Android TV verwenden.

Auch wer WG Tunnel nur mit einer einzelnen WireGuard-Verbindung nutzt, profitiert von den allgemeinen Verbesserungen und Fehlerkorrekturen. Die neuen Funktionen für AMOLED-Darstellung und Ping-Tests sind zusätzliche Vorteile, aber nicht für jeden Einsatzzweck zwingend erforderlich.

Nach einem Update lohnt es sich, kurz zu prüfen, ob die eigenen Tunnel wie erwartet starten und ob besondere Einstellungen – etwa Split Tunneling, DNS oder Proxy – weiterhin korrekt funktionieren.

DOWNLOAD

Wo gibt es WG Tunnel 5.8.2?

Die Android-Version ist über verschiedene Bezugsquellen verfügbar. Welche Version bereits angeboten wird, kann je nach Store und Veröffentlichungszeitpunkt variieren.

📦

GitHub

Die offiziellen Releases und die APK-Dateien direkt aus dem Projekt.

📱

IzzyOnDroid

Ein alternativer Store für freie Android-Apps.

▶

Google Play

Verfügbarkeit und Aktualisierungsstand bitte direkt im Store prüfen.

Wer die APK direkt herunterlädt, sollte darauf achten, dass sie aus dem offiziellen Projekt stammt. Für Version 5.8.2 nennt der Entwickler folgenden SHA-256-Fingerabdruck des Signaturzertifikats:

SHA-256 (Signaturzertifikat)

5204d82e766e8aa14dcbb06dc70aebae2bdd812d4d6203cd521a8a685d7d3d80

Die Signatur lässt sich nach dem Download beispielsweise mit apksigner prüfen:

Bash

apksigner verify --print-certs [Pfad zur APK] | grep SHA-256

Der ausgegebene Fingerabdruck muss mit dem vom Projekt veröffentlichten Wert übereinstimmen.

ANDROID & DESKTOP

Android und Desktop künftig getrennt betrachten

WG Tunnel ist inzwischen nicht mehr nur ein Android-Projekt. Mit dem Desktop-Client gibt es auch Varianten für Windows, Linux und macOS. Die Desktop-Version besitzt eigene Releases und plattformspezifische Installationswege.

Deshalb werden wir die beiden Varianten künftig getrennt behandeln: Dieser Beitrag konzentriert sich auf WG Tunnel für Android. Ein eigener Artikel für WG Tunnel Desktop kann dann die jeweiligen Neuerungen, Installationswege und Besonderheiten unter Windows, Linux und macOS behandeln.

QUELLEN

Quellen und Links

VPN, Netzwerk oder Fernzugriff einrichten?

Von WireGuard-Anbindungen bis zur Netzwerkplanung: Sprechen Sie uns an, wir unterstützen bei Konzept, Einrichtung und Betrieb.

Der Beitrag WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen erschien zuerst auf RDDZ.

UniFi OS und Protect hinter Caddy: Wenn die Oberfläche im Ladebalken hängen bleibt

dennis_rddz — Mon, 19 Oct 2026 18:25:33 +0000

RDDZ PRAXIS · UNIFI · CADDY

UniFi OS und Protect hinter Caddy: Wenn die Oberfläche im Ladebalken hängen bleibt

Caddy 2.11.6, UniFi Protect und ein Reverse Proxy mit gültigem TLS-Zertifikat: Eigentlich sollte der Zugriff auf die UniFi-Oberfläche problemlos funktionieren. In meinem Test blieb die Oberfläche jedoch beim Laden hängen.

CADDY → UNIFI · VON RDDZ

● Getestet mit Caddy 2.11.6

Direkt am Cloud Key

WebSocket: HTTP 101

Über Caddy

WebSocket: HTTP 500

Mit Host-Header

Oberfläche lädt wieder

SymptomLadebalken hängt, WebSocket 500

Vermutete UrsacheHost-Header bei HTTPS-Upstream

Lösungheader_up Host + HTTP/1.1

Ergebnisse aus meiner konkreten Installation, Ursache nicht isoliert nachgewiesen.

✓ Direkter Zugriff auf den Cloud Key funktionierte

✓ WebSockets scheiterten über Caddy mit HTTP 500

✓ Vermutete Ursache: Host-Header bei HTTPS-Upstreams

✓ Funktionierende Caddyfile-Konfiguration inklusive

✓ Mit Quellen und Hinweisen zur eigenen Fehlersuche

AUSGANGSLAGE

Das Problem: UniFi bleibt beim Laden hängen

Die Browser-Konsole zeigte fehlgeschlagene WebSocket-Verbindungen mit HTTP-Status 500. Die Ursache lag offenbar nicht an der Firewall oder an der grundsätzlichen Erreichbarkeit des Cloud Keys. Entscheidend war eine Besonderheit beim Zusammenspiel von Caddy, HTTPS-Upstreams und den von UniFi verwendeten WebSockets.

In diesem Beitrag dokumentiere ich die Fehlersuche, die Messungen und die Konfiguration, mit der UniFi Protect anschließend wieder funktionierte.

Ich betreibe UniFi Protect auf einem Cloud Key im Heimnetz. Der Zugriff sollte über meinen zentralen Caddy-Reverse-Proxy und ein gültiges Wildcard-Zertifikat erfolgen.

Die Ausgangssituation war zunächst unspektakulär: Die Anmeldeseite wurde aufgerufen, das UniFi-Logo erschien, anschließend blieb die Oberfläche jedoch dauerhaft im Ladebildschirm hängen.

Ein Blick in die Browser-Konsole brachte den entscheidenden Hinweis. Die WebSocket-Verbindungen zu folgenden Endpunkten schlugen fehl:

/api/ws/system
/api/ws/webrtc/local

Insbesondere die Verbindung zu /api/ws/system ist für den Aufbau der UniFi-Oberfläche relevant. Funktioniert dieser WebSocket nicht, kann die Oberfläche beim Laden hängen bleiben.

Ein direkter Zugriff auf den Cloud Key funktionierte dagegen. Damit war klar: Das Problem trat beim Zugriff über den Reverse Proxy auf.

Getestet mit Caddy 2.11.6

Die beschriebenen Ergebnisse beziehen sich auf meine konkrete Installation. Die vermutete Ursache ist nicht isoliert nachgewiesen.

AUSGANGSKONFIGURATION

Die Verbindung im Überblick

Die Verbindung verlief über folgende Kette: Browser → Caddy → UniFi Protect auf dem Cloud Key

Caddy stellte die Verbindung zum Backend über HTTPS her. Da der Cloud Key ein selbstsigniertes Zertifikat verwendete, war die Zertifikatsprüfung für den Upstream deaktiviert.

Das folgende Beispiel verwendet nvr.home.example als Hostnamen und 192.0.2.10 als beispielhafte IP-Adresse des Cloud Keys. Die ursprüngliche Konfiguration sah so aus:

Caddyfile

@nvr host nvr.home.example

handle @nvr {
    reverse_proxy https://192.0.2.10 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

Auf den ersten Blick ist das ein übliches Muster für einen HTTPS-Upstream mit selbstsigniertem Zertifikat. Trotzdem funktionierte der Zugriff über Caddy nicht.

FEHLERSUCHE

Was ich ausschließen konnte

Mein erster Verdacht war die Firewall. Wenn eine Weboberfläche nicht vollständig lädt, liegt der Gedanke an eine blockierte Verbindung schließlich nahe. Die weiteren Tests sprachen allerdings gegen diese Erklärung.

Der Cloud Key war erreichbar

Ein curl-Aufruf von Caddy zum Cloud Key funktionierte. Die grundlegende Netzwerkverbindung zwischen Reverse Proxy und Backend war also vorhanden.

Die WebSockets scheiterten sofort

Die fehlgeschlagenen WebSocket-Anfragen endeten nach ungefähr 10 bis 20 Millisekunden. Das passte nicht zu einer typischen Firewall-Blockade, bei der eine Verbindung häufig in einen Timeout läuft. Ein schneller Fehler ist zwar kein endgültiger Beweis gegen die Firewall, machte diese Erklärung aber deutlich unwahrscheinlicher.

Das Access-Log zeigte HTTP 500

Im Caddy-Access-Log war für die betroffenen Anfragen der Status 500 Internal Server Error zu sehen. Die Antwort enthielt außerdem Server: nginx und einen JSON-Response-Body.

Das deutete darauf hin, dass die Fehlerantwort vom Backend stammte und von Caddy weitergereicht wurde. Der Server-Header allein ist allerdings kein absoluter Beweis für den Ursprung einer Antwort. Zusammen mit den übrigen Messungen war er ein weiterer Hinweis auf ein Problem innerhalb der UniFi-Anwendung beziehungsweise ihrer HTTP-Verarbeitung.

Direkt gegen Protect funktionierte der WebSocket

Der wichtigste Vergleich war der direkte Test gegen den Cloud Key. Mit einem gültigen Cookie erhielt ich bei einem WebSocket-Handshake den erwarteten Status HTTP/1.1 101 Switching Protocols.

Das funktionierte auch dann, wenn ich beim direkten Zugriff den Hostnamen nvr.home.example, den passenden Origin und die entsprechenden Browser-Header verwendete. Der WebSocket-Handshake funktionierte also grundsätzlich.

Andere Headeränderungen halfen nicht

Ich testete außerdem Änderungen an den X-Forwarded-*-Headern sowie die erzwungene Verwendung von HTTP/1.1. Keine dieser Änderungen allein beseitigte den Fehler.

Damit blieb eine andere mögliche Ursache im Fokus: der Host-Header, den Caddy an den HTTPS-Upstream weitergab.

VERMUTETE URSACHE

Der Host-Header passt nicht zum Origin

Mit Caddy 2.11 hat sich das Verhalten beim Reverse Proxy zu HTTPS-Upstreams geändert. Caddy passt den Host-Header standardmäßig an den Upstream an, damit er zum Ziel der HTTPS-Verbindung passt.

Diese Änderung ist dokumentiert und hat bereits bei anderen Reverse-Proxy-Konfigurationen zu Problemen geführt. In der Caddy-Community wird deshalb unter anderem empfohlen, den ursprünglichen Hostnamen ausdrücklich weiterzugeben. Für meine Konfiguration ergibt sich daraus folgende mögliche Situation:

Header	Erwarteter Wert
`Host`	`192.0.2.10`
`Origin`	`https://nvr.home.example`

Der Browser greift über den öffentlichen Hostnamen zu. Wenn Caddy beim Weiterleiten den Host-Header auf die Backend-IP setzt, während der Origin weiterhin den ursprünglichen Hostnamen enthält, stimmen beide Angaben nicht mehr überein.

Meine Vermutung: UniFi prüft beim WebSocket-Handshake die Kombination aus Host und Origin. Ein Widerspruch könnte dazu führen, dass das Backend den Handshake mit HTTP 500 ablehnt. Diese Erklärung passt zu meinen Messungen: Beim direkten Zugriff mit passendem Host und Origin erhielt ich HTTP 101. Über Caddy schlug der Handshake dagegen fehl.

Wichtige Einschränkung

Ich habe die konkrete Kombination Host = IP-Adresse und Origin = Domainname nicht noch einmal isoliert nachgestellt. Die Ursache ist deshalb plausibel und durch die anschließende Lösung gestützt, aber nicht abschließend bewiesen.

Ein weiterer Stolperstein: HTTP/2 zum Backend

Caddy verwendet bei TLS-Upstreams seit Version 2.10 standardmäßig auch HTTP/2. UniFi unterstützt jedoch nicht in jeder betroffenen Konstellation WebSockets über HTTP/2. Die Caddy-Community dokumentiert deshalb einen weiteren Lösungsansatz: HTTP/1.1 für die Verbindung zum Backend ausdrücklich festlegen.

In meinem Test beseitigte die Änderung am Host-Header das Problem. Ob versions 1.1 in meiner konkreten Installation zusätzlich erforderlich ist, habe ich nicht einzeln getestet.

LÖSUNG

Host-Header ausdrücklich setzen

Die entscheidende Änderung bestand darin, den ursprünglichen Hostnamen explizit an das Backend weiterzugeben. Meine funktionierende Konfiguration lautet:

Caddyfile

@nvr host nvr.home.example

handle @nvr {
    reverse_proxy https://192.0.2.10 {
        header_up Host {host}

        transport http {
            tls_insecure_skip_verify
            versions 1.1
        }
    }
}

Die entscheidende Zeile ist header_up Host {host}. Damit verwendet Caddy beim Weiterleiten den Hostnamen aus der ursprünglichen Client-Anfrage, anstatt den Host-Header an die Backend-Adresse anzupassen. Die Zeile versions 1.1 erzwingt HTTP/1.1 für die Verbindung zum Backend.

Als Gesamtpaket verstehen

In meinem Test funktionierte die Oberfläche nach dieser Änderung wieder. Welche der einzelnen Zeilen dabei wie stark mitgewirkt hat, habe ich nicht aufgeschlüsselt. Die Konfiguration ist deshalb als funktionierendes Ganzes zu lesen, nicht als Beleg für die alleinige Wirkung jeder einzelnen Zeile.

WENN ES NICHT REICHT

Was tun, wenn es weiterhin nicht funktioniert?

Je nach UniFi-Version, Gateway und Reverse-Proxy-Konfiguration können weitere Anpassungen erforderlich sein. In Community-Beiträgen werden unter anderem diese Varianten diskutiert.

🔧

Host mit Port

Caddyfile

header_up Host {hostport}

{hostport} berücksichtigt zusätzlich einen gegebenenfalls vorhandenen Port.

🔃

Host des Upstreams

Caddyfile

header_up Host {upstream_hostport}

{upstream_hostport} bezieht sich auf den Upstream, {host} dagegen auf den Hostnamen der ursprünglichen Anfrage.

⚠

Origin entfernen

Caddyfile

header_up Origin ""

Das sollte nicht die erste Maßnahme sein. Der Origin-Header dient der Herkunftsprüfung. Ihn zu entfernen, kann Sicherheitsprüfungen verändern und sollte nur nach gezielter Prüfung der konkreten Installation erfolgen.

Welche Variante funktioniert, hängt davon ab, welche Werte UniFi erwartet. Deshalb sollte man diese Einstellungen nicht blind austauschen, sondern gezielt testen. Die Community-Erfahrungen zeigen außerdem, dass eine wieder ladende Oberfläche nicht zwangsläufig bedeutet, dass alle Funktionen – etwa Live-Kamerabilder – anschließend funktionieren.

EIGENE FEHLERSUCHE

Tipps für die eigene Fehlersuche

Wer ein ähnliches Problem untersucht, sollte die Fehlerquelle möglichst systematisch eingrenzen.

Caddy-Access-Log aktivieren

Mit dem log-Block im Site-Abschnitt lassen sich Status und Dauer der Anfragen nachvollziehen. Besonders hilfreich ist es, die fehlgeschlagenen WebSocket-Anfragen separat zu betrachten.

Bei Bedarf Debug-Logging einschalten

Caddys globaler debug-Schalter kann bei der Fehlersuche helfen. Dabei können sensible Header sichtbar werden.

WebSocket-Handshake gezielt testen

Ein WebSocket-Handshake lässt sich beispielsweise mit curl und den entsprechenden Upgrade-Headern nachstellen. Ein erfolgreicher Handshake sollte mit HTTP 101 antworten.

Bash

curl -sk -i --http1.1 \
  https://192.0.2.10/api/ws/system \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Host: nvr.home.example" \
  -H "Origin: https://nvr.home.example" \
  -H "Cookie: TOKEN="

Das Beispiel verwendet bewusst Platzhalter für Hostname, IP-Adresse und Token. Der Test muss mit einem gültigen Authentifizierungstoken und den zur Installation passenden Headern durchgeführt werden. Ein einfacher curl-Aufruf ohne diese Angaben ist kein aussagekräftiger WebSocket-Test.

Host und Origin einzeln variieren

Für eine belastbare Ursachenanalyse sollten Host, Origin und die verwendete HTTP-Version einzeln verändert werden. So lässt sich feststellen, welche Änderung tatsächlich für den Erfolg verantwortlich ist.

Zugangsdaten niemals veröffentlichen

Der Cookie-Wert TOKEN=... kann einen gültigen Login repräsentieren. Wer Logs oder Befehle in Foren veröffentlicht, muss solche Werte vollständig entfernen. Falls ein echter Sitzungstoken versehentlich veröffentlicht wurde, sollte die Sitzung beendet beziehungsweise der Token ungültig gemacht werden.

Vorsicht beim Teilen von Logs

Cookies, Sitzungstokens und andere Zugangsdaten müssen vor dem Teilen von Logs unbedingt entfernt werden.

FAZIT

Nicht zwangsläufig die Firewall

Wenn UniFi OS oder Protect hinter Caddy im Ladebildschirm hängen bleibt, muss nicht zwangsläufig die Firewall die Ursache sein.

In meinem Test funktionierte der direkte Zugriff auf den Cloud Key, während die WebSocket-Verbindungen über Caddy mit HTTP 500 scheiterten. Die explizite Weitergabe des ursprünglichen Hostnamens mit header_up Host {host} brachte die Oberfläche wieder zum Laufen.

Die Messungen sprechen dafür, dass das Verhalten des Host-Headers bei HTTPS-Upstreams in Verbindung mit der WebSocket-Verarbeitung von UniFi eine Rolle spielte. Da ich die vermutete Host-/Origin-Abweichung nicht separat reproduziert habe, bleibt die genaue Ursache allerdings offen.

Mein Tipp: Bei ähnlichen Problemen zuerst die WebSocket-Anfragen im Browser und im Caddy-Access-Log untersuchen. Anschließend den Host-Header und die HTTP-Version zum Backend gezielt testen, bevor Firewall-Regeln oder andere Netzwerkkomponenten verändert werden.

QUELLEN

Quellen und Links

Netzwerk, Reverse Proxy oder Hosting-Umgebung planen?

RDDZ unterstützt bei Planung, Umsetzung und Fehlersuche in Netzwerken und Hosting-Umgebungen – von der Konzeption bis zum laufenden Betrieb.

Der Beitrag UniFi OS und Protect hinter Caddy: Wenn die Oberfläche im Ladebalken hängen bleibt erschien zuerst auf RDDZ.

UniFi Network 11: Alle Neuerungen und wichtige Upgrade-Hinweise

dennis_rddz — Tue, 13 Oct 2026 16:04:38 +0000

RDDZ NEWS · UBIQUITI · NETZWERK

UniFi Network 11: Alle Neuerungen und wichtige Upgrade-Hinweise

Mit UniFi Network Application 11.0.83 veröffentlicht Ubiquiti einen umfangreichen Versionssprung: neue Oberfläche, aber auch eine veränderte technische Grundlage. PostgreSQL-Datenbank, Live Flows, externe Network Lists, WLAN als Backup-Internetzugang und Matter-Thread-Monitoring gehören zu den größten Neuerungen – dazu kommen wichtige Einschränkungen, die vor einem Upgrade bekannt sein sollten.

UNIFI NETWORK 11 · EINGEORDNET VON RDDZ

● Release Candidate – noch keine stabile Version

PostgreSQL

Neue Datenbank-Grundlage

Live Flows

Verbindungen live kontrollieren

Zone-Based FW

Automatische Migration aller Sites

Statistik-HistorieGeht beim Update verloren

USG-GatewaysNicht mehr unterstützt

FirewallAutomatische Umstellung

Stand: Release Candidate 11.0.83, Oktober 2026.

✓ Neue Datenbank-Grundlage mit PostgreSQL und skalierbarer Statistik-Engine

✓ Live Flows: aktive Verbindungen direkt am Gateway anzeigen und beenden

✓ Externe Network Lists und WLAN als Backup für den Internetzugang

✓ Matter-Thread-Monitoring für Smart-Home-Geräte im Netzwerk

✓ USG-Support und klassischer Network Application Server entfallen

TECHNISCHE GRUNDLAGE

PostgreSQL und neue Statistik-Engine: der Unterbau wird ausgetauscht

Eine der größten Änderungen betrifft nicht eine sichtbare Funktion, sondern die interne Architektur von UniFi Network.

🗃

Datenbank wird auf PostgreSQL umgestellt

Die bisherige Anwendungsdatenbank wird durch PostgreSQL abgelöst – eine deutlich belastbarere Grundlage für größere Installationen.

📊

Skalierbarere Statistik-Engine

Ubiquiti führt parallel eine neue Engine für die Verarbeitung von Statistiken ein, inklusive Fehlerkorrekturen bei Installationen mit vielen Sites.

⚙

Mehr Stabilität im Hintergrund

Der neue Unterbau soll die Anwendung insgesamt stabiler machen – gerade bei Umgebungen mit vielen verwalteten Standorten.

⚠

Wichtig: Statistik-Historie geht verloren

Beim Update wird die vorhandene Statistik-Historie gelöscht, die Anwendung beginnt danach mit dem Aufbau neuer Daten. Wer langfristige Auswertungen oder historische Netzwerkdaten für Vergleiche braucht, sollte diesen Verlust vor der Migration einplanen.

Unsere Einordnung

Ein Datenbankwechsel dieser Größenordnung ist kein kosmetisches Update. Wer auf historische Statistiken angewiesen ist, sollte vorab einen eigenen Export oder Screenshot der relevanten Zeiträume anlegen.

NEUE FUNKTIONEN

Mehr Kontrolle im Netzwerkalltag

Neben dem technischen Unterbau bringt Version 11 auch eine Reihe praktischer Funktionen für den laufenden Betrieb mit.

📡

Live Flows

Aktive Verbindungen lassen sich direkt am Gateway anzeigen und bei Bedarf gezielt beenden – praktisch bei der Fehlersuche. Voraussetzung: UniFi OS 6.0.10 oder neuer.

🔍

Externe Network Lists

Domain- und IP-Listen lassen sich aus externen Quellen importieren, statt sie nur manuell zu pflegen. Ebenfalls ab UniFi OS 6.0.10.

📶

WiFi Uplink als Backup

Unterstützte Gateways mit eigenem WLAN-Radio können sich mit einem WLAN in der Umgebung verbinden und dieses als Ausweichmöglichkeit nutzen, falls der reguläre Internetzugang ausfällt. Unterstützt werden Dream Router 7 (UDR7), Dream Router 5G Max (UDR-5G-Max), UniFi Express 7 (UX7) und Cloud Gateway Industrial (UCG-Industrial) – jeweils mit UniFi OS 6.0.10 oder neuer.

SMART HOME & CLIENTS

Matter-Thread-Monitoring und mehr Kontrolle bei Clients

Dort, wo Netzwerkverwaltung und Smart-Home-Infrastruktur zusammenkommen, erweitert UniFi Network 11 die Sichtbarkeit deutlich.

Matter-Thread-Geräte lassen sich hinsichtlich Status und Verbindung überwachen – vorausgesetzt, das UniFi OS Gateway läuft mit Version 6.0.10 oder neuer, mDNS ist aktiviert und IPv6 ist in dem Netzwerk eingeschaltet, in dem sich die Thread Border Router befinden. Da IPv6 in UniFi standardmäßig deaktiviert ist, lohnt sich gerade bei IoT-Netzen ein Blick in die Einstellungen.

UniFi beobachtet die Geräte dabei nur – eine Steuerung findet nicht statt. Parallel wird die Client-Verwaltung ausgebaut: Icons für Client-Geräte lassen sich jetzt generieren, mehrere Clients gleichzeitig bearbeiten, entfernen oder blockieren, und ein neuer Alarm informiert über Verbindungsänderungen.

Wichtig: Die Release Notes sprechen ausdrücklich vom Generieren von Client-Icons – nicht vom Hochladen eigener Bilder als Gerätebild. Beide Funktionen sollten nicht verwechselt werden.

ANALYSE & ROUTING

Topology, SD-WAN und Traffic Flows im Detail

Auch bei Netzwerkübersicht und Routing-Entscheidungen hat sich mit Version 11 einiges verändert.

🌐

Topology und Time Machine

Time Machine wurde in die Topology-Seite integriert, die Animationen des Netzwerkverkehrs verbessert und das Laden bei großen Sites optimiert. Der zuletzt genutzte Zustand (geöffnet/geschlossen) wird sich nun gemerkt.

🛡

SD-WAN: ziel- und leistungsbasiert

Neue Richtlinien ermöglichen Routing nach Hub-Auswahl, WAN-Priorität sowie Schwellenwerten für Paketverlust, Latenz und Jitter. Voraussetzung ist Site Manager 5.10.2 oder neuer.

🌎

IPIP-WAN für Japan

Zusätzlich ergänzt Ubiquiti IPIP-WAN-Unterstützung für japanische IPv4-over-IPv6-Dienste – ein eher regionales, aber nicht unerhebliches Detail.

Traffic Flows und Firewall: mehr Kontext

Erlaubte Verbindungen zeigen jetzt den Namen der zugehörigen Firewall-Policy, eine neue Anwendungsspalte samt Filter erleichtert die Zuordnung, Flows lassen sich direkt in Firewall Policies protokollieren und lokale DNS-Anfragen werden korrekt als DNS erkannt. Die neuen Firewall-Policy-Namen und der Anwendungsfilter setzen UniFi OS 6.0.10 oder neuer voraus.

IM DETAIL

Weitere Verbesserungen im Überblick

Netzwerk, WLAN & Switching

Verbessertes Channel AI inkl. Länderauswahl, korrigierte Kanalempfehlungen für Outdoor-APs, stabilere Switch-Stacks, bessere Validierung des IGMP-Snooping, höhere VLAN-Grenze ohne adoptiertes Gateway sowie System-Logs für Subnet-Overlaps.

VPN, Routing & Firewall

Überarbeitete Bedienung bei VPN- und Routing-Einstellungen, neue Verschlüsselungsoptionen AES-192-CBC und AES-128-CBC für Site-to-Site-OpenVPN, behobene Fehler bei SD-WAN-Hub-Spoke-Tunneln nach WAN-Änderungen sowie bei der Isolation von Netzwerken gegenüber der VPN-Zone.

VOR DEM UPDATE

Was vor dem Upgrade zu beachten ist

UniFi Network 11.0.83 ist ein Release Candidate und benötigt mindestens UniFi OS 6.0. Diese Schritte sollten vorher geprüft werden:

Backup erstellen

Konfiguration sichern und prüfen, wie eine Wiederherstellung im Fehlerfall abläuft.

Hardware kontrollieren

Prüfen, ob noch USG-Gateways oder ein klassischer Network Application Server im Einsatz sind.

Statistikverlust einplanen

Wichtige historische Auswertungen vorher sichern – die Statistik-Historie wird beim Update gelöscht.

Firewall-Konfiguration prüfen

Alle Sites werden automatisch auf die Zone-Based Firewall migriert. Besonders bei Kombinationen mit Fremd-Routern oder individuellen LAN-In/LAN-Local-Regeln lohnt ein genauer Blick danach.

Voraussetzungen prüfen

UniFi OS und, für die neuen SD-WAN-Richtlinien, Site Manager müssen die geforderten Mindestversionen erfüllen.

Release-Status beachten

11.0.83 ist ein Release Candidate, kein stabiles Release. In produktiven Umgebungen sollte man damit entsprechend vorsichtig umgehen.

Genug Zeit einplanen

Das Upgrade selbst kann laut Ubiquiti bis zu 20 Minuten dauern, einzelne Geräte können danach noch etwas länger für die Neuprovisionierung brauchen.

FAZIT

UniFi Network 11 ist ein größerer Umbau

UniFi Network 11 ist deutlich mehr als ein gewöhnliches Funktionsupdate. Die Migration auf PostgreSQL, die neue Statistik-Engine, Live Flows, externe Network Lists und WiFi Uplink erweitern die Plattform technisch wie funktional. Auch SD-WAN, die Analyse von Traffic Flows, die Topology-Ansicht und die Verwaltung von Clients werden weiterentwickelt.

Gleichzeitig bringt die Version wichtige Einschränkungen mit: Die Statistik-Historie geht verloren, USG-Gateways werden nicht mehr unterstützt und selbst gehostete Installationen sollen auf UniFi OS Server umgestellt werden. Die automatische Migration auf die Zone-Based Firewall verdient dabei besondere Aufmerksamkeit.

Unsere Empfehlung: Hardware, bestehende Firewall-Regeln und benötigte Statistiken vor dem Upgrade prüfen. Da 11.0.83 aktuell als Release Candidate geführt wird, sollte die Version in produktiven Umgebungen nicht unüberlegt installiert werden.

FAQ

Häufige Fragen zu UniFi Network 11

Ist UniFi Network 11.0.83 schon stabil?

Nein. Ubiquiti führt die Version aktuell als Release Candidate, also als Vorabversion. Das Update wird schrittweise verteilt und ist deshalb möglicherweise nicht bei jeder Installation sofort verfügbar. Für produktive Umgebungen empfiehlt sich ein vorsichtiger Umgang.

Was passiert mit meinen bisherigen Statistiken?

Die vorhandene Statistik-Historie wird beim Update gelöscht, da die Datenbank auf PostgreSQL migriert und die Statistik-Engine ausgetauscht wird. Danach beginnt die Anwendung mit dem Aufbau neuer Daten.

Kann ich mit einer USG-Gateway auf Version 11 updaten?

Nein. Die Unterstützung für USG-Gateways wurde entfernt. Laut Ubiquiti ist Network 10.6 die letzte Version, die USG unterstützt – wer noch USG-Hardware betreibt, sollte vor einem Update die weitere Planung klären.

Welche Gateways unterstützen WiFi Uplink?

Aktuell Dream Router 7 (UDR7), Dream Router 5G Max (UDR-5G-Max), UniFi Express 7 (UX7) und Cloud Gateway Industrial (UCG-Industrial) – jeweils mit UniFi OS 6.0.10 oder neuer. Gateways ohne eigenes WLAN-Radio unterstützen die Funktion nicht.

Was ändert sich bei selbst gehosteten Installationen?

Der bisherige Network Application Server wird nicht mehr unterstützt. Ubiquiti empfiehlt für Self-Hosting den Wechsel auf UniFi OS Server, für alle anderen Installationen weiterhin ein UniFi Cloud Gateway.

QUELLEN

Quellen und Links

UniFi-Netzwerk sicher auf Version 11 bringen?

Ob Bestandsaufnahme der Hardware, Prüfung der Firewall-Konfiguration oder begleitetes Update: RDDZ unterstützt dich dabei, UniFi Network 11 kontrolliert einzuführen – statt Überraschungen im produktiven Betrieb zu riskieren.

Der Beitrag UniFi Network 11: Alle Neuerungen und wichtige Upgrade-Hinweise erschien zuerst auf RDDZ.

WG Tunnel 5.8.0 released: Multihop, Tunnel-Gruppen und wichtige Fixes

dennis_rddz — Mon, 12 Oct 2026 06:15:10 +0000

WG Tunnel · Release · 11.10.2026

WG Tunnel 5.8.0 released: Multihop, Tunnel-Gruppen und wichtige Fixes

Erst vor wenigen Wochen ging es bei WG Tunnel 5.7.3 vor allem um Fehlerbehebungen beim Auto-Tunnel und DNS. Jetzt legt der Android-Client nach: Am 11. Oktober 2026 ist WG Tunnel 5.8.0 erschienen – diesmal mit zwei neuen Funktionen für Nutzer mit mehreren VPN-Verbindungen.

WG TUNNEL 5.8.0 · RELEASE

● Seit 11.10.2026 verfügbar

Multihop

Mehrere VPN-Verbindungen verketten

Tunnel-Gruppen

Übersichtliche Verwaltung mehrerer Tunnel

IPv6 & DNS

Weitere Fehlerbehebungen

5.7.3 (18.09.2026)Auto-Tunnel & DNS Fixes

5.8.0 (11.10.2026)Multihop & Tunnel-Gruppen

5.7.3 (18.09.2026) war vor allem Bugfixes für Auto-Tunnel und DNS.

✓ Multihop-Tunnel: VPN-Verbindungen hintereinander schalten

✓ Neue Tunnel-Gruppen zur übersichtlichen Verwaltung

✓ Fehlerbehebungen bei IPv6-Proxy und DNS-/Proxy-Betrieb

✓ Weitere Korrekturen am Auto-Tunnel (Gerätehersteller, Standortberechtigungen, Android Auto)

✓ Freier Android-Client für WireGuard und AmneziaWG

WAS IST NEU

Was steckt in WG Tunnel 5.8.0?

Mehrere VPN-Verbindungen miteinander verbinden: Die größte Neuerung ist die Unterstützung für Multihop-Tunnel. Damit lassen sich VPN-Verbindungen hintereinander schalten, der Datenverkehr läuft also über mehrere Tunnel statt nur über eine einzelne Verbindung. Das kann interessant sein, wenn man bewusst mehrere VPN-Stationen nutzen möchte. Der praktische Nutzen hängt dabei von der jeweiligen Konfiguration ab, mehrere Tunnel bedeuten nicht automatisch mehr Sicherheit oder bessere Geschwindigkeit.

Tunnel-Gruppen: Neu sind außerdem Tunnel-Gruppen. Damit lassen sich Tunnel übersichtlicher zusammenfassen und verwalten. Wer mehrere Konfigurationen für unterschiedliche Standorte oder Einsatzzwecke nutzt, bekommt damit eine bessere Ordnung in seine Verbindungsliste.

Verbesserungen bei IPv6 und DNS: Auch unter der Haube wurde gearbeitet. Die Entwickler nennen mehrere Fehlerbehebungen rund um den lokalen IPv6-Proxy sowie den DNS- und Proxy-Betrieb, dazu gehören Korrekturen an der IPv6-Bind-Adresse und am zugrunde liegenden Kern der App.

Der Auto-Tunnel wird weiter verbessert: Betroffen sind unter anderem die Netzwerkerkennung bei bestimmten Geräteherstellern, die Behandlung fehlender Standortberechtigungen und Probleme mit Android Auto. Gerade bei Android-Geräten können solche Sonderfälle im Alltag entscheidend sein: Der VPN-Tunnel soll zuverlässig auf Änderungen der Netzwerkverbindung reagieren, ohne dass man ständig selbst eingreifen muss.

Überarbeitete Einstellungen: Die Bedienung der Split-Tunnel- und DNS-Einstellungen wurde ebenfalls verbessert, dazu kommen weitere kleinere Änderungen und Fehlerkorrekturen.

EMPFEHLUNG

Soll man updaten?

Das Update ist besonders interessant, wenn Sie mehrere Tunnel verwalten oder Multihop nutzen möchten. Auch wer in den vorherigen Versionen Probleme mit dem Auto-Tunnel, IPv6 oder DNS hatte, sollte sich die neue Version ansehen. Wer WG Tunnel einfach nur mit einer einzelnen VPN-Verbindung nutzt und bisher keine Probleme hatte, bekommt ebenfalls Verbesserungen, die beiden neuen Funktionen sind für diesen Einsatz aber nicht zwingend erforderlich.

DOWNLOAD

Wo gibt es die Version?

📦

GitHub

Die APK direkt vom Entwickler. Release 5.8.0 ist dort als „Latest“ markiert: Release 5.8.0.

📱

IzzyOnDroid

Der F-Droid-kompatible Store zieht neue Releases in der Regel zeitnah nach. Ein Client wie Neo Store oder Droid-ify hält die App aktuell: WG Tunnel bei IzzyOnDroid.

▶

Google Play

Ob die neue Version dort schon angekommen ist, haben wir nicht geprüft: WG Tunnel bei Google Play.

APK-Signatur prüfen

Wer die APK direkt von GitHub lädt, sollte darauf achten, sie aus dem offiziellen Projekt zu beziehen. Laut Release Notes lautet der SHA-256-Fingerprint des Signaturzertifikats für Version 5.8.0:

5204d82e766e8aa14dcbb06dc70aebae2bdd812d4d6203cd521a8a685d7d3d80

So lässt er sich prüfen (den Pfad zur APK anpassen):

apksigner verify --print-certs [Pfad zur APK] | grep SHA-256

MEHR

Mehr zu WG Tunnel

WG Tunnel ist ein freier Android-Client für WireGuard und AmneziaWG. Neben dem Auto-Tunnel gibt es einen Lockdown-Modus als eigenen Kill-Switch und einen lokalen Proxy (SOCKS5/HTTP).

Was es bei der Vorgängerversion zu beachten gab, steht in diesem Beitrag: WG Tunnel 5.7.3: Feinschliff für Auto-Tunnel und DNS.

QUELLEN

Quellen und Links

VPN und Fernzugriff sauber aufsetzen?

Ob WireGuard, Firewall oder Fernzugriff: Nutzen Sie unsere IT-Leistungen.

Der Beitrag WG Tunnel 5.8.0 released: Multihop, Tunnel-Gruppen und wichtige Fixes erschien zuerst auf RDDZ.

Von pfSense zu OPNsense: was bei der Migration wirklich zu beachten ist

dennis_rddz — Wed, 23 Sep 2026 04:10:00 +0000

Netzwerk · Firewall · Migration

Von pfSense zu OPNsense: was bei der Migration wirklich zu beachten ist

Es gibt keinen offiziell unterstützten 1:1-Import einer aktuellen pfSense-Konfiguration nach OPNsense. Eine Migration ist möglich, aber wir würden sie als Neuaufbau mit kontrollierter Übernahme der bestehenden Konfiguration planen, nicht als simples Backup einspielen. Stand: aktuelle OPNsense-Version 26.7.4.

PFSENSE → OPNSENSE

● OPNsense 26.7.4

Import

nicht offiziell

Legacy-Code

< 10 %

Weg

Neuaufbau

config.xml importieren ✓ kein Migrationsweg

Parallel aufbauen ✓ empfohlen

Aliase ✓ JSON-Import

VPN & PKI ✓ meister Aufwand

Dokumentieren → Aufbauen → Testen → Cutover

✓ Kein offizieller 1:1-Import

✓ Fork seit 2014

✓ < 10 % Legacy-Code laut OPNsense

✓ Aktuell: OPNsense 26.7.4

✓ Migration statt Restore

AUSGANGSLAGE

Warum gibt es keinen einfachen Import?

pfSense und OPNsense haben denselben historischen Ursprung und sind beide auf FreeBSD aufgebaut. Auf den ersten Blick sieht eine Migration deshalb einfacher aus, als sie tatsächlich ist.

◐

Seit 2014 getrennte Wege

Die Projekte sind seit dem Fork technisch immer weiter auseinandergelaufen. OPNsense selbst beschreibt, dass inzwischen weniger als 10 % des ursprünglichen Legacy-Codes verblieben sind.

▤

Konfiguration umgebaut

Auch die Konfiguration wurde über die Jahre verändert und teilweise auf neue interne Modelle und APIs umgestellt. Ältere Anleitungen im Netz sind deshalb mit Vorsicht zu genießen.

✎

Formate nicht kompatibel

Im OPNsense-Forum wird ausdrücklich darauf hingewiesen, dass die Konfigurationsformate beider Projekte inzwischen nicht mehr direkt kompatibel sind. Ein früherer pfSense-Importer wurde entfernt.

Unser Ansatz: Die pfSense-Konfiguration ist eine wichtige Vorlage, aber kein fertiges OPNsense-Backup.

INVENTAR

Was lässt sich übernehmen?

Sehr viel von dem, was man für die Migration braucht, ist weiterhin vorhanden, muss aber teilweise manuell neu aufgebaut werden. Die pfSense-Konfiguration sollte deshalb vor allem als Inventar und technische Dokumentation dienen.

WAN- und LAN-Konfiguration, VLANs
DHCP-Netze und Reservierungen
Firewall-Regeln, NAT und Portweiterleitungen, Aliase
statische Routen, DNS-Konfiguration
VPN-Konfigurationen und Zertifikate
Benutzer und Gruppen, Captive Portal, Traffic Shaping, Dynamic DNS
weitere installierte Pakete und deren Einstellungen

Die XML als Vorlage, nicht als Backup

pfSense speichert die Konfiguration als XML mit eigenen Backup- und Restore-Funktionen. Konfigurationen sind dabei an die jeweilige Konfigurationsrevision gebunden, es gibt also selbst innerhalb von pfSense Unterschiede zwischen älteren und neueren Ständen. Die XML eignet sich hervorragend, um schnell herauszufinden, welche VLANs, Aliase, DHCP-Reservierungen, Portweiterleitungen, VPN-Netze, Zertifikate und CAs vorhanden sind, notfalls automatisiert ausgewertet. Wofür sie sich nicht eignet: pfSense-config.xml → OPNsense → „wird schon passen“. Dafür sind die Systeme zu weit auseinander.

VORGEHEN

Der saubere Weg: parallel aufbauen

Wenn die Firewall produktiv eingesetzt wird, bauen wir die neue OPNsense-Installation parallel zur bestehenden pfSense-Firewall auf, auf zweiter Hardware oder zunächst als VM. Die alte Firewall bleibt so bis zum Umschalttermin vollständig funktionsfähig.

pfSense dokumentieren

Vollständiges Backup erstellen, dann eine echte Bestandsaufnahme: WAN-IPs, LAN-Netze, VLANs, Gateways, DNS, DHCP, Firewall-Regeln, NAT, Portweiterleitungen, Aliase, statische Routen, VPNs, Zertifikate, Benutzer, Dynamic DNS, Zusatzpakete, Monitoring, externe Dienste. Bei größeren Installationen lohnt sich zusätzlich ein Netzwerkdiagramm.

OPNsense separat installieren

Aktuell befindet sich OPNsense in der 26.7er-Reihe (seit 15. Juli 2026), zuletzt aktualisiert mit 26.7.4 am 15. September 2026. Nicht nach einer Anleitung für OPNsense 22.x oder 23.x migrieren und diese blind übertragen: Gerade bei VPN, Aliasen und Interface-Konfiguration hat sich seither einiges verändert.

Interfaces und VLANs zuerst

Physische Interfaces, WAN, LAN, VLANs, Gateways, IP-Adressen, Routing. Erst wenn diese Grundlage steht, übertragen wir Firewall-Regeln und NAT. Bei VLANs nicht nur auf sichtbare Namen achten: Interface-Zuordnung und interne Bezeichnungen können sich auf Regeln auswirken, im OPNsense-Forum werden entsprechende Probleme berichtet.

REGELN & DIENSTE

Firewall, NAT und DNS: neu anlegen statt kopieren

Die Logik einer Regel bleibt gleich (WAN → Webserver → TCP 443 → NAT → interne IP), in OPNsense wird sie aber neu angelegt, nicht aus XML importiert.

✓

Firewall-Regeln aufräumen

Eine Migration ist eine gute Gelegenheit, alte Regeln zu hinterfragen: Wird sie noch gebraucht? Ist sie zu weit gefasst? Wird der Alias noch verwendet? Gerade bei gewachsenen Installationen findet man erstaunlich oft Regeln, deren Zweck niemand mehr kennt.

◐

Aliase sauber importieren

OPNsense hat die Alias-Verwaltung umgebaut und bietet einen eigenen Alias-Export und -Import auf JSON-Basis inklusive Validierung. Das ist deutlich sauberer, als alte -Blöcke aus einer pfSense-XML zu kopieren.

▤

NAT nicht vergessen

Neben Portforwards auch Outbound NAT, 1:1 NAT, NAT Reflection, automatische Regeln, Hairpin-Szenarien und IPv6 prüfen. OPNsense baut die Outbound-NAT-Konfiguration seit der 26.7-Reihe weiter zur Source-NAT-Konfiguration um, inklusive Migrationshilfe für den Übergang.

DHCP und DNS: unscheinbar, aber tückisch

Die eigentliche DHCP-Konfiguration ist meist einfach nachzubauen. Genauer hinschauen würden wir bei statischen DHCP-Zuweisungen, Hostnames, DNS-Registrierung, DHCP-Optionen, speziellen Boot-Optionen, PXE, DNS-Overrides und internen Hostnamen. Ein Migrationsprojekt kann technisch erfolgreich aussehen, während plötzlich ein Drucker, ein VoIP-Telefon oder ein Management-System nicht mehr funktioniert, weil eine DHCP-Option fehlt.

Auch OPNsense migriert intern

Seit Version 26.7.1 bietet OPNsense einen eigenen Migrationsassistenten, der ältere, „legacy“ angelegte Firewall-Regeln auf die neue MVC/API-Struktur überträgt. Das betrifft bestehende OPNsense-Installationen, nicht den Umstieg von pfSense, ist aber ein guter Grund, auch bei einer frischen OPNsense-Installation den CSV-Export der Regeln vor dem Löschen der alten Regeln zu prüfen.

DER GRÖSSTE AUFWAND

VPN ist wahrscheinlich der Punkt mit dem größten Aufwand

Bei VPNs würden wir besonders viel Zeit einplanen, vor allem wenn bestehende Clients nach der Migration weiter funktionieren sollen.

OpenVPN

Server/Client, Port, Protokoll, Tunnel-Netze, Cipher, TLS-Einstellungen, Routing, DNS-Push und Firewall-Regeln müssen stimmen. Besonders wichtig ist die PKI: Wer nicht einfach eine neue CA erzeugen will, muss CA, Zertifikate und Schlüssel sauber übernehmen oder kontrolliert neu ausstellen, sonst verbinden alte Clients nicht mehr.

IPsec

OPNsense hat die IPsec-Konfiguration über die Jahre auf die StrongSwan-basierte Struktur ausgerichtet, die ältere „Tunnel settings“ sind seit längerem auf dem Migrationspfad zu den moderneren „Connections“. Phase 1, Phase 2, IKE-Version, Verschlüsselung, PFS, IDs und Routing sollten auf beiden Seiten bewusst abgeglichen und nach der Umstellung in beide Richtungen getestet werden.

Zertifikate nicht vergessen

OpenVPN, WebGUI, Reverse Proxy, Captive Portal, IPsec und andere Dienste brauchen ihre Zertifikate, CAs und privaten Schlüssel auch auf OPNsense. Bei Let’s Encrypt ist eine kontrollierte Neuausstellung durch OPNsense selbst oft sauberer als die Übernahme der alten Zertifikate.

HA UND PAKETE

CARP/HA und zusätzliche Pakete

◐

CARP und HA

Wer pfSense als HA-Paar mit CARP/pfsync betreibt, sollte nicht versuchen, beide Systeme gleichzeitig umzubauen. Erst eine einzelne OPNsense-Instanz vollständig aufbauen und testen, dann die HA-Ebene: CARP-VIPs, pfsync, Interface-Zuordnung, Synchronisationsnetz, XMLRPC/API-Synchronisation. Dafür ein eigenes Migrationsfenster und einen expliziten Fallback einplanen.

▤

pfSense-Pakete

Ein installiertes pfSense-Paket wird nicht automatisch zu einem OPNsense-Paket. Bei zusätzlicher Software für IDS/IPS, Proxy, DNS, Monitoring, VPN, Dynamic DNS oder Reporting vorher prüfen, ob es ein Gegenstück unter OPNsense gibt und wie dessen Konfiguration aufgebaut ist.

✎

Community-Skripte

Es gibt Skripte, die versuchen, pfSense-Konfigurationen automatisiert zu übertragen. Auch im OPNsense-Forum wird darauf hingewiesen, dass dabei Einschränkungen bestehen und das Ergebnis anschließend manuell geprüft werden muss. Für eine produktive Firewall wäre uns „hat bei jemandem funktioniert“ als einzige Absicherung zu wenig.

CHECKLISTE

So planen wir eine produktive Migration

Bei einer kleinen Firewall ist das an einem Wartungsabend machbar. Bei vielen VLANs, mehreren VPNs, HA und Zusatzpaketen sollte daraus ein richtiges Migrationsprojekt werden.

Vorbereitung

Backup und Konfiguration exportieren, Pakete, VPNs, Zertifikate, VLANs, Firewall/NAT dokumentieren, Netzwerkdiagramm erstellen.

Aufbau

OPNsense installieren und aktualisieren, dann Interfaces, WAN/LAN, VLANs, Routing, DNS, DHCP, Firewall, NAT, VPN, Zertifikate und Zusatzpakete einrichten.

Test

Nicht nur „GUI geht“: Internet, DNS, IPv4/IPv6, VLANs, Inter-VLAN-Routing, Portweiterleitungen, VPN (Site-to-Site und Remote Access), DHCP, interne DNS-Auflösung, Monitoring, Logging, externe Dienste.

Cutover: Wartungsfenster starten, pfSense-Konfiguration ein letztes Mal sichern, aktuelle Änderungen übernehmen, Kabel/VIPs/Routing umschalten, OPNsense aktivieren, testen, Monitoring beobachten. Die pfSense-Firewall bleibt als Fallback stehen und wird nicht sofort gelöscht: Wenn nach dem Umschalten ein VPN oder VLAN Probleme macht, sollte der Rückweg nicht darin bestehen, pfSense schnell neu zu installieren.

FAZIT

Kein simples Software-Upgrade, aber gut planbar

Beide Systeme haben denselben historischen Ursprung und viele Gemeinsamkeiten, ihre Konfigurationsstrukturen haben sich aber über Jahre auseinanderentwickelt. Eine aktuelle pfSense-config.xml betrachten wir deshalb nicht als vollständiges OPNsense-Backup.

Was dagegen sehr gut funktioniert: pfSense dokumentieren → OPNsense parallel installieren → Grundkonfiguration aufbauen → Regeln, NAT, VLANs und Dienste übertragen → VPN/PKI prüfen → testen → umschalten.

Und noch ein Punkt, den wir persönlich wichtig finden: nicht versuchen, die bestehende pfSense 1:1 nachzubauen, nur weil es technisch möglich wäre. Eine Migration ist ein guter Zeitpunkt, alte Firewall-Regeln, ungenutzte Aliase, vergessene Portfreigaben und historische Sonderlösungen zu hinterfragen. Das reduziert nicht nur den Migrationsaufwand, sondern macht auch die künftige Administration übersichtlicher.

FAQ

Häufige Fragen zur Migration

Kann ich die pfSense-config.xml einfach in OPNsense importieren?

Nein. Es gibt keinen offiziell unterstützten 1:1-Import. OPNsense hatte früher einen pfSense-Importer, der wurde entfernt, weil die Konfigurationsformate zu weit auseinandergelaufen sind.

Wie viel vom pfSense-Code steckt eigentlich noch in OPNsense?

Laut OPNsense selbst sind es inzwischen weniger als 10 % des ursprünglichen Legacy-Codes. Die Projekte haben sich seit dem Fork 2014 stark auseinanderentwickelt.

Kann ich pfSense weiterlaufen lassen, während ich OPNsense aufbaue?

Ja, und genau das empfehlen wir. Die neue OPNsense-Installation parallel auf zweiter Hardware oder als VM aufbauen und testen, die alte Firewall bleibt bis zum Cutover und als Fallback danach in Betrieb.

Was ist bei VPN am aufwendigsten?

Die PKI. Sollen bestehende OpenVPN-Clients weiter funktionieren, müssen CA, Zertifikate und Schlüssel sauber übernommen oder kontrolliert neu ausgestellt werden, statt einfach eine neue CA zu erzeugen.

Werden pfSense-Pakete automatisch zu OPNsense-Paketen?

Nein. Für Zusatzsoftware wie IDS/IPS, Proxy, DNS oder Monitoring vorher prüfen, ob es ein Gegenstück unter OPNsense gibt und wie dessen Konfiguration aufgebaut ist.

Wie gehe ich mit einem CARP/HA-Paar um?

Erst eine einzelne OPNsense-Instanz vollständig aufbauen und testen, dann die HA-Ebene mit CARP-VIPs, pfsync und Synchronisationsnetz einrichten, mit eigenem Migrationsfenster und Fallback.

Lohnen sich Community-Skripte für die automatisierte Übertragung?

Sie können bei größeren Installationen einen Startpunkt liefern, ersetzen aber keine manuelle Prüfung. Für eine produktive Firewall reicht „hat bei jemandem funktioniert“ als Absicherung nicht aus.

QUELLEN

Quellen und Links

Firewall-Migration sauber planen?

Ob pfSense zu OPNsense, VLANs, VPN oder HA: Nutzen Sie unsere IT-Leistungen.

Der Beitrag Von pfSense zu OPNsense: was bei der Migration wirklich zu beachten ist erschien zuerst auf RDDZ.

WG Tunnel 5.7.3 released: Feinschliff für Auto-Tunnel und DNS

dennis_rddz — Mon, 21 Sep 2026 16:30:23 +0000

WG Tunnel · Release · 18.09.2026

WG Tunnel 5.7.3 released: Feinschliff für Auto-Tunnel und DNS

Nur zehn Tage nach 5.7.2 gibt es schon wieder ein Update: Am 18. September 2026 ist WG Tunnel 5.7.3 erschienen. Ein kleines Release, das sich aber lohnt, wenn man den Auto-Tunnel im Alltag nutzt.

WG TUNNEL 5.7.3

● Seit 18.09.2026

Auto-Tunnel

Fixes

DNS

DoH · DoT

Samsung

Netzerkennung

„Stopp ohne Netz“ ✓ kein Flackern

Captive Portals ✓ kein Flackern

Neustart-Schleife ✓ behoben

DoH/DoT-Timeouts ✓ behoben

5.7.2 (08.09.) → 5.7.3 (18.09.)

✓ Release: 18. September 2026

✓ Auto-Tunnel stabiler

✓ DNS-Timeouts behoben

✓ Samsung-Netzerkennung

✓ Als „Latest“ markiert

WAS IST NEU

Was steckt in WG Tunnel 5.7.3?

Der Schwerpunkt liegt beim Auto-Tunnel. In bestimmten Situationen hat sich der Tunnel wegen der Option „Stopp ohne Netz“ ständig selbst ein- und wieder ausgeschaltet. Das ist behoben. Auch in Netzen mit Anmeldeseite, zum Beispiel im Hotel-WLAN, soll der Auto-Tunnel nicht mehr hin und her springen.

Dazu kommt ein Fix für den Fall, dass Android den Auto-Tunnel-Dienst beendet. Danach startete der Dienst in manchen Fällen immer wieder neu, in den Release Notes ist von einem „Restart Storm“ die Rede. Auch das gehört jetzt der Vergangenheit an.

Samsung-Geräte bekommen eine eigene Korrektur: Die Erkennung des zugrunde liegenden Netzes, während das VPN aktiv ist, funktionierte dort nicht sauber.

Beim DNS wurden Fehler bei DoH und DoT behoben, die zu DNS-Timeouts geführt haben. Dafür wurde der DNS-Kern der App auf Version 1.6.0 angehoben. Wenn das VPN steht und einzelne Seiten trotzdem hängen, ist DNS oft der Grund.

Ein kleines Detail zum Schluss: Tunnelnamen mit problematischen Zeichen werden beim Export jetzt bereinigt, damit der Dateiexport nicht mehr scheitert.

EMPFEHLUNG

Soll man updaten?

Ich würde 5.7.3 einspielen, vor allem wenn man den Auto-Tunnel nutzt oder ein Samsung-Gerät hat. Es sind Bugfixes, große neue Funktionen gibt es diesmal nicht.

DOWNLOAD

Wo gibt es die Version?

↗

GitHub

Die APK direkt vom Entwickler. Release 5.7.3 ist dort als „Latest“ markiert: Release 5.7.3.

▤

IzzyOnDroid

Der F-Droid-kompatible Store führt 5.7.3 seit dem 19. September. Ein Client wie Neo Store oder Droid-ify hält die App aktuell: WG Tunnel bei IzzyOnDroid.

✎

Google Play

Ob die neue Version dort schon angekommen ist, habe ich nicht geprüft: WG Tunnel bei Google Play.

APK-Signatur prüfen

Wer die APK direkt von GitHub lädt, kann die Signatur prüfen. Laut Release Notes lautet der SHA-256-Fingerprint des Signaturzertifikats:

5204d82e766e8aa14dcbb06dc70aebae2bdd812d4d6203cd521a8a685d7d3d80

So lässt er sich prüfen (den Pfad zur APK anpassen):

apksigner verify --print-certs [Pfad zur APK] | grep SHA-256

MEHR

Mehr zu WG Tunnel

WG Tunnel ist ein freier Android-Client für WireGuard und AmneziaWG. Neben dem Auto-Tunnel gibt es einen Lockdown-Modus als eigenen Kill-Switch und einen lokalen Proxy (SOCKS5/HTTP).

Was seit Version 5.0.9 bis 5.7.2 alles passiert ist, steht in diesem Beitrag: WG Tunnel: Was sich seit Version 5.0.9 getan hat.

QUELLEN

Quellen und Links

VPN und Fernzugriff sauber aufsetzen?

Ob WireGuard, Firewall oder Fernzugriff: Nutzen Sie unsere IT-Leistungen.

Der Beitrag WG Tunnel 5.7.3 released: Feinschliff für Auto-Tunnel und DNS erschien zuerst auf RDDZ.

UniFi auf eigenen Server migrieren – UniFi OS Server unter Debian

dennis_rddz — Thu, 17 Sep 2026 16:04:11 +0000

UniFi · UniFi OS Server · Debian 13

UniFi auf eigenen Server migrieren – UniFi OS Server unter Debian

Wer UniFi bisher auf einem Cloud Key, einem klassischen UniFi Network Server oder bei einem anderen Hoster betreibt, kann UniFi Network auf einen eigenen Server umziehen. Diese Anleitung zeigt die Installation von UniFi OS Server unter Debian, die Vorteile des neuen Aufbaus und den Weg der Migration.

UNIFI OS SERVER

● Neuer Standard

Debian

ab 13

Podman

ab 4.9.3

RAM

ab 2 GB

UniFi Network ✓ enthalten

Site Manager ✓ kompatibel

Organizations ✓ verfügbar

Lizenz ✓ kostenlos

Vorbereiten → Installieren → Migrieren → Prüfen

✓ Debian 13 oder neuer

✓ Podman ab 4.9.3

✓ Lizenzfrei

✓ Zentral über Site Manager

✓ Migration per Backup oder Site Export

ÜBERBLICK

Warum UniFi OS Server?

Ubiquiti bezeichnet UniFi OS Server als neuen Standard für das Self-Hosting und hat damit den klassischen UniFi Network Server als bevorzugte Lösung abgelöst. Stand: 20. September 2026.

◐

Mehr als der alte Network Server

Der klassische Network Server stellte im Kern die Network Application bereit. UniFi OS Server bringt zusätzlich Funktionen der UniFi-Plattform mit, darunter Organizations, Identity-Provider-Integration und Site Magic SD-WAN.

▤

Mehrere Standorte zentral

Im UniFi Site Manager lassen sich mehrere Installationen über eine Oberfläche verwalten. Dabei spielt es keine Rolle, ob ein Standort über Cloud Key, UniFi OS Server oder eine andere unterstützte UniFi Console läuft.

↗

Verwaltung von außen

Mit einem UI Account lässt sich der Server über den Site Manager auch außerhalb des lokalen Netzwerks verwalten. Er kann im eigenen Serverraum, im Rechenzentrum oder bei einem Hoster stehen.

↻

Updates zentral verwalten

Der Update Manager im Site Manager zeigt verfügbare Updates aller eigenen Installationen an. Auto-Updates und Release Channel stellt man unter Settings → Control Plane → Updates ein.

✓

Lizenzfrei

Nach Angaben von Ubiquiti ist UniFi OS Server vollständig lizenzfrei und für alle UniFi-Nutzer verfügbar. Kosten entstehen nur für Server oder VM und den Betrieb.

✎

Kein gewöhnlicher Container

UniFi OS Server ist eine Komplettlösung. Einige Dienste für Geräteerkennung, Adoption und automatische Updates laufen direkt auf dem Linux-Host, deshalb gibt es keinen einfachen Docker- oder Podman-Container.

AUFBAU

So sieht ein typischer Aufbau aus

Der Server kann im eigenen Netzwerk oder extern stehen. Drei typische Varianten:

◐

Ein Standort

Debian/KVM
→ UniFi OS Server
→ UniFi Network
→ Switches und Access Points

▤

Mit UniFi Protect

Cloud Key (zum Beispiel Gen2 Plus)
→ UniFi Protect
→ Kameras

Der vorhandene Cloud Key muss dafür nicht ersetzt werden.

↗

Mehrere Standorte

Standort A: UniFi OS Server
Standort B: UniFi OS Server
Standort C: Cloud Gateway
→ zentral im Site Manager, sofern die Berechtigungen vorhanden sind.

GRENZEN

Was UniFi OS Server nicht ersetzt

UniFi OS Server dient dem Self-Hosting von UniFi Network. Bevor ein Cloud Key oder Gateway abgeschaltet wird, sollte man diese Punkte kennen:

✎

Protect, Access, Talk, Connect

Diese Anwendungen lassen sich nicht auf UniFi OS Server hosten. Sie benötigen weiterhin eine kompatible UniFi Console.

↻

Cloud Key

Ein Cloud Key kann Protect und weitere Anwendungen weiter betreiben. Die Network-Geräte kann er parallel zu einem UniFi OS Server nicht verwalten, denn beide enthalten die Network Application und ein Gerät kann nur einen Host haben.

▤

Cloud Gateways

UDM, UCG und Fortress Gateway haben die Network Application eingebaut und lassen sich nicht von einem UniFi OS Server verwalten. Passend sind unabhängige Gateways der UXG-Serie.

VORAUSSETZUNGEN

Das braucht der Server

Für den Start reichen laut Ubiquiti geringe Ressourcen. Für eine produktive Umgebung sollte man aber nicht direkt mit den absoluten Mindestwerten arbeiten.

◐

Betriebssystem

Debian 13 oder neuer, Ubuntu 24.04 oder neuer (oder eine andere moderne Distribution) mit x86-64, systemd und libc 2.31 oder neuer.

▤

Podman

Podman ab 4.9.3 (mit pasta-Networking) und slirp4netns ab 1.2. Beide Pakete lassen sich per apt installieren.

↻

Hardware laut Ubiquiti

x86-64-Prozessor, mindestens 2 GB RAM, mindestens 10 GB freier Speicher und 100-Mbit/s-Ethernet.

✓

Unsere Empfehlung

KVM-VM mit 2 vCPU, 4 GB RAM, 32 GB SSD und 1 Gbit/s. Bei größeren Umgebungen entsprechend größer dimensionieren.

CPU

2 vCPU

RAM

4 GB

Speicher

32 GB SSD

Netzwerk

1 Gbit/s

Betriebssystem

Debian 13 Minimal (ohne Desktop-Umgebung)

Virtualisierung

KVM

KVM oder LXC?

Für eine neue Installation bevorzugen wir KVM. Eine eigene VM trennt UniFi OS Server sauber vom Host und macht Wartung, Backups und spätere Änderungen übersichtlich. Aus der Ubiquiti-Community gibt es außerdem Berichte, dass sich UniFi OS Server wegen des Installers nicht in einem LXC-Container installieren lässt.

Der Server sollte per SSH erreichbar sein und eine feste interne IP-Adresse besitzen. In dieser Anleitung verwenden wir als Beispiel 192.168.10.10.

VM nicht klonen

Ubiquiti empfiehlt, VMs nicht zu klonen (Ausnahme: Hochverfügbarkeit oder Failover). Geklonte VMs verwenden dieselben Remote-Zugriffstoken für den Site Manager, was zu unerwartetem Verhalten führt. Jede Installation sollte deshalb neu aufgesetzt werden.

INSTALLATION

UniFi OS Server unter Debian installieren

Als Beispieladresse verwenden wir 192.168.10.10. Sie muss durch die tatsächliche IP-Adresse des eigenen Servers ersetzt werden.

1. Debian vorbereiten

Das System zuerst aktualisieren, dann die von Ubiquiti genannten Pakete installieren und die Podman-Version prüfen:

sudo apt update
sudo apt upgrade -y
sudo apt install -y podman slirp4netns
podman --version

Podman sollte mindestens in Version 4.9.3 vorliegen.

2. Installer herunterladen

Den Installer immer direkt von Ubiquiti beziehen. Auf der UniFi-Download-Seite den UniFi OS Server für Linux auswählen, die Link-Adresse kopieren und auf dem Server herunterladen:

wget

Den Platzhalter durch den aktuellen Link ersetzen.

3. Installer ausführen

Die Datei ausführbar machen und den Installer starten:

chmod +x 
sudo ./

Am Ende nennt der Installer die Adresse, unter der UniFi OS Server läuft. Ob der Dienst läuft, lässt sich so prüfen:

sudo systemctl status uosserver

Läuft auf derselben Maschine noch ein alter UniFi Network Server, muss er vor der Installation geschlossen werden.

4. Weboberfläche öffnen

Die Adresse steht im Installer; sie lautet üblicherweise https://:11443. Bei unserer Beispielkonfiguration:

https://192.168.10.10:11443

Beim ersten Aufruf zeigt der Browser eine Zertifikatswarnung, denn der Server verwendet zunächst ein selbstsigniertes Zertifikat. Ein eigenes Zertifikat lässt sich unter Settings → Control Plane → Console → Certificates hochladen. Danach die Grundkonfiguration durchlaufen. Für den Zugriff über den Site Manager anschließend einen UI Account anlegen oder verbinden (Remote Management).

5. UniFi Network einrichten

Nach der Grundkonfiguration steht die UniFi Network Application auf dem neuen Server bereit. Vor der Migration sollte die neue Installation vollständig eingerichtet und auf aktuellem Stand sein. Der Server muss danach dauerhaft laufen: Ist er offline, arbeiten die Geräte mit der letzten verfügbaren Konfiguration weiter.

Nützliche Befehle

Dienst stoppen, starten und den Autostart beim Systemstart steuern:

sudo systemctl stop uosserver
sudo systemctl start uosserver
sudo systemctl disable uosserver
sudo systemctl enable uosserver

MIGRATION

Bestehende Umgebung migrieren

Ziel: Die vorhandene Network-Konfiguration liegt anschließend auf dem neuen UniFi OS Server, und die UniFi-Geräte verwenden ihn als Network Host. Welcher Weg passt, hängt vom Ausgangssystem ab.

Network-Backup (.unf)

Für einen selbst gehosteten UniFi Network Server. Das Backup wird auf dem neuen Server wiederhergestellt.

Layer-3-Adoption

Für Geräte, die per DNS, DHCP Option 43 oder Layer-3-Befehl adoptiert wurden, etwa über VLANs oder das Internet.

Site Export

Für Sites von Cloud Key, Official UniFi Hosting oder einem UniFi OS Server mit Multi-Site-Verwaltung. Ubiquiti nennt ihn außerdem als manuellen Weg unter Linux.

Vorher: Vorbereitung und Backup

Die neue Network Application auf den aktuellen Stand bringen.
Ein Backup der bisherigen Installation erstellen (Network-Backup oder Site Export).
SSH-Benutzername und Passwort der Geräte notieren (Devices → Device Updates & Settings → Device SSH Settings), falls sich ein Gerät später nicht verbindet.
Alle anderen UniFi-Geräte bleiben zunächst wie bisher verbunden.

Methode 1: Network-Backup (.unf)

In der alten Installation das Network-Backup (.unf) unter Settings → Control Plane → Backups herunterladen.
UniFi OS Server fertig einrichten, die Geräte bleiben dabei verbunden.
Das Backup auf dem neuen Server unter Settings → Control Plane → Backups einspielen.
Warten, bis alle Geräte online sind. Danach die alte Installation herunterfahren oder die Geräte dort mit „Forget“ entfernen, damit sie sich nicht erneut verbinden.
Erscheint ein Gerät offline oder als „Managed by Another Console“, zuerst die Layer-3-Adoption versuchen.

Methode 2: Layer-3-Adoption

Backup wie bei Methode 1 erstellen und auf dem neuen Server wiederherstellen.
In der ursprünglichen Network Application den Schalter „Override Inform Host“ aktivieren und die IP-Adresse des neuen Servers eintragen.
Warten, bis alle Geräte in der neuen Installation online sind, dann die Geräte in der alten Installation mit „Forget“ entfernen und diese herunterfahren.

Alternativ lässt sich der Inform-Host pro Gerät per SSH setzen. Die IP-Adresse ist wieder unsere Beispieladresse:

set-inform http://192.168.10.10:8080/inform

Methode 3: Site Export

In der bisherigen Installation unter Network Settings → System → Site Management auf „Export Site“ klicken und die Site-Datei herunterladen.
In der neuen Network Application im Site Switcher „Import Site“ wählen und die Datei hochladen. Ist der Site Switcher nicht sichtbar, zuerst „Multi-Site Management“ unter Settings → System → Site Management aktivieren.
Im geführten Assistenten der alten Installation die Geräte auswählen und die Inform-URL (IP-Adresse des neuen Servers) eintragen.
Die migrierten Geräte in der alten Installation mit „Forget“ entfernen und warten, bis alle online sind.

Wenn ein Gerät nicht online kommt

Nicht direkt einen Factory Reset durchführen. Zuerst Netzwerkverbindung, Inform-Adresse, DNS und Firewall prüfen und die Layer-3-Adoption versuchen. Erst wenn das scheitert, ist ein Zurücksetzen und erneutes Adoptieren des Geräts nötig.

NACH DER MIGRATION

Alles gründlich prüfen

Dass alle Geräte „Online“ anzeigen, reicht nicht. Diese Punkte sollten getestet sein, bevor der alte Host abgeschaltet wird:

✓Geräte online: Access Points, Switches, Gateways und weitere Network-Geräte

✓WLAN: alle SSIDs vorhanden, Internet und interne Ressourcen erreichbar

✓Netzwerke und VLANs übernommen, Trennung funktioniert

✓Switches: Port-Konfiguration und VLAN-Zuweisungen stimmen

✓Firewall: vorhandene Regeln funktionieren wie erwartet

✓VPN und Routing getestet

✓UniFi Protect (auf anderer Console): Kameras, Aufzeichnungen und Oberfläche

✓Release Channel und Firmware-Stände geprüft

✓Alte Geräteeinträge erst danach mit „Forget“ entfernen

✓Alten Network Server erst abschalten, wenn alles läuft

NETZWERK & FIREWALL

Extern betreiben – und Ports beachten

Der Server muss nicht im selben Netzwerk wie die verwalteten Geräte stehen und kann auch im Rechenzentrum oder bei einem Hoster laufen. Dann sollten Netzwerkverbindung, Firewall-Regeln und Erreichbarkeit vor der Migration sorgfältig geplant werden. Für Geräte in anderen Netzen ist Layer-3-Adoption nötig.

TCP 8080

Kommunikation mit UniFi-Geräten und Anwendungen (Inform)

UDP 3478

STUN für Geräte-Adoption und Kommunikation

TCP 11443

Weboberfläche von UniFi OS Server (Adresse nennt der Installer)

TCP 443

Remote Access und Zugriff auf die Weboberfläche

TCP 8883

Remote Access (ausgehend)

TCP 8444

Secure Portal für den Hotspot (beim Network Server war es Port 8843)

UDP 53 und 123

DNS und NTP, unter anderem für Updates und sichere Verbindungen

Die vollständige Liste steht in der Required Ports Reference von Ubiquiti. Bei einer einfachen Installation im gleichen internen Netzwerk ist die Einrichtung entsprechend unkomplizierter.

UPDATES

Updates und Release Channel

↻

Zentral im Site Manager

Der Update Manager zeigt Updates aller Installationen an. Größere Umgebungen sollten Updates trotzdem kontrolliert und mit Blick auf die Release Notes einspielen. Alternativ geht es direkt über die lokalen Control-Plane-Einstellungen.

◐

Release Channel

Es gibt den offiziellen Kanal und Early Access. Vor der Migration prüfen, welchen Kanal die bestehende Umgebung nutzt, und den neuen Server passend einstellen: Settings → Control Plane → Updates.

✎

Firmware prüfen

Immer kontrollieren, welche Geräte-Firmware tatsächlich angeboten wird. Ein niedrigerer Versionsstand ist kein normales Upgrade und sollte nicht ohne vorherige Prüfung installiert werden.

FAZIT

UniFi OS Server ist mehr als ein neuer Name

Wer UniFi Network selbst hosten möchte, bekommt eine deutlich stärker in das aktuelle UniFi-Ökosystem integrierte Plattform: mit Site Manager, Remote Management, Multi-Site-Verwaltung und zentraler Update-Verwaltung. Der Server muss dabei nicht am jeweiligen Standort stehen. Er kann zum Beispiel als KVM-VM im Rechenzentrum oder bei einem Hoster laufen.

Für eine kleine bis mittlere Umgebung reicht als Basis eine KVM-VM mit Debian 13, 2 vCPU, 4 GB RAM und 32 GB SSD. Wer bereits eine UniFi-Umgebung besitzt, muss nicht von vorne beginnen: Je nach Ausgangssystem wird die Konfiguration per Network-Backup oder Site Export übernommen, anschließend stellt man die Geräte auf den neuen Network Host um. UniFi Protect kann parallel auf einem vorhandenen Cloud Key weiterlaufen.

FAQ

Häufige Fragen zu UniFi OS Server

Was ist UniFi OS Server?

Ubiquiti nennt ihn den neuen Standard für das Self-Hosting von UniFi. Er löst den klassischen UniFi Network Server ab und bringt Funktionen wie Organizations, Identity-Provider-Integration und Site Magic SD-WAN mit.

Was kostet UniFi OS Server?

Nach Angaben von Ubiquiti nichts: Er ist lizenzfrei und für alle UniFi-Nutzer verfügbar. Kosten entstehen nur für Server oder VM und den Betrieb.

Welche Debian-Version wird benötigt?

Debian 13 oder neuer. Alternativ werden Ubuntu 24.04 oder neuer und andere moderne Distributionen mit systemd, Podman ab 4.9.3 und slirp4netns ab 1.2 unterstützt.

Läuft UniFi OS Server als Docker-Container?

Nein. Ubiquiti beschreibt UniFi OS Server als Komplettlösung, die bestimmte Dienste auf dem Host benötigt, etwa für Geräteerkennung, Adoption und automatische Updates. Die Installation erfolgt per Installer, intern kommt Podman zum Einsatz.

Kann ich UniFi Protect auf UniFi OS Server installieren?

Nein. Protect, Access, Talk und Connect benötigen weiterhin eine kompatible UniFi Console, zum Beispiel einen Cloud Key.

Kann ich eine UDM oder ein Cloud Gateway mit UniFi OS Server verwalten?

Nein. Cloud Gateways enthalten die Network Application bereits. Passend sind unabhängige Gateways der UXG-Serie oder andere Gateways.

Unter welcher Adresse erreiche ich die Weboberfläche?

Der Installer nennt die Adresse am Ende der Installation. Üblicherweise lautet sie https://:11443.

Kann ich UniFi OS Server in einem LXC-Container betreiben?

Wir empfehlen KVM. In der Ubiquiti-Community wird berichtet, dass sich UniFi OS Server wegen des Installers nicht in einem LXC-Container installieren lässt.

Muss der Server dauerhaft laufen?

Ja. Um Geräte anzuzeigen und zu verwalten, muss UniFi OS Server durchgehend laufen. Ist er offline, arbeiten die Geräte mit der letzten verfügbaren Konfiguration weiter.

Muss ich die UniFi-Geräte bei der Migration neu einrichten?

In der Regel nicht. Nach Backup-Wiederherstellung oder Site Export übernehmen die Geräte den neuen Host. Erscheint ein Gerät offline oder als „Managed by Another Console“, zuerst die Layer-3-Adoption versuchen. Erst danach zurücksetzen und neu adoptieren.

Kann ich die UniFi-OS-Server-VM klonen?

Ubiquiti rät davon ab, außer für Hochverfügbarkeit oder Failover. Geklonte VMs verwenden dieselben Remote-Zugriffstoken für den Site Manager, was zu unerwartetem Verhalten führt.

Welche Ports braucht der Remote-Zugriff über den Site Manager?

Unter anderem TCP 443 und TCP 8883 (ausgehend) sowie UDP 3478 für STUN. Die vollständige Liste steht in der Required Ports Reference von Ubiquiti.

QUELLEN

Quellen und Links

Sie benötigen Hilfe bei UniFi?

Ob Planung, Installation oder Migration: Nutzen Sie unsere IT-Leistungen.

Der Beitrag UniFi auf eigenen Server migrieren – UniFi OS Server unter Debian erschien zuerst auf RDDZ.

WG Tunnel 5.7.2

dennis_rddz — Wed, 09 Sep 2026 08:49:38 +0000

WG Tunnel 5.7.2

WG Tunnel: Was sich seit Version 5.0.9 getan hat

Wer WG Tunnel auf Android nutzt, kennt die App vermutlich vor allem wegen der vielen Möglichkeiten rund um WireGuard und AmneziaWG. Seit Version 5.0.9 hat sich bei der App einiges getan.

Ich habe mir deshalb einmal die Entwicklung bis zu den aktuellen Versionen angesehen. Dabei fällt vor allem auf: WG Tunnel wurde weniger durch große neue Funktionen verändert, sondern vor allem bei Stabilität, DNS, Wiederherstellung und AmneziaWG weiterentwickelt.

Von 5.0.9 zu einer deutlich robusteren VPN-App

In Version 5.0.9 lag der Schwerpunkt noch auf kleineren Fehlerbehebungen, unter anderem beim Start des Tunnels im Proxy-Modus und bei der Wiederherstellung des Foreground-Service.

Danach wurde die App Schritt für Schritt umfangreicher.

AmneziaWG wurde weiterentwickelt

Eine der größeren Änderungen betrifft AmneziaWG. WG Tunnel unterstützt neben klassischem WireGuard auch AmneziaWG und hat die Unterstützung im Laufe der Versionen weiter ausgebaut.

Mit neueren Versionen kamen unter anderem aktualisierte AmneziaWG-Versionen und Verbesserungen bei der Verarbeitung entsprechender Konfigurationen hinzu.

Das ist besonders interessant für Nutzer, die WireGuard in Netzwerken einsetzen, in denen eine normale VPN-Verbindung nicht zuverlässig funktioniert.

Automatische Wiederherstellung wurde verbessert

Ein Punkt, der im Alltag wesentlich wichtiger ist als eine neue Einstellung in der Oberfläche: Was passiert, wenn Android die App beendet oder das Smartphone neu startet?

Hier wurde bei WG Tunnel einiges verbessert.

Die automatische Wiederherstellung aktiver Tunnel und des Auto-Tunneling-Dienstes wurde zuverlässiger. Auch nach Neustarts, App-Updates oder Netzwerkänderungen soll die Verbindung wieder sauber aufgebaut werden.

WG Tunnel bietet dafür unter anderem automatisches Tunneling, Tunnel-Neustarts bei Problemen und verschiedene Überwachungsfunktionen.

DNS und Split-DNS wurden deutlich ausgebaut

Ein weiterer großer Schwerpunkt der vergangenen Versionen ist DNS.

Neben Verbesserungen bei IPv4 und IPv6 kamen unter anderem Möglichkeiten für:

Split-DNS
eigene DNS-Regeln
DNS über bestimmte Domains
bessere Behandlung von DNS-Änderungen
DNS over HTTPS für bestimmte Auflösungen
Fehlerbehebungen bei benutzerdefiniertem Tunnel-DNS

Gerade die letzten Versionen haben hier noch einmal nachgebessert. Probleme mit benutzerdefinierten DNS-Konfigurationen und Race Conditions wurden behoben.

Das klingt zunächst nach einem Detail, kann im Alltag aber den Unterschied zwischen „VPN funktioniert“ und „warum lädt diese eine Webseite eigentlich nicht?“ ausmachen.

IPv6 und Netzwerkwechsel

Auch beim Umgang mit IPv4 und IPv6 wurde nachgebessert.

WG Tunnel kann inzwischen besser mit unterschiedlichen Netzwerkbedingungen umgehen und wurde unter anderem beim Wechsel zwischen Netzwerkverbindungen und bei IPv6-Endpunkten stabiler.

Das ist vor allem auf Smartphones relevant, weil sich die Netzwerkumgebung unterwegs ständig ändern kann – WLAN zu Mobilfunk, anderes WLAN oder ein Wechsel des Netzes.

Lockdown und Kill-Switch

Auch der Lockdown-Modus wurde weiter gepflegt.

WG Tunnel bringt einen eigenen Kill-Switch mit, der verhindern soll, dass Netzwerkverkehr außerhalb des VPN-Tunnels läuft. Dabei kann beispielsweise auch ein lokaler Netzwerkzugriff erlaubt werden.

Das gehört zu den Funktionen, die WG Tunnel von einer einfachen WireGuard-Konfigurations-App unterscheiden.

Benachrichtigungen und Oberfläche

In den neueren Versionen wurde außerdem an den Benachrichtigungen für aktive Tunnel gearbeitet.

Die Informationen in der Android-Benachrichtigung lassen sich detaillierter darstellen, und auch die Synchronisation der App-Sprache mit Android wurde verbessert.

Gleichzeitig wurde der Speicherverbrauch beim Logging reduziert.

Und natürlich: jede Menge kleinere Fehler

Neben den größeren Punkten gab es über die verschiedenen Versionen hinweg zahlreiche kleinere Korrekturen.

Dazu gehören unter anderem Probleme mit:

Tunnel-Importen
DNS
IPv6
Android TV
Arbeitsprofilen
Netzwerk-Erkennung
Tunnel-Recovery
Proxy-Modus
AmneziaWG-Paketen
Speicherverbrauch
benutzerdefinierten DNS-Einstellungen

Nicht jeder dieser Punkte betrifft jeden Nutzer. Insgesamt merkt man der Entwicklung aber an, dass WG Tunnel immer stärker auf zuverlässigen Dauerbetrieb ausgelegt wird.

Aktuelle Version 5.7.2 als Download

Direkt zu WG-Tunnel auf Github

Der Beitrag WG Tunnel 5.7.2 erschien zuerst auf RDDZ.