WireGuard ist eine schlanke Alternative zu OpenVPN und IPsec und seit 2020 fester Bestandteil des Linux- Kernels. Geübte Kommandozeilen- Ritter erstellen Schlüsselpaare und Konfiguration in wenigen Minuten und die VPN-Verbindung steht [1]. Wer die Command Line meidet oder einen größeren Rollout vor sich hat, greift zur Web-GUI von Firezone. Die Software hat nicht nur WireGuard auf dem Schirm, sondern auch Firewallregeln und Multifaktor-Authentifizierung, die es in WireGuard so nicht gibt.

Firezone läuft grundsätzlich auf allem mit Linux-Kernel 5.6 oder höher sowie auf x86_64- und ARM-Prozessoren. Das trifft auf die meisten Angebote von Cloudservern zu, aber auch auf Mini-Computer wie den Intel NUC oder den Raspberry Pi. Welche Hardware die beste für den eigenen Anwendungsfall ist, hängt von der gewünschten Durchsatzrate ab. Als Anhaltspunkt liefert ein Raspberry Pi 3B+ für eine einzelne WireGuard-Session eine Durchsatzrate von etwa 120 MBit/s. Für ein Unternehmensnetz ist das eher knapp bemessen, aber im Heimumfeld ein großzügiger Messwert.

Die Entwicklung von Firezone verläuft über GitHub [2]. Wer den Quellcode nicht selbst kompilieren will, greift zu einem fertigen Paket, das der Entwickler für die üblichen Linux-Distros anbietet. Die Installation unterscheidet zwischen Debian-basierten Systemen mit dem Paketmanager apt sowie Distributionen auf Red-Hat-Basis mit dem wohlbekannten yum. Das Softwarepaket hat zwar Abhängigkeiten, aber deren Installation überlässt es nicht dem Paketmanager, sondern dem eigenen Einrichtungs-Wizard.

Noch einfacher geht es mit dem Installer- Skript. Das ermittelt die Distribution, lädt das passende Paket auf den lokalen Rechner und startet die Installation:

Wer sich die Software zu Testzwecken nur kurz anschauen möchte, kann die Ersteinrichtung überspringen und mit firezonectl reconfigure direkt loslegen. Dieser Befehl setzt das um, was als Konfigurationsanweisungen in der Datei "/etc/firezone/ firezone.rb" steht. Jede Änderung innerhalb der Datei macht die erneute Befehlsausführung nötig. Falls die lokale Firewall aktiv ist (und das sollte sie sein), bedarf der Firezone-Rechner einer Ausnahme für HTTPS und den WireGuard-Port 51820:

Im letzten Schritt auf der Kommandozeile verrät Firezone das initiale Admin-Kennwort. Ein Default-Passwort gibt es nicht – jede Installation hat ein individuelles Kennwort, das der Admin (und jeder reguläre User) nach der Anmeldung mit seinem Passwortgenerator zur Multifaktor- Authentifizierung absichern kann. Firezone setzt das Kennwort durch

Auf dem Rechner läuft jetzt ein Webdienst, der per HTTPS über seine IPAdresse erreichbar ist. Unter Linux liefert ip addr show die IP-Adresse(n). Wer sein Firezone in der Amazon-Cloud betreibt, erhält eine lokale Adresse, die hier nicht brauchbar ist. Die öffentliche Adresse steht in der EC2 Management Console.

Nach dem ersten Login lohnt sich ein Blick in den Bereich "Settings", denn hier legt der Admin Einstellungen fest, die für alle zukünftigen Geräte gelten (Bild 1). Das große Textfeld bei "Allowed IPs" erwartet alle IP-Netze, die die Clients durch den WireGuard-Tunnel schicken sollen. Ohne Angabe von IP-Adressen wird Wire - Guard zum Full-Tunnel und leitet die gesamte Kommunikation hier durch.

In das Feld "Endpoint" tippen Sie den DNS-Namen des Firezone-Servers ein, so wie die Clients ihn später auflösen sollen. Bei leerem Feld nimmt Firezone automatisch die eigene öffentliche IPv4- Adresse. Aber Achtung: Bei wechselnden IP-Adressen ändert sich die Erreichbarkeit des Servers, die WireGuard-Settings beim Client bleiben hierzu aber gleich. Für diesen Fall hilft ein DynDNS-Account, der die dynamischen öffentlichen IP-Adressen hinter einem festen DNS-Namen verbirgt. Auf diesen DNS-Namen lassen sich dann auch die Zertifikate ausstellen. Denn bei einer seriösen Installation sollte die administrative Webseite von Firezone ein ordentliches Zertifikat anbieten, das jeder Browser validieren kann. Wenn kein passendes vorliegt, kann Let's Encrypt aushelfen. Die Konfigurationsdatei von Firezone ist darauf vorbereitet und beispielhaft einfach. Firezone benötigt nur drei Dinge, um ein Zertifikat von Let's Encrypt zu empfangen: einen gültigen DNS-Namen, das ACME-Protokoll und die Erreichbarkeit auf TCP-Port 80. Der DNS-Name gehört in die Konfigurationsdatei und um den Rest kümmert sich firezone- ctl reconfigure:

Anschließend präsentiert der Webserver dem Browser stolz sein gültiges Zertifikat.

Der Firezone-Rechner ist bereits aus dem LAN erreichbar, aber der Zugriff aus dem Internet scheitert noch am Zugangsrouter. Hier benötigen Fritzbox und Konsorten eine Adressumsetzung, die öffentliche Anfragen für die eigene Internetadresse an die Firezone-Box weiterreicht.

Eine Regel für die Adressumsetzung umfasst mindestens UDP-Port 51820. Die Portweiterleitung einer Fritzbox sendet eingehende WireGuard-Pakete weiter an den Firezone-Rechner und macht ihn damit aus dem Internet erreichbar. Wenn die Administration ebenfalls aus dem Internet erfolgen soll, kommt noch TCP-Port 443 hinzu. Und wer seine TLS-Zertifikate von Let's Encrypt bezieht, braucht zusätzlich noch TCP-Port 80, allerdings nur während der Ausstellung und Verlängerung.

Die Fritzbox muss zusätzlich die IP-Netze der WireGuard-Tunnel kennen und die entpackten Tunnelpakete an den Firezone- Rechner zurückschicken. Dazu benötigt sie in ihrer Routingtabelle eine statische Route für das IPv4-Netzwerk 10.3.2.0 mit der Subnetzmaske 255. 255.255.0. Das Gateway ist dabei die IPv4- Adresse des Firezone-Hosts. Bei IPv6 sieht die Sache einfacher aus, da sich die Router per Router-Advertisements gegenseitig über ihre Präfixe informieren.

Einige Speedport-Routermodelle erlauben keinen Zugriff auf die eigene Routingtabelle. Firezone lässt sich in diesem Fall trotzdem nutzen, wenn die IP-Adressen innerhalb des WireGuard-Tunnels zum IP-Netz des Routers passen. Das Speedport- Netz, typischerweise 192.168.2.0/24, gehört dann teilweise zu den LAN-/Wi- Fi-Clients und teilweise den WireGuard- Einwählern. Wichtig ist, dass sich die Bereiche nicht überschneiden. Wenn das Speedport-Gerät die Werte aus der Voreinstellung benutzt, dann hört die dynamische Adressvergabe bei ".200" auf. Fire - zone könnte die Adressen oberhalb davon vergeben. Die passenden Zeilen in der Konfigurationsdatei lauten:

Eine Konfigurationsempfehlung für größere Umgebungen ist schwierig, da sie vom Firewalldesign abhängt. Grundsätzlich gilt, dass Anfragen auf UDP-Port 51820 irgendwie beim Firezone-Server ankommen müssen. Wenn dieser nicht im LAN steht, sondern in einem isolierten Netzsegment, dann muss die Firewall zusätzlich die Anwendungspakete erlauben, die aus den Wire- Guard-Tunneln fließen. In der Voreinstellung stammen diese aus den IP-Netzen "10.3.2.0/24" und "fd00::3:2:0/120".

Weiter geht's mit der Erreichbarkeit der WireGuard-Netze im Unternehmensnetz. Hier ist das Routingprotokoll gefragt und die Umsetzung erneut individuell. Der Firezone-Server könnte mit dem Zusatzpaket Free Range Routing seine neuen IP-Netze per dynamischem Routingprotokoll an die Infrastruktur verteilen, was in Firewallumgebungen nicht gerne gesehen wird. Im Zweifelsfall bleibt es bei statischem Routing.

Bei Version 6 des Internet-Protokolls sieht die Welt einfacher aus, denn Firezone ist vollständig IPv6-ready. In jedem Adressfeld akzeptiert Firezone eine IPv4- oder eine IPv6-Adresse. Die berüchtigte Adressumsetzung ist grundsätzlich nicht vonnöten. Firewallregeln und die Einträge für die Routingtabelle funktionieren genauso wie bei IPv4.

Alle Komponenten sind nun eingerichtet und die Infrastruktur ist startklar. Im Webmenü "Users" erhält der erste Anwender jetzt seinen Zugang, der lediglich aus E-Mail- Adresse und Kennwort besteht. Die E-Mail-Adresse wird nicht überprüft und dient als Benutzername. Damit kann sich der Anwender selbst am Firezone-Host anmelden und eigene Geräte anlegen.

Die Einstellungen für das neue Gerät ergeben sich aus den Voreinstellungen, die der Admin bereits getroffen hat. Allerdings ist es möglich, von diesen Vorgaben abzuweichen. Am Ende präsentiert Firezone die Konfiguration für einen Wire- Guard-Client und einen QR-Code für das Smartphone. Wer diese Informationen vorschnell wegklickt, wird überrascht sein, dass Firezone die Werte nur ein einziges Mal anzeigt (Bild 2).

Aus diesem Grund ist es sinnvoll, die Webseite auf einem Gerät aufzurufen, das bereits einen WireGuard-Client hat. Dann lassen sich die Konfigurationszeilen per Copy-and-Paste in die WireGuard-App kopieren. Beim Smartphone ist die Einrichtung noch schlanker, denn der QR-Code enthält alle Einstellungen für die App. Nur den Titel der Verbindung muss der Nutzer selber festlegen.

Die Vorgehensweise zum Anlegen eines neuen Users plus Gerät ist zwar simpel, skaliert aber nicht gut. Wenn die eigene Anwenderschaft die dreistellige Marke überschreitet, macht das Mausschubsen wenig Spaß und die händische Eingabe führt zu Tippfehlern in Form von lustigen Usernamen und falschen Kennwörtern.

Üblicherweise haben Softwareprodukte dieser Art eine Anbindung an einen Verzeichnisdienst, wie beispielsweise das Active Directory. Firezone geht einen anderen Weg und unterstützt mit OpenID-Connect und SAML zwei Protokolle zum Anzapfen eines Identity Providers. Auf der Webseite sind Konfigurationsbeispiele für Microsoft Azure und Google aufgeführt. Fast alle Beispiele haben gemein, dass es sich um kommerzielle Anbieter handelt. Wer ohne Budget auskommen möchte und lediglich das hausinterne Active Directory benötigt, sei auf die Microsoft AD Federation Services oder Red Hats Keycloak [3] verwiesen. Keycloak ist mit einem einzigen (Docker)- Befehl installiert und gestartet.

Da die offizielle Dokumentation Keycloak noch als "Untested but known to work" führt, enthält unser Listing-Kasten die JSON-Anweisungen für Firezones Konfigurationsdatei. Auf grafischem Weg akzeptiert die Webseite bei "Settings / Security" den Zugang zu Keycloak. Vor dem Abspeichern müssen Sie die URLs an die eigene Umgebung anpassen. Der Pfad bei "discovery_document_uri" führt zum Server mit Keycloak. Die URL "redirect_uri" leitet nach der Anmeldung zurück zur Firezone-Webseite. Das "client_secret" erzeugt Keycloak, nachdem der Client dort angelegt ist. Als Client bezeichnet Open- ID-Connect eine Instanz, die Benutzer authentifizieren möchte. Da Firezone die HTTPS-Zertifikate seiner Identity Provider prüft, sollte der selbstgehostete Keycloak-Container nicht mit Bastelzertifikaten laufen, sondern gültiges Material vorweisen. Wenn die Web-GUI von Firezone alle Änderung angenommen hat, erscheint auf der Login-Seite ein Button mit dem Titel "Sign in with Keycloak". Die Anmeldung leitet den User auf die Webseite von Keycloak, die die Zugangsdaten erwartet. Bei erfolgreicher Validierung führt Keycloak den User zurück in den persönlichen Bereich von Firezone, wo er neue Geräte anlegen kann. Mit diesem Aufbau muss der Admin in Firezone keine Benutzerkonten für seine Mannschaft anlegen. Beim Troubleshooting sind die angemeldeten User dennoch in Firezone sichtbar und mit einem administrativen Zugang lassen sich Geräte (und Nutzer) wieder entfernen.

Sobald der VPN-Tunnel steht, fließen die Pakete ungehindert dort hindurch. Firezone bringt eine Mini-Firewall mit, die den Datenverkehr filtern kann, sobald er aus dem WireGuard- Tunnel kommt. Es gibt eine Allow-Liste, die Datenverkehr gestattet, und eine Deny-Liste, die Verbote ausspricht. Bei widersprüchlichen Regeln gewinnt die erstgenannte. Eine Filterregel gilt für einen gesonderten User oder für alle Teilnehmer. Die Kriterien einer Regel umfassen das Zielnetz, einen Firezone- User und einen TCP/UDP-Port. Mit Firezone-Nutzern sind alle Geräte des ausgewählten Anwenders gemeint.

Auf diese Weise lassen sich einzelne Bereiche des internen Netzes für die Firezone-User ausblenden. Die Richtlinie in Bild 3 ermöglicht das Least-Privilege-Prinzip und gestattet den Firezone- Usern nur Zugriff auf ausgewählte Dienste. Die Möglichkeiten dieser Security-Maßnahme sind nicht sonderlich granular, aber deutlich anwenderfreundlicher als iptables oder nftables. Wer mehr Flexibilität benötigt, muss seine Richtlinie in iptables-Syntax formulieren.

Firezone eignet sich nicht nur für den VPN-Zugriff ins eigene Netz, sondern auch als Zugangspunkt in die persönliche Cloud. Es gibt zwar fertige Maschinen-Images bei Amazon und Co., aber eine Blanko-VM mit der Firezone-Software ist aktueller und günstiger.

Die Installation verläuft exakt so wie bei der lokalen Installation: Linux-Distro wählen, Instanz starten, Paket laden und installieren. Je nach Cloudprovider benötigt die Firewall noch ein paar Löcher für die verwendeten Ports. Beispielsweise schützt AWS die Instanzen seiner Kunden mit einer Security Group vor der Welt. Diese funktioniert wie eine Fire wall, die per eingehenden Regeln den Zugriff auf die eigene Firezone-Instanz gestatten muss. Die Regeln innerhalb des Wire Guard-Tunnels sind davon nicht betroffen.

Der Zugang zur eigenen Virtual Private Cloud in Amazons Rechenzentrum ermöglicht nicht nur den geschützten Zugriff auf die dort laufenden Instanzen. Der Verkehr lässt sich am Ende des WireGuard-Tunnels ins Internet einspeisen. Der damit erreichte Webzugriff stammt nicht mehr von der heimischen IP-Adresse, sondern aus einer beliebigen Region, in der die Rechenzentren von Amazon wohnen. Die Firezone-Instanz in Bild 4 läuft in Mumbai (Region ap-south-1), und die Quelle der eigene IP-Pakete ist scheinbar irgendwo in Indien.

Die Webseite gibt keinen Hinweis darauf, aber unter der Haube sendet Firezone Telemetriedaten nach Hause. Der Hersteller begründet diesen Schritt auf der letzten Seite der Dokumentation damit, dass er erkennen möchte, welche Features am beliebtesten sind und wo es mal klemmt. Die Daten sind natürlich anonymisiert und stehen ausschließlich dem Entwicklerteam zur Verfügung.

Dennoch passt diese Form der Produktanalyse nicht zu jeder Sicherheitsrichtlinie. Dafür gibt es einen passenden Schalter für die Konfigurationsdatei, um die Sammelleidenschaft von Firezone zu beenden:

Rund ums Troubleshooting vereint Firezone alle Befehle unter dem Kommando firezone-ctl. Der Zusatz "tail" folgt der Logdatei und mit "status" prüft das System, ob die vier Komponenten Nginx, Phoenix, PostgreSQL und WireGuard einsatzbereit sind. Beim Aufruf ohne Option zeigt firezone-ctl sein vollständiges Repertoire.

Gibt die Webseite nur einen stummen 503-Fehler von sich, war die letzte Konfigurationsänderung fatal, denn der Dienst Phoenix läuft nicht mehr. In diesem Fall gilt es, die letzte Änderung an der Datei "firezone.rb" zu revidieren. Komplexer wird es, wenn die Modifikation über die Webseite erfolgte, beispielsweise beim Einrichten eines Identity Providers. Hier hilft es nur, die fehlerhafte Zeile aus der Tabelle "configurations" der PostgreSQL-Datenbank zu entfernen.

Falls die Anmeldung eines WireGuard- Clients klemmt, übergibt Firezone die Fehlersuche an WireGuard und seinen Allround- Befehl wg. Dieser stammt aus dem Paket wireguard-tools, das eventuell im lokalen System nicht installiert ist. Mit wg showconf legen Sie die vollständige Konfiguration offen. Die Kunst besteht nun darin, den richtigen Eintrag zu finden, denn die Liste der Tunnel ist nicht nach Anwender gruppiert. Am einfachsten lässt sich der Partner anhand der vergebenen IP-Adresse aufspüren, die bei "Allowed- IPs" gelistet ist. Hier gilt es zu prüfen, ob die Schlüsselpärchen zusammenpassen und der Pre-shared Key auf beiden Seiten identisch ist.

Firezone macht aus einem regulären Linux- Rechner einen WireGuard-VPN-Server für beliebig viele Benutzer. Dabei bringt Firezone noch ein paar zusätzliche Features mit, wie beispielsweise eine Benutzeranmeldung, die sich zur Multifaktor- Authentifizierung ausbauen lässt. Die Einarbeitung in Firezone verlangt nur einen geringen Lernaufwand. Die Web-GUI ist übersichtlich und eignet sich für das Tagesgeschäft: User und Geräte verwalten. Nur für die Ersteinrichtung der Software geht es bis auf die Kommandozeile. Wer das Werkzeug für viele User ausrollen möchte, kombiniert es mit einem Identity Provider und kann damit seine Nutzer im großen Stil per Self-Service mit Zugängen versorgen.