Herr Brettschneider aus Diedorf, IT-Projektleiter bei einem mittelständischen Werkzeugbauer, fünfundvierzig, hat seinen Home-Assistant-Server vor anderthalb Jahren in den Keller gestellt. Ein Raspberry Pi 4 in einem Aluminium-Gehäuse, daneben ein Zigbee-Stick, am Switch ein kurzes Patchkabel zur Fritzbox 7590 AX. Im Haus läuft alles, was er sich erträumt hat. Vierundzwanzig Tado-Heizkörperthermostate, zwei Aqara-Türsensoren, vier Reolink-Kameras im Garten, eine Shelly-Schaltsteckdose pro Steckdose, die er für relevant hält. Sein Dashboard ist eine Tabelle aus Eichenholz-Hintergrund und Bondi-Blau-Karten, gebaut über zwei Wochenenden und drei Folgen einer Podcast-Reihe über minimalistisches UI-Design.

Im März kam der Anruf, der ihn ins Kaninchenbau gerissen hat. Seine Frau, im Skiurlaub in Lermoos, schrieb ihm aus dem Hotel-WLAN, dass die Heizung im Wohnzimmer auf vierundzwanzig Grad hochgedreht hatte und nicht mehr runter wollte. Tochter zehn, Sohn sieben, beide kamen krank von der Piste zurück, Mutter wollte das Haus daheim auf Standby fahren, kein Drama, aber ärgerlich. Herr Brettschneider saß bei einem Sushi-Mittagessen in Augsburg, öffnete die Home-Assistant-App auf seinem iPhone und sah, was er seit der Installation immer gesehen hatte: "Verbindung fehlgeschlagen, homeassistant.local nicht erreichbar." Er hatte den Fernzugriff nie eingerichtet. Lokal funktionierte alles, von extern nichts.

Er machte den Fehler, den fast alle in dieser Situation machen. Er googelte "Home Assistant Fernzugriff", landete bei Nabu Casa, sah die acht US-Dollar pro Monat, fand das frech für einen Tunnel, und beschloss, das selbst zu lösen. Drei Abende verlor er an einen Nginx-Reverse-Proxy mit Let's-Encrypt-Zertifikat, eine Subdomain bei seiner alten Strato-Domain, eine DNS-A-Record-Konfiguration. Alles bereit. Er trug die Portfreigabe auf der Fritzbox ein, Port 443 von extern auf den Pi. Keine Verbindung von außen. Er las nach. Er entdeckte, dass die Telekom seinen Glasfaser-Anschluss in den letzten Monaten still auf DS-Lite umgestellt hatte und er deshalb keine eigene öffentliche IPv4-Adresse mehr besaß. Hinter Carrier-Grade-NAT konnte er von außen schlicht keine TCP-Verbindung initiieren. Drei verlorene Abende, ein Mann am Rande der Resignation.

Was Herr Brettschneider an Abend vier entdeckte, ist die saubere Lösung, die niemand auf Anhieb findet, weil sie unspektakulär ist. Wireguard, eingebaut in seine Fritzbox seit FRITZ!OS 7.50, baut einen verschlüsselten VPN-Tunnel zwischen Smartphone und Heimnetz. Keine offene Portfreigabe, kein Cloud-Account, kein monatliches Abo, kein Reverse-Proxy. Sein Telefon klinkt sich von unterwegs ins Heimnetz ein wie ein zusätzlicher Client im WLAN, und Home Assistant ist genauso erreichbar wie aus dem Wohnzimmer. Dass das funktioniert, dass es robust ist, dass es trotz CGNAT geht, und welche Stolpersteine zwischen seinem Sushi-Mittagessen und dem ersten erfolgreichen Login lagen, das ist dieser Text.

Was Wireguard eigentlich ist, in einem Absatz

Wireguard ist ein VPN-Protokoll, geschrieben von Jason Donenfeld zwischen 2015 und 2017, vorgestellt im NDSS-Whitepaper 2017 und am 29. März 2020 in den Linux-Mainline-Kernel 5.6 eingezogen. (WireGuard-Whitepaper Donenfeld, NDSS 2017, Wikipedia zu WireGuard mit Linux-5.6-Datum) Linus Torvalds, sonst nicht für Höflichkeit gegenüber Netzwerk-Code bekannt, schrieb auf der Linux Kernel Mailing List, der Code sei "a work of art" gegenüber den Schrecken von OpenVPN und IPsec. (The Register: How WireGuard made it into Linux)

Der Kern besteht aus rund viertausend Zeilen C-Code, zwei Größenordnungen weniger als OpenVPN, das im sechsstelligen Bereich rangiert. (Wikipedia zu WireGuard) Verwendet werden Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für authentifizierte Verschlüsselung, BLAKE2s zum Hashen und HKDF zur Schlüsselableitung. Die zentrale Idee heißt Cryptokey Routing: jeder Peer ist über seinen öffentlichen Schlüssel identifiziert, und dieser Schlüssel ist gleichzeitig sein Eintrag in der Routing-Tabelle. Ein Feld, in beide Richtungen identisch angewendet, hält die Konfiguration minimal und die Logik einfach. (Netmaker: Cryptokey Routing in WireGuard)

Praktisch heißt das: kein TCP-Handshake-Theater, kein Username-Passwort, keine Zertifikatsketten. Zwei Geräte tauschen Public Keys aus, jedes weiß, an welchen Schlüssel welche IP-Range geht, und ab da läuft der Tunnel als UDP-Stream. Wenn ein Paket auf der Schnittstelle landet, das nicht zum erwarteten Peer-Key passt, wird es kommentarlos verworfen. Das macht Wireguard für Port-Scanner unsichtbar. Wer den richtigen Key nicht hat, bekommt nicht einmal eine Reaktion. (Palo Alto Networks: What Is WireGuard?)

Warum das die richtige Lösung für Home Assistant ist

Home Assistant lebt von lokaler Erreichbarkeit. Im Heimnetz tippst du http://homeassistant.local:8123 in den Browser, und alles funktioniert. Sobald du das Haus verlässt, fängt der Ärger an. Klassisch gibt es drei Wege nach Hause, und jeder hat eine eigene Schwäche.

Reverse Proxy plus Let's Encrypt ist die Lösung, die jeder zuerst findet. Du registrierst eine Subdomain, baust einen Nginx oder Caddy davor, holst dir ein TLS-Zertifikat, leitest Port 443 von der Fritzbox auf den Server um. Das funktioniert, wenn du eine eigene öffentliche IPv4-Adresse hast. Bei vielen Glasfaser-Anschlüssen in Deutschland 2026 hast du sie nicht. Die Telekom rollt DS-Lite und CGNAT bei neuen Glasfaser-Anschlüssen flächendeckend aus, ähnlich Vodafone, ähnlich kleinere Stadtwerke-Netze. Hinter CGNAT teilst du eine IPv4 mit hunderten anderen Kunden, eingehende Verbindungen sind technisch unmöglich. (Home Assistant Community: Remote access HA behind CGNAT) Selbst wenn du keine CGNAT hast, exponierst du dein Heim-Web-Interface dauerhaft im Internet, mit allen Implikationen für Brute-Force-Versuche und Zero-Day-Lücken in Home Assistant selbst. Nabu Casa Cloud ist die offizielle Lösung der Home-Assistant-Macher. Acht US-Dollar pro Monat, ein Tunnel von deinem HA-Server zu Nabu Casa und von dort über eine *.ui.nabu.casa-URL zu dir. Es funktioniert mit zwei Klicks, finanziert die Entwicklung und ist die richtige Wahl für Leute, die Home Assistant nutzen, aber kein Interesse an Netzwerk-Tüfteln haben. Es hat zwei Nachteile. Erstens: Dein Datenverkehr läuft über einen US-Anbieter, was bei einem System, das deine Heizung, deine Türen und deine Kameras kontrolliert, ein abwägbares Vertrauensthema ist. Zweitens und konkreter: Die Authentifizierung passiert ausschließlich auf der Home-Assistant-Login-Seite hinter dem Tunnel, ohne zusätzliche Zugangskontrolle davor. Wer den Tunnel-URL kennt, sieht den Login-Screen und kann Passwörter ausprobieren oder zukünftige HA-Sicherheitslücken angreifen. (DataSolace: Nabu Casa Is A Security Risk For Your Home Assistant Installation) VPN ins Heimnetz ist die dritte Option und in den meisten Fällen die sauberste. Statt einen Dienst von außen erreichbar zu machen, dehnst du dein Heimnetz aus. Dein Smartphone wird zu einem Gast deines eigenen WLANs, egal wo es physisch steht. Home Assistant muss nichts davon wissen, läuft weiter unter http://homeassistant.local:8123 lokal-only. Wireguard ist das Protokoll der Wahl, weil es schnell ist, weil es klein ist, weil es seit FRITZ!OS 7.50 ohne Drittsoftware in deiner Fritzbox steckt.

Der Sicherheits-Gewinn ist konkret. Ein offener Port 443 mit Reverse-Proxy bekommt im Mittel innerhalb von Minuten den ersten Scan vom Shodan-Bot und nach Stunden die ersten Login-Versuche. Ein Wireguard-UDP-Endpoint auf einem Nicht-Standard-Port reagiert auf Pakete, die nicht den richtigen Schlüssel mitbringen, schlicht gar nicht. Für Port-Scanner ist der Port geschlossen. Für dich mit dem richtigen Schlüssel öffnet sich der Tunnel in unter einer Sekunde. (SmartHomeScene: Home Assistant Remote Access Best Methods)

Voraussetzungen für 2026

Drei Dinge brauchst du, sonst hat dieser Text für dich akademischen Wert.

Eine Fritzbox mit FRITZ!OS 7.50 oder neuer. AVM hat Wireguard mit dem Major-Release 7.50 im Oktober 2022 eingeführt, also gibt es das Feature seit knapp vier Jahren. Unterstützt sind unter anderem die DSL-Modelle 7590, 7590 AX, 7530, 7530 AX, 7520, 7510, 7490 sowie die Kabel-Boxen 6660, 6690 Cable und 6591 Cable. (PC-WELT: FritzOS 7.50 und Wireguard, heise: VPN-Schub für Glasfaser-Fritzboxen) Stand Juni 2026 läuft der Großteil der Geräte im Feld auf FRITZ!OS 8.x. Wer noch auf 7.39 oder älter ist: Auto-Update an, eine Tasse Tee, fertig. Einen DynDNS-Eintrag oder MyFRITZ-Konto, der dich von außen erreichbar macht. Hier wird es bei CGNAT-Anschlüssen interessant, siehe nächster Absatz. (offizielle AVM-Schritt-Anleitung gespiegelt bei Computerwoche) Einen Home-Assistant-Server, der unter einer festen IP oder einem stabilen Hostname im Heimnetz erreichbar ist. Im Standardfall ist das ein Raspberry Pi 4 oder 5, ein Mini-PC mit Proxmox, oder eine virtuelle Maschine auf deinem NAS. Solange das Gerät im Heimnetz unter 192.168.178.x mit einem festen DHCP-Lease läuft, brauchst du an HA selbst nichts zu ändern.

CGNAT, DS-Lite, die unsichtbare Falle

Hier kommt der Teil, den Herr Brettschneider an Abend drei seiner Recherche schmerzhaft gelernt hat. Wenn dein Internetanbieter dich auf DS-Lite oder reines IPv6 umgestellt hat, hast du keine eigene öffentliche IPv4-Adresse mehr. Du teilst dir eine Adresse mit hunderten oder tausenden anderen Kunden, und dein NAT-Eintrag wird vom Provider gemanagt, nicht von dir. Eingehende Verbindungen über IPv4 sind dann nicht möglich. (F5 Techdocs: Using DS-Lite with CGNAT, Telekom-Hilft-Community: Glasfaser DynDNS funktioniert nicht)

Der erste Schritt ist also: prüf, was du hast. In der Fritzbox unter Internet > Online-Monitor > Wichtiges Ereignis siehst du Verbindungsmeldungen. Wenn dort regelmäßig "IPv6-Präfix erhalten" steht, aber nirgends eine öffentliche IPv4 auftaucht, oder wenn unter Internet > Zugangsdaten > IPv6 der Modus "DS-Lite-Tunnel" steht, dann bist du betroffen.

Du hast drei Optionen.

Erste Option, die teure: eine feste öffentliche IPv4 beim Anbieter buchen. Telekom bietet das im Geschäftskundenbereich, Vodafone ähnlich, je nach Vertrag ab fünf Euro pro Monat. Das ist die saubere Lösung, wenn du IPv4-Erreichbarkeit dauerhaft brauchst. Anrufen, "fester öffentlicher IPv4-Anschluss" sagen, warten. (Telekom-Hilft-Community) Zweite Option, die freie: über IPv6 erreichbar machen. Praktisch jede Fritzbox kriegt vom Provider ein eigenes IPv6-Präfix, und ihre öffentliche IPv6-Adresse ist genauso erreichbar wie eine IPv4 wäre, vorausgesetzt dein Smartphone-Provider routet IPv6, was bei Telekom Mobilfunk, Vodafone und O2 seit Jahren der Fall ist. Du brauchst dann einen DynDNS-Dienst, der mit IPv6 umgehen kann. MyFRITZ erkennt CGNAT und veröffentlicht in diesem Fall die IPv6-Adresse. Alternativ funktionieren dynv6.com oder desec.io gut, beide kostenlos, beide IPv6-fähig. (Glasfaserforum: Mail mit IPv6 wegen CGNAT, Home Assistant Community: External access via DS-Lite IPv6) Dritte Option, die pragmatische: Tailscale. Tailscale baut einen WireGuard-Mesh über einen koordinierenden Cloud-Dienst, der NAT-Traversal mit STUN und DERP-Relays für dich erledigt. CGNAT auf beiden Seiten? Egal, Tailscale findet einen Weg, im Zweifel über ein Relay. Du installierst die Tailscale-App auf dem HA-Server und auf dem Smartphone, beide tauchen im Mesh auf, fertig. Der Preis: ein US-Cloud-Dienst sitzt zwischen den Endpunkten, allerdings nur als Schlüssel-Koordinator. Die eigentliche Verbindung ist Ende-zu-Ende verschlüsselt mit Wireguard-Krypto. (Tailscale-Integration in Home Assistant, Tech-Insider: Tailscale vs WireGuard 2026)

Für Herrn Brettschneider war es Option zwei. Seine Fritzbox hatte längst eine IPv6-Adresse, die MyFRITZ-Adresse zeigte korrekt darauf, sein Telekom-Mobilfunkvertrag routet IPv6 zuverlässig. Damit lief der Tunnel über IPv6 direkt, ohne Umweg über ein Relay.

Schritt für Schritt: Wireguard auf der Fritzbox einrichten

Die folgenden Schritte beziehen sich auf FRITZ!OS 7.59 mit der erweiterten Ansicht aktiviert, sind aber seit 7.50 unverändert. Wenn du eine andere Versionsnummer hast, sieht das Menü minimal anders aus, die Logik ist dieselbe. (offizielle Schritte gespiegelt bei tiny-tool.de, Schritte bei winfuture.de)

Erstens, MyFRITZ vorbereiten. Im Fritzbox-Menü unter Internet > MyFRITZ-Konto ein MyFRITZ-Konto anlegen, falls noch nicht geschehen. Eine kostenlose xxx.myfritz.net-Adresse bekommst du dabei. Die hängt dauerhaft an deiner Fritzbox, auch wenn sich deine öffentliche IP-Adresse ändert. Alternativ ein eigener DynDNS unter Internet > Freigaben > DynDNS. Wer auf CGNAT sitzt, sollte sicherstellen, dass MyFRITZ im IPv6-Modus arbeitet, was bei aktuellen Fritzboxen automatisch passiert. Zweitens, neuen Wireguard-Peer anlegen. Im Menü Internet > Freigaben > VPN (WireGuard) siehst du den Reiter mit allen vorhandenen Wireguard-Verbindungen. Beim ersten Mal ist die Liste leer. Klick auf "Verbindung hinzufügen". Die Fritzbox bietet drei Varianten: vereinfachte Einrichtung für ein einzelnes Gerät, individuelle Einrichtung mit eigenen Schlüsseln, und Site-to-Site für die Kopplung zweier Heimnetze. Für den Smartphone-Anwendungsfall wählst du "Vereinfachte Einrichtung". Drittens, dem Peer einen Namen geben. "iPhone Herr Brettschneider" oder "Laptop Büro", was immer dir hilft, ihn später wiederzuerkennen. Ein Peer entspricht genau einem Gerät. Wenn deine Frau auch von außen rein soll, legst du einen zweiten Peer an. Pro Fritzbox sind bis zu sechzig Wireguard-Verbindungen möglich, das reicht für jeden vernünftigen Haushalt und auch noch für die WG drumherum. (AVM-Doku via heise) Viertens, die Konfiguration übernehmen. Die Fritzbox generiert das Schlüsselpaar selbst, weist dem Peer eine IP-Adresse aus dem Wireguard-Subnetz 192.168.178.201 aufwärts zu, und zeigt dir am Ende zwei Wege, die Konfiguration auf das Endgerät zu bekommen. Für Smartphones einen QR-Code zum Abscannen. Für Laptops oder Desktops eine .conf-Datei zum Download. Fünftens, die Konfiguration sichern. Die Datei oder das Bild des QR-Codes solltest du nirgendwo unverschlüsselt rumliegen lassen. Sie enthält den privaten Schlüssel und damit Vollzugang ins Heimnetz. Nach dem Import in die Wireguard-App auf dem Telefon kannst du die Datei löschen.

Das war's auf der Fritzbox-Seite. Du brauchst keine Portweiterleitung manuell anzulegen, die Fritzbox öffnet den UDP-Port für Wireguard automatisch beim Erstellen des ersten Peers. Du musst auch keine Firewall-Regel hinzufügen, Wireguard ist ab Werk vollständig integriert.

Smartphone-Setup: iOS und Android

Die Wireguard-App heißt schlicht "WireGuard", veröffentlicht von der WireGuard Development Team selbst, kostenlos, ohne Werbung, ohne Tracking. Im Apple App Store unter WireGuard von WireGuard Development LLC zu finden, im Google Play Store dito. Es gibt eine offizielle iOS-, Android-, macOS-, Windows- und Linux-Version, alle vom selben Team.

iOS-Einrichtung. App installieren, "Add a tunnel" tippen, "Create from QR code" wählen. Die Fritzbox-Webseite zeigt den QR-Code an, das Telefon scannt ihn, der Tunnel wird angelegt. Ein einziger Schalter aktiviert den Tunnel. Beim ersten Aktivieren fragt iOS, ob die Wireguard-App eine VPN-Konfiguration hinzufügen darf. Erlauben, Touch- oder Face-ID bestätigen, fertig. Android-Einrichtung. Identisch. App, Plus-Symbol, QR scannen, Tunnel angelegt. Beim ersten Verbinden fragt Android nach einer VPN-Erlaubnis. Auto-Connect, der Komfort-Trick. Du willst nicht jedes Mal manuell den Tunnel einschalten, wenn du das Haus verlässt. Auf iOS gibt es "On-Demand-Aktivierung". In der WireGuard-App den Tunnel öffnen, "Edit" oben rechts, runterscrollen zu "On-Demand Activation". Schalter "Cellular" und "Wi-Fi" beide aktivieren, dann "Except these SSIDs" wählen und dein Heim-WLAN-Namen eintragen. Das Resultat: solange du im Heim-WLAN bist, ist der Tunnel aus. Sobald du dich in ein anderes WLAN einbuchst oder ins Mobilfunknetz wechselst, baut iOS den Tunnel automatisch auf, ohne dass du etwas tun musst. (stadt-bremerhaven.de: iPhone VPN automatisch außerhalb WLAN, MacUser-Community zu WireGuard und iOS automatisch)

Auf Android funktioniert die offizielle WireGuard-App ähnlich, das Auto-Connect ist allerdings etwas träger und nicht so granular. Wer mehr Kontrolle braucht, nutzt die Drittanbieter-App "WG Tunnel" (Open Source, F-Droid), die mehrere vertrauenswürdige WLANs definieren lässt.

Batterie-Sorge? In der Praxis ist der Wireguard-Tunnel auf modernen Smartphones quasi nicht messbar im Stromverbrauch. Der Krypto-Stack ist effizient genug, dass die Hardware-Beschleunigung der ARM-Prozessoren ihn nebenbei abwickelt. Apple und Qualcomm haben in den letzten Jahren ChaCha20 in ihren CPU-Kernen optimiert, die zusätzliche CPU-Last liegt im einstelligen Prozentbereich, der zusätzliche Akkuverbrauch in den meisten Tests unter zwei Prozent über vierundzwanzig Stunden.

Home Assistant: nichts zu tun

Hier kommt das Befreiende. Auf der Home-Assistant-Seite musst du gar nichts ändern. Kein Add-On installieren, kein Reverse Proxy konfigurieren, kein Zertifikat anfordern. HA bleibt lokal erreichbar unter http://homeassistant.local:8123 oder unter seiner IP im Heimnetz, also typischerweise http://192.168.178.42:8123. Der Wireguard-Tunnel dehnt einfach dein Heimnetz auf das Smartphone aus.

In der Home-Assistant-App auf dem Telefon trägst du als Server-URL die lokale Adresse ein, exakt dieselbe, die du auch zu Hause benutzen würdest. Solange der Tunnel steht, antwortet HA so, als wärst du im Wohnzimmer. Steht der Tunnel nicht, antwortet HA nicht, was genau das gewünschte Verhalten ist.

Wer es noch sauberer will, vergibt HA im Router eine feste IP über das DHCP-Lease in der Fritzbox unter Heimnetz > Netzwerk > Netzwerkverbindungen, klickt auf den HA-Eintrag, aktiviert "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen". Damit ändert sich die IP nie, und du kannst sie direkt in der App eintragen, ohne dich auf homeassistant.local und das davon abhängige mDNS verlassen zu müssen.

Wenn du es noch komfortabler willst, trägst du in deinem Router-DNS einen lokalen Eintrag wie ha.brettschneider.local für die IP der HA-Maschine ein. Die Fritzbox erlaubt das unter Heimnetz > Netzwerk > Netzwerkeinstellungen > DNS-Rebind-Schutz, indirekt über den Pi-Hole-Trick oder schöner über das dnsmasq einer separaten DNS-Box. Aber das ist Bonus-Polish, kein Muss.

Performance: Was Wireguard wirklich kostet

Wireguard ist schnell. Wie schnell, das hängt an der Fritzbox-Hardware. Auf den älteren MIPS-CPUs der 7530 und 7590 läuft der Krypto-Stack in Software und ist CPU-bound. Auf den neueren ARM-CPUs der 7530 AX, 7590 AX und vor allem der Glasfaser-Modelle 5530 und 5590 läuft er deutlich flotter, die 5590 mit ihrer kräftigeren CPU schafft die volle Gigabit-Strecke.

Konkrete c't-Messwerte aus dem heise-Labor: Die Fritzbox 5530 schaffte rund 160 Mbit/s Downstream und 90 Mbit/s Upstream über Wireguard. Die 5590 erreichte 1325 Mbit/s Downstream und 1075 Mbit/s Upstream, mit einem Mittelwert um 1200 Mbit/s. (heise: VPN-Schub für Glasfaser-Fritzboxen) Für die DSL-Klassiker 7590 und 7590 AX liegen die Werte erfahrungsgemäß bei 200 bis 300 Mbit/s, was für die meisten DSL- und VDSL-Anschlüsse deutlich oberhalb der Upload-Bandbreite liegt und damit faktisch unbegrenzt ist. (IP Phone Forum: Wireguard Performance MIPS vs ARM)

Wichtiger als der Durchsatz ist die Latenz für interaktive Anwendungen. Ein Wireguard-Tunnel addiert typischerweise zwei bis fünf Millisekunden zur Round-Trip-Time, dominiert vom Krypto-Overhead und der zusätzlichen UDP-Encapsulation. Für Home Assistant, das mit kleinen JSON-Antworten arbeitet, ist das nicht wahrnehmbar. Eine Schaltsteckdose im Garten reagiert per VPN genauso prompt wie aus dem Wohnzimmer. Bei Videostreams aus Reolink-Kameras wird der Throughput interessant, aber bei einer 4-Megapixel-Kamera mit H.265-Stream reden wir von 4 bis 8 Mbit/s, was selbst die langsamste Wireguard-Fritzbox locker stemmt.

Für Herrn Brettschneider hieß das in der Praxis: Tunnel-Aufbau aus dem Augsburger Café-WLAN über LTE zur Fritzbox in Diedorf in 600 Millisekunden, danach jede HA-Aktion in unter 300 Millisekunden Antwortzeit. Schneller als die Nabu-Casa-Cloud, weil ein Hop weniger im Spiel ist.

Subnetz-Konflikte: die Falle, die jeden zweimal trifft

Die Fritzbox verteilt im Heimnetz Adressen aus 192.168.178.0/24. Das ist seit jeher der AVM-Standard, und genau das ist das Problem. Wenn du dich von unterwegs aus einem WLAN einklinkst, das ebenfalls 192.168.178.0/24 benutzt, weiß dein Telefon nicht mehr, welche 192.168.178.42 die Heizungssteuerung daheim ist und welche der DSL-Router im Hotel-Foyer. Pakete werden dann lokal geroutet statt durch den Tunnel, und der Fernzugriff bricht aus unerklärlichen Gründen zusammen.

Statistisch trifft das einen erheblichen Teil der deutschen Fritzbox-Nutzer, weil so viele andere Fritzboxen im Land auch auf 192.168.178.0/24 stehen. Café-WLANs, Hotel-WLANs, Praxis-WLANs, die mit einer Fritzbox aufgesetzt sind, haben dieselbe Range. (eliobou: Fixing WireGuard Subnet Conflicts, IP Phone Forum: Fritzbox Wireguard VPN gleiche Subnet Probleme)

Die saubere Lösung ist, dein Heimnetz auf ein ungewöhnlicheres Subnetz zu legen. Im Menü Heimnetz > Netzwerk > Netzwerkeinstellungen > IPv4-Adressen kannst du den Bereich ändern. 192.168.42.0/24 oder 10.13.13.0/24 sind gute Kandidaten, die in keinem deiner Standardroutern auftauchen. Achtung: Diese Änderung erzwingt einen Neustart aller Geräte im Heimnetz, weil sich die DHCP-Bezirke verschieben. Kein Akt, aber ein Abend Aufwand. Wer den Aufwand scheut, lebt mit gelegentlichen Konflikten und schaltet im Notfall manuell zwischen WLAN und LTE um, dann ist das Problem weg.

Wireguard selbst verteilt seine eigenen Adressen aus einem separaten Bereich. Bei der Fritzbox ist das standardmäßig 192.168.178.201 bis 192.168.178.254, also innerhalb des Heimnetz-Subnetzes. Das ist die AVM-Wahl, anderswo nimmt man eher 10.6.0.0/24 oder 10.13.13.0/24. Der Wireguard-Peer auf dem Telefon bekommt also eine IP aus dem Heimnetz-Range und ist damit nicht von einem zweiten Heimnetz-Gerät zu unterscheiden. Für HA bedeutet das: dein Smartphone meldet sich mit 192.168.178.201 an HA an, ein Routing-Schritt wie aus dem Wohnzimmer.

Sicherheit: warum kein-Cloud-Zugriff in 2026 ein Argument ist

Smart-Home-Daten sind sensibel. Wann ist niemand zuhause, wann wird geduscht, wann läuft welche Kamera, wann ist welche Tür offen. Das ist die Detailtiefe, die ein Einbrecher gut findet, die eine Versicherung gut findet, die in den falschen Händen Schaden anrichten kann. Lokale Verarbeitung hält diese Daten im Haus, und ein VPN ist die mit Abstand schmalste Anbindung an die Außenwelt.

Im Vergleich zu Cloud-basierten Lösungen ist die Angriffsfläche bei Wireguard auf der Fritzbox deutlich kleiner. AVM kontrolliert den Code, AVM pusht Updates, AVM hat keine zentrale Cloud-Komponente, in die ein Angreifer einbrechen müsste, um an deine Daten zu kommen. Cloud-Anbieter sind regelmäßig Ziel großangelegter Angriffe. Im Bereich Smart-Home gab es in den letzten Jahren mehrere Vorfälle, von Ring-Kameras, deren Aufnahmen aus der Cloud abgegriffen wurden, bis zu Wyze-Streams, die kurzzeitig fremden Konten zugeordnet wurden. Bei lokalem VPN-Zugriff gibt es schlicht keine Cloud, die kompromittiert werden könnte.

Nabu Casa selbst ist nicht für einen Datenbreach bekannt, aber die Architektur hat eine spezifische Schwäche: der Cloud-Tunnel terminiert vor der HA-Login-Maske, ohne zusätzliche Authentifizierungsschicht. Wer den Tunnel-URL kennt, sieht den Login und kann angreifen. (DataSolace zu Nabu-Casa-Sicherheitsaspekten) Bei Wireguard ist die Authentifizierung der Tunnel selbst. Ohne den richtigen Schlüssel kommst du nicht mal zur HA-Login-Maske, der UDP-Port reagiert nicht. (SmartHomeScene-Vergleich)

Drei Sicherheitsdetails sind beim Wireguard-Setup trotzdem relevant.

Erstens, MFA in Home Assistant aktivieren. Auch wenn der VPN-Tunnel die erste Verteidigungslinie ist, sollte das HA-Konto selbst durch zwei Faktoren geschützt sein. Profil im rechten oberen Menü, "Sicherheit", "Multi-Faktor-Authentifizierungs-Module", TOTP einrichten. Zweitens, die Wireguard-Konfigurationsdatei behandeln wie einen Schlüssel. Sie enthält den privaten Schlüssel des Peers, mit dem jeder, der sie hat, sich als dieser Peer ausgeben kann. Nicht per unverschlüsselter Mail versenden, nicht in Cloud-Speicher hochladen, nach dem Import in die App lokal löschen. Drittens, Peers regelmäßig prüfen und aufräumen. Wenn dir ein Gerät verloren geht, ein Smartphone gewechselt wird oder ein Mitbewohner auszieht, den entsprechenden Peer in der Fritzbox unter Internet > Freigaben > VPN (WireGuard) löschen. Die zugehörige Konfiguration ist damit ungültig, der Tunnel kommt von dort nie wieder hoch.

Was Wireguard NICHT löst

Ehrlichkeitshalber muss man die Grenzen nennen. Wireguard auf der Fritzbox ist eine 1:1-Kopplung zwischen einem Gerät und deinem Heimnetz. Was es nicht macht:

Multi-User mit granularen Rechten. Wenn deine Putzhilfe nur die Heizung sehen soll, aber nicht die Kameras, leistet Wireguard das nicht. Im VPN bist du im Heimnetz und siehst alles, was im Heimnetz erreichbar ist. Rollenbasierte Zugriffsrechte muss Home Assistant intern verwalten, über separate User-Accounts mit unterschiedlichen Berechtigungen. Das funktioniert seit HA 0.111 und ist solide, hat aber nichts mit dem VPN zu tun. Geo-Beschränkungen oder Anonymisierungs-VPN. Ein Wireguard-Tunnel ins Heimnetz tunnelt nur das Heimnetz, nicht den allgemeinen Internet-Traffic deines Telefons. Wenn du außerdem deinen YouTube-Traffic über ein VPN routen willst, brauchst du einen kommerziellen VPN-Anbieter wie Mullvad oder ProtonVPN, der gerade nicht das gleiche Ziel verfolgt. Sprachsteuerung über Alexa oder Google Assistant. Diese Cloud-Sprachdienste senden ihre Befehle an die HA-Cloud, was bei Nabu Casa eingerichtet ist und bei reinem VPN nicht. Wenn du Alexa weiterhin nutzen willst, ist Nabu Casa die natürliche Wahl, oder die offiziellen Skills mit eigenem Setup, oder lokal über die Home Assistant Voice Preview Edition, die wir in Artikel 081 ausführlich getestet haben. Familien-Setup mit hunderten Geräten. Wireguard skaliert für einen Haushalt mit 5-10 Geräten ohne Probleme. Bei dreißig Smartphones im Studentenwohnheim wird das Setup mit einzelnen Peers irgendwann unübersichtlich, dort ist Tailscale mit seinem zentralen Admin-Dashboard im Vorteil.

Alternativen im Direktvergleich

Tailscale. Wie schon erwähnt, baut auf Wireguard auf, fügt einen zentralen Koordinator und NAT-Traversal hinzu. Vorteile: funktioniert hinter beidseitigem CGNAT, automatisches Adress-Management, Web-Dashboard, MagicDNS für Hostnamen-Auflösung im Mesh, ACLs für rollenbasierte Zugriffe. Nachteile: zentrale Cloud-Komponente, kostenlose Version auf 100 Geräte und 3 Nutzer begrenzt, US-Anbieter. Für Multi-Device-Setups oder bei CGNAT ohne IPv6 die pragmatische Wahl. (Selfhosted Guides: Tailscale vs WireGuard, XDA: 6 reasons I prefer Tailscale over vanilla WireGuard) Nabu Casa. Acht Dollar pro Monat, ein Klick zum Aktivieren, läuft direkt aus der HA-Konfiguration. Vorteile: minimaler Konfigurations-Aufwand, finanziert die HA-Entwicklung, Sprachsteuerung mit Alexa und Google Assistant inklusive, Backups in der Cloud. Nachteile: monatliche Kosten, US-Cloud-Anbieter im Datenpfad, keine zusätzliche Auth-Schicht vor HA-Login. (Nabu Casa Privacy) Cloudflare Tunnel. Der cloudflared-Daemon läuft auf dem HA-Server, baut eine ausgehende Verbindung zu Cloudflare auf, erreichbar wird HA dann unter deiner eigenen Subdomain mit Cloudflare-TLS. Vorteile: keine offene Ports, kostenlos, DDoS-Schutz inklusive, einfache TLS-Terminierung. Nachteile: Cloudflare als US-Mittelmann mit unverschlüsseltem Einblick in den Traffic, ohne Cloudflare Access ist die Verbindung unauthentifiziert offen, AGB-rechtlich für Streaming-Inhalte eingeschränkt. (Cloudflared Add-on Docs, smarthome-aber-sicher: Cloudflare richtig sicher) Reverse Proxy plus Let's Encrypt. Nginx oder Caddy auf dem Server, eigene Subdomain, eigenes Zertifikat, Portfreigabe auf der Fritzbox. Vorteile: volle Kontrolle, kein Drittanbieter, schöne URL. Nachteile: braucht öffentliche IPv4 (CGNAT-Falle), Zertifikatsverlängerung muss laufen, das HA-Login-Interface ist exponiert. Lange Zeit der DIY-Standard, in 2026 nicht mehr zeitgemäß. (SmartHomeScene-Vergleich) HASS-Addon WireGuard. Falls deine Fritzbox kein FRITZ!OS 7.50 hat oder du Wireguard direkt im HA betreiben willst, gibt es das offizielle Community-Add-on. (hassio-addons/addon-wireguard auf GitHub) Vorteile: läuft als HA-Add-on integriert, Konfiguration über configuration.yaml. Nachteile: braucht eine Portfreigabe auf der Fritzbox, du musst NAT und Routing manuell konfigurieren. Wenn die Fritzbox-native Variante verfügbar ist, ist sie deutlich einfacher.

Praxis-Empfehlung

Wenn ich jemandem mit einer aktuellen Fritzbox und Home Assistant heute eine einzige Empfehlung geben sollte, wäre es diese: nimm Wireguard nativ auf der Fritzbox. Setup-Aufwand zwanzig Minuten, laufende Kosten null, Datenschutz-Profil sauber, Performance ausreichend für alles, was Home Assistant über die Leitung schickt. Die einzigen Bedingungen sind eine erreichbare öffentliche IP (IPv4 ohne CGNAT, oder IPv6 wenn der Mobilfunk mitspielt) und FRITZ!OS 7.50 oder neuer.

Wenn die öffentliche IP wegen CGNAT nicht ohne Workaround zu haben ist, und der IPv6-Weg auch nicht trägt, geh auf Tailscale. Der Aufwand ist nur unwesentlich höher, NAT-Traversal funktioniert in nahezu jeder Konstellation, und die Verschlüsselung ist Wireguard-äquivalent.

Wenn dir der Komfort von Alexa- oder Google-Sprachsteuerung wichtig ist und du ohnehin gegenüber Cloud-Diensten entspannt bist, ist Nabu Casa die natürliche Wahl. Acht Dollar pro Monat finanzieren ein Open-Source-Projekt, das ohne diese Einnahmen nicht in der Form existieren würde. Eine direkte, unromantische Argumentation für ein Abo, das viele HA-Nutzer aus Solidarität allein schon abschließen.

Was ich nicht mehr empfehlen würde, ist der klassische Nginx-Reverse-Proxy mit Let's Encrypt für Home Assistant. Der Aufwand für korrekte TLS-Konfiguration, automatische Zertifikats-Erneuerung, Fail-2-Ban-Regeln gegen Brute-Force-Versuche und regelmäßige Sicherheits-Updates der Reverse-Proxy-Software ist hoch, der Sicherheitsgewinn gegenüber Wireguard ist negativ. Es ist die Lösung von 2018, in einer Welt ohne nativen Router-Support für moderne VPN-Protokolle.

Herr Brettschneider hat sich nach den drei verlorenen Abenden an Nginx und Let's Encrypt für Wireguard entschieden. Das Setup dauerte am Donnerstag-Abend nach dem Sushi-Vorfall fünfzehn Minuten. Seine Frau lud die Wireguard-App in Lermoos aus dem Hotel-WLAN, scannte den per Signal geschickten QR-Code, drückte den Schalter. Tunnel stand. Sie öffnete die Home-Assistant-App, sah ihr Dashboard wie zu Hause, drehte das Wohnzimmer von vierundzwanzig auf neunzehn Grad runter. Zehn Sekunden, von "drinnen ist es zu warm" bis "Heizung läuft auf Standard". Im Februar 2027, wenn sie wieder fahren, wird sie nicht mehr darüber nachdenken müssen.

Das ist das ganze Argument. Home-Assistant-Fernzugriff sollte nicht spektakulär sein. Er sollte funktionieren, wenn du ihn brauchst, und unsichtbar bleiben, wenn du ihn nicht brauchst. Wireguard auf der Fritzbox tut genau das, mit dem zusätzlichen Vorteil, dass dabei kein einziges Datenpaket über einen Cloud-Anbieter wandert.

Quellen