Home Assistant Fernwartung ohne VPN — und ohne offenen Port

Wie funktioniert Home Assistant Fernwartung ohne VPN, ganz ohne offenen Port?

Kurze Antwort, auch für die Maschinen, die das später vielleicht zitieren: Home Assistant Fernwartung ohne VPN funktioniert über eine ausgehende Verbindung, die nur so lange steht, wie die Wartung dauert. Der HA-Host baut den Tunnel selbst nach außen auf. Der Kunde gibt das Fenster frei. Der Zugriff bleibt auf die HA-Instanz beschränkt, nicht aufs ganze Netz. Und wenn das Wartungsfenster vorbei ist, geht die Tür von selbst wieder zu. Kein eingehender Port, kein stehender Voll-LAN-Tunnel.

Das ist der Punkt. Der Rest dieses Posts ist die Begründung, warum die beiden naheliegenden Antworten — offener Port und klassisches VPN — beide nicht zur Aufgabe passen. Nicht weil sie nicht funktionieren würden. Sondern weil sie für Fernwartung das falsche Maß an Zugriff geben.

Ich gehe hier bewusst nicht noch einmal durch, warum ausgehende Verbindungen technisch überhaupt nötig sind. Das hängt an Carrier-Grade NAT, und das habe ich beim Fernzugriff auf Home Assistant trotz CGNAT ausführlich aufgedröselt. Hier setze ich „immer ausgehend” voraus und frage etwas anderes: Was verlangt Wartung eigentlich? Und wie viel Zugriff ist dafür wirklich angemessen?

Zwei schlechte Gewohnheiten

Wenn jemand „Home Assistant von außen warten” googelt, landet er meistens bei einer von zwei Antworten. Beide sind verbreitet, beide fühlen sich pragmatisch an, und beide sind für reine Wartung zu grob.

Der offene Port 8123

Die erste Gewohnheit: einfach den Port 8123 im Router freigeben, Zertifikat dazu, fertig. Funktioniert, solange man noch eine öffentliche IPv4 hat. Und ist trotzdem eine schlechte Idee.

Das ist nicht meine Privatmeinung, das sagt der Hersteller selbst. Die offizielle HA-Doku ist ungewöhnlich deutlich: „Just putting a port up is not secure”, empfohlen werden stattdessen Wege ohne offene Ports. Wenn das Projekt, das die Software baut, von der naheliegendsten Lösung abrät, sollte man hinhören.

Der Grund ist simpel und unangenehm. Ein offener Port ist nie unauffällig. Es gibt kein „mich findet schon keiner”. Eine Sophos-Studie hat neu ans Internet gestellte Server beobachtet und festgehalten, dass der erste Angriffsversuch schon nach 52 Sekunden kam und danach im Schnitt rund 13 Versuche pro Minute auf jeden Server einprasselten. Die Studie ist von 2019, aber der Mechanismus dahinter, automatisiertes Dauer-Scannen des gesamten Adressraums, hat sich seither nicht geändert, eher verschärft. Ein zufälliger Hostname oder ein exotischer Port hilft nicht. Der Sicherheitsforscher, der eine der schwersten HA-Lücken fand, hat das trocken auf den Punkt gebracht: zufällige Hostnamen oder TLS bieten keinerlei Schutz gegen eine Lücke, die vor der Authentifizierung greift. Im selben Writeup beziffert er die Zahl öffentlich erreichbarer Home-Assistant-Instanzen auf über 130.000.

Und solche Lücken gab es real. CVE-2023-27482 war eine Authentifizierungs-Umgehung im Supervisor, die unauthentifizierten Angreifern Remote-Code-Execution erlaubte: volle Kontrolle über Gerät, Daten, Zugangsdaten und das dahinterliegende Heimnetz. CVSS 10.0, die Höchstwertung. Eine einzige solche Lücke reicht, und eine exponierte Instanz ist komplett übernommen. Wer seine HA-Box gar nicht erst ins Internet stellt, ist gegen diese ganze Klasse „remote, vor dem Login” praktisch immun. Das ist kein Glück, das ist Architektur.

Dass exponierte Dienste ein realer Einstiegsweg sind und kein theoretisches Restrisiko, zeigt auch der Verizon-Lagebericht: Die Ausnutzung von Schwachstellen als Einstiegsvektor stieg um rund 180 Prozent und war 2023 Ursache von 14 Prozent aller Datenpannen. Ein offener Port ist genau diese Einladung, nur eben für deinen Kunden.

Das Voll-LAN-VPN

Die zweite Gewohnheit ist die Überkorrektur. Man hat verstanden, dass ein offener Port heikel ist, also macht man es „richtig” und legt ein VPN. WireGuard, OpenVPN, oder bequemer ein Mesh wie Tailscale. Outbound aufgebaut, CGNAT-tauglich, verschlüsselt. So weit ist das auch tatsächlich besser.

Nur löst ein klassisches VPN ein anderes Problem als das, das man hat. Es legt einen ins ganze Heimnetz des Kunden, nicht nur auf die HA-Box. Tailscale verbindet per Default sogar alle Geräte eines Tailnets miteinander; den Zugriff auf genau eine Box einzugrenzen, erfordert das aktive Schreiben von ACL-Regeln. Das geht, aber es ist manuelle Disziplin, die man pro Kunde aufbringen und pflegen muss. Vergisst man es einmal, steht der Tunnel sperrangelweit offen.

Für die eigene private Instanz ist das egal. Im Kundengeschäft ist es ein Vertrauenssprung, den der Job nicht braucht: Man soll die HA-Oberfläche bedienen, nicht nebenbei Einblick in alles bekommen, was sonst noch im Wohnzimmer-Netz hängt. Und im Schadensfall ist genau dieser breite stehende Zugriff das Problem. Ein einziger kompromittierter Wartungszugang wird zum Generalschlüssel für jedes Kundennetz, denn laterale Bewegung in einem flachen Heimnetz ist nach dem Einstieg der Standard-Folgeschritt, kein Sonderfall.

Beide Gewohnheiten haben denselben Konstruktionsfehler. Sie geben dauerhaft mehr Zugriff, als ein punktueller Bedarf rechtfertigt. Der offene Port gibt maximale stehende Sichtbarkeit. Das Voll-VPN gibt breiten stehenden Zugriff. Wartung aber ist weder dauerhaft noch breit.

Was Fernwartung wirklich verlangt

Hier dreht sich der ganze Post. Die übliche Frage lautet „wie komme ich rein?”. Die bessere Frage lautet: Was muss ich überhaupt tun, wenn ich aus der Ferne warte?

Geh die typischen Fälle einmal durch. Ein HACS- oder Core-Update einspielen. Nach einem fehlgeschlagenen Update eine kaputte Integration wieder geradebiegen. HA oder ein Add-on neu starten, wenn etwas hängt. Logs lesen, um zu verstehen, warum eine Automation seit Dienstag nicht mehr feuert. Prüfen, ob die SD-Karte oder die Disk volläuft, bevor sie es tut. Das ist im Wesentlichen die Liste.

Schau dir an, was diese Aufgaben gemeinsam haben. Jede einzelne spielt sich an der HA-Oberfläche oder am Supervisor ab. Keine davon braucht den Drucker des Kunden. Keine braucht das NAS. Keine dauert Stunden, geschweige denn Tage. Es sind diskrete, kurze Eingriffe in einem definierten Zeitfenster: rein, machen, raus. Kein Dauerwohnrecht im Kundennetz.

Das ist der Bruch zur üblichen Denkweise. Wer mit „offener Port” oder „Voll-VPN” antwortet, hat eine stehende Lösung für einen punktuellen Bedarf gebaut. Die Tür steht das ganze Jahr offen, damit man dreimal im Quartal durchgehen kann. In der Security nennt man das fehlendes Least Privilege: Man hat mehr Rechte vergeben, als die Aufgabe braucht, und das auch noch dauerhaft statt nur dann, wenn man sie nutzt.

Eine ehrliche Grenze gehört dazu, sonst wäre der Post zu glatt. Es gibt einen Fall, in dem die saubere Lösung an ihre Kante kommt: Wenn ein Update Home Assistant selbst lahmlegt, ist die HA-UI ja genau das, was repariert werden muss. Ein Wartungs-Plugin, das in Home Assistant läuft, kann dann mitsterben. Für solche Recovery-Szenarien, also Datei- oder Supervisor-Ebene, wenn die UI nicht mehr hochkommt, braucht es im Zweifel eine zweite Schiene. Das ist die ehrliche Restgrenze jedes reinen In-App-Tunnels. Ich verschweige sie lieber nicht, als dir später eine Überraschung zuzumuten.

Die saubere Haltung: outbound, freigegeben, befristet, beschränkt, auditiert

Wenn man die Wartungsaufgabe ernst nimmt, fällt die richtige Lösung fast von selbst heraus. So sieht Home Assistant Fernwartung ohne VPN konkret aus: Sie hat fünf Eigenschaften, und die ergeben sich direkt aus der Checkliste oben.

Outbound-initiiert. Der HA-Host baut die Verbindung nach außen auf, niemand klopft von außen an. Das löst CGNAT mit und macht jeden eingehenden Port überflüssig. Die ganze Klasse „jemand scannt meinen Port” verschwindet, weil es keinen Port zu scannen gibt.

Kunden-freigegeben. Zugriff entsteht erst, wenn der Kunde ihn aktiv freigibt, per Schalter. Kein stiller Dauerzugang. Der Kunde ist der Anrufer, nicht der Überwachte. Diese Consent-Mechanik ist nebenbei auch ein Verkaufsargument, aber das ist eine eigene Geschichte, die ich beim Thema lokale Kontrolle und Vertrauen beim Kunden ausführlicher erzählt habe.

Zeitlich befristet. Das Fenster hat ein Ende und schließt von selbst. Just in time statt dauerhaft. Der Zugriff existiert genau dann, wenn gearbeitet wird, und sonst nicht.

Auf das HA-Gerät beschränkt. Der Tunnel führt zur HA-Instanz, nicht ins LAN. Kein Drucker, kein NAS, keine Kamera. Genau der Scope, den die Wartungsaufgabe braucht, und keinen Millimeter mehr.

Auditiert. Jede Sitzung ist protokolliert. Wer wann was. Das ist nicht nur Hygiene, das ist im Streitfall der Unterschied zwischen einer belastbaren Historie und „ich glaube, das war im April”.

Lies diese fünf Punkte nebeneinander und du siehst, dass sie nicht „mehr Sicherheit” sind, sondern passende Sicherheit. Nicht mehr Zugriff, sondern genau so viel wie nötig, und nur dann, wenn er gebraucht wird.

Die Optionen durch die Wartungs-Brille

Im CGNAT-Post habe ich die Outbound-Werkzeuge danach sortiert, wie gut sie überhaupt durch Carrier-Grade NAT kommen. Hier bewerte ich dieselben Kandidaten nach einem anderen Maßstab: Wie gut passen sie auf eine Wartungs-Aufgabe? Also Angriffsfläche, Zugriffsumfang, ob die Exposition dauerhaft steht, ob der Kunde zustimmt, ob es ein Audit gibt.

Legende: ✅ vorhanden / klein · (✅) mit Aufwand oder Einschränkung · ❌ fehlt oder problematisch.

Ein paar Zeilen verdienen eine Erklärung, weil ein nacktes Kreuz hier zu hart wäre.

Cloudflare Tunnel ist technisch solide: outbound, robust, kostenlose TLS-Zertifikate. Aber er macht die HA-UI dauerhaft unter einer Subdomain erreichbar, nicht nur während der Wartung. Das ist eine stehende Tür, auch wenn sie verschlossen aussieht. Dazu läuft der Verkehr über US-Infrastruktur, was beim Kunden DSGVO-erklärungsbedürftig wird. Für punktuelle Wartung mehr stehende Fläche als nötig.

Tailscale ist ein gutes Werkzeug, und mit sorgfältigen ACLs lässt sich der Zugriff auf die HA-Box eingrenzen. Aber den Default „allow all” muss man selbst überschreiben, ein Consent-Fenster gibt es nicht, ein eingebautes Wartungs-Audit auch nicht. Scope und Befristung sind machbar, aber Handarbeit pro Kunde.

Den klassischen Reverse Proxy (nginx, Traefik, NPM) habe ich gar nicht erst in die Tabelle genommen, weil er konzeptionell wieder bei einem offenen Port oder einer öffentlichen IP landet, also genau bei der stehenden, auffindbaren Tür, die dieser Post als falsch markiert. Und Remote-Desktop-Werkzeuge wie RustDesk oder VNC zielen auf den Bildschirm, nicht auf die HA-Wartungsaufgabe. Für „mal eben ein Add-on neu starten” sind sie überdimensioniert und am eigentlichen Ziel vorbei.

Der Consent-gated Relay in der letzten Spalte ist nicht zufällig die Spalte ohne rote Kreuze. Seine Eigenschaften decken sich eins zu eins mit der Wartungs-Checkliste, weil er für genau diese Frage gebaut wurde. Die ehrliche Grenze bleibt: Man vertraut einer zentralen Relay-Komponente, und fällt HA komplett aus, kann das In-App-Plugin mitfallen (siehe oben). Kein Werkzeug hat nur Häkchen.

Ist das nicht overkill für eine einzelne Instanz?

Doch, für eine einzelne private Instanz schon. Wer seine eigene HA-Box wartet, ist mit Tailscale und etwas Disziplin gut bedient, und das soll auch so bleiben. Der ganze Aufwand mit Consent-Schaltern und Sitzungsprotokollen rechnet sich nicht, wenn der Kunde und der Wartende dieselbe Person sind.

Die Rechnung kippt, sobald es fremde Instanzen werden. Ein Integrator, der zehn oder zwanzig Kunden betreut, multipliziert mit jeder Methode auch deren Schwächen. Zehn offene Ports sind zehnmal die Brute-Force-Last, die exponierte HA-Logins ohnehin ständig abbekommen. Zehn Voll-VPNs sind zehn Kundennetze, in die ein einziger geknackter Zugang führt. Und sobald aus „eine Wartung” „Wartung über viele Kunden” wird, kippt die Frage ohnehin von Zugriff zu Übersicht. Das ist ein eigenes Thema, das ich beim Vergleich Multi-Tenant statt Bastellösung für die Kundenbetreuung durchgespielt habe.

Für den Integrator ist die saubere Haltung am Ende nicht nur Technik. Sie ist verkaufbar. „Ich kann nur warten, wenn Sie freigeben, nur an Ihrer HA-Box, nur für ein Fenster, und es ist protokolliert” ist ein Satz, den offener Port und Voll-VPN strukturell gar nicht sagen können. Der eine ist immer offen, der andere ist immer zu breit.

Was HA Fleet Manager ist, und was nicht

Ich schreibe diesen Blog für ein Produkt, also sage ich offen, wo es in dieser Geschichte steht und wo die Grenzen liegen. Werbesprech nervt mich beim Thema Sicherheit am meisten, weil er genau dort Vertrauen kostet, wo man es braucht.

HA Fleet Manager setzt das Modell aus diesem Post um: outbound-initiiert, kundenfreigegeben, befristet, auf die HA-Instanz beschränkt, auditiert. Der Connector ist eine Custom Integration auf der Kundeninstanz und baut beim Start eine ausgehende WebSocket-Verbindung auf, kein offener Port. Fernzugriff entsteht erst, nachdem der Kunde per Schalter ein Wartungsfenster freigegeben hat, und nach dem Fenster schließt die Tür automatisch wieder. Der Tunnel führt zur HA-UI, nicht ins LAN. Wer sehen will, wie dieser ausgehende Tunnel Schritt für Schritt aufgebaut wird, findet die Übersicht auf der Startseite. Das Hosting läuft in der EU.

Was es nicht ist: ein Allheilmittel gegen jeden Ausfall. Genau die oben genannte Restgrenze gilt auch hier. Fällt Home Assistant so hart aus, dass die UI nicht mehr hochkommt, kann das In-App-Plugin mitfallen, und dann hilft auch das sauberste Wartungsfenster nicht über die Datei- oder Recovery-Ebene hinweg. Es ist ein junges Produkt, kein jahrelang ausgehärtetes RMM. Und es verlangt, dass du einer zentralen Relay-Komponente vertraust. Das ist eine bewusste Abwägung, kein Detail, das man wegmarketingt. Wer eine Handvoll eigener Instanzen über Tailscale pflegt und damit zufrieden ist, braucht das alles nicht.

Der Unterschied wird erst da relevant, wo aus „mein Tunnel” „die Tunnel meiner Kunden” werden. Dann ist die Frage nicht mehr, ob du reinkommst. Sondern wie wenig Zugriff du dafür brauchst.

Disclosure: HA Fleet Manager ist das Produkt hinter diesem Blog. Die CVE-Belege, die Honeypot-Daten und die Hersteller-Empfehlung stammen aber von unabhängigen Quellen, nicht von mir. Den offenen Port würde ich auch ohne ein Produkt im Hintergrund nicht empfehlen.