CGNAT und Home Assistant — warum dein Port-Forwarding bald nicht mehr funktioniert

Das Symptom

Ein Klassiker im Home-Assistant-Forum: Jemand hat in der FritzBox eine Portfreigabe für Port 8123 eingerichtet, im Router ist alles grün, lokal funktioniert die HA-Instanz, aber von außen ist sie nicht erreichbar. Stunden gehen ins Debugging — Firewall, DDNS, Zertifikate, Router-Firmware. Alles geprüft, nichts gefunden. Bis jemand im Thread schreibt: „Hast du eigentlich eine öffentliche IPv4-Adresse?”

Antwort meist: „Ich glaube schon.”

Dann der Tipp: Auf whatismyip.com nachsehen, die angezeigte Adresse mit der WAN-IP im Router vergleichen. Wenn beide unterschiedlich sind, ist die Antwort gefunden: CGNAT. Und dann ist das Port-Forwarding nicht kaputt — es liegt in einem Netzsegment, das vom Internet aus prinzipiell nicht erreichbar ist.

Was ist CGNAT?

Carrier-Grade NAT (auch Large-Scale NAT) ist die Strategie, mit der Internet-Anbieter dem IPv4-Mangel begegnen. Statt jedem Kundenanschluss eine eigene öffentliche IPv4 zu geben, teilen sich viele Kunden eine begrenzte Anzahl öffentlicher IPs. Dazwischen sitzt ein riesiger NAT-Router auf Anbieterseite.

Für dich heißt das: deine WAN-Adresse ist plötzlich privat. Typischerweise aus dem Block 100.64.0.0/10, der genau für diesen Zweck reserviert ist. Eingehende Pakete aus dem Internet treffen nicht mehr deinen Router, sondern den NAT des Providers — und der weiß bei tausend Kunden hinter derselben öffentlichen IP nicht, an wen er sie weiterleiten soll. Also wirft er sie weg. Ausgehende Verbindungen funktionieren weiter, weil NAT den Rückweg im Zustand behält.

Port-Forwarding setzt voraus, dass deine WAN-Seite öffentlich erreichbar ist. Hinter CGNAT ist sie das nicht. Daran ändert auch das fünfzehnte Neukonfigurieren des Routers nichts.

Wer ist betroffen?

CGNAT trifft längst nicht mehr nur Exotenanschlüsse:

• Mobilfunk: so gut wie alle Mobilfunk-Datenverbindungen in DACH laufen darüber. Wer HA auf einem LTE-Router betreibt (Wochenendhaus, Backup-Anschluss), ist garantiert dabei.
• Glasfaser-Neuanschlüsse: viele neuere Anbieter geben in den günstigen Privattarifen standardmäßig CGNAT. Eine öffentliche IPv4 gibt es nur optional, meist kostenpflichtig.
• Kabel-Anschlüsse: zunehmend ebenfalls, vor allem in neu erschlossenen Regionen.
• DSL: historisch öffentlich. Auch hier rüsten manche Anbieter still um.

Ein Tarifwechsel reicht, manchmal sogar ein Routerwechsel beim selben Anbieter. Und dann ist das gestern noch funktionierende Port-Forwarding heute tot.

Schnelltest: bin ich betroffen?

Drei Minuten:

1. WAN-IP im Router ablesen. Bei der FritzBox: Übersicht → Internet → IP-Adresse.
2. Öffentliche IP über externes Tool ermitteln. whatismyip.com oder im Terminal curl ifconfig.me.
3. Vergleichen.
   • Identisch → öffentliche IPv4, klassisches Port-Forwarding funktioniert.
   • Unterschiedlich, WAN-IP beginnt mit 100.64. bis 100.127. → CGNAT, Port-Forwarding wird nicht funktionieren.
   • Unterschiedlich, WAN-IP ist privat (10.x, 192.168.x, 172.16-31.x) → du sitzt hinter mehreren NAT-Schichten, vermutlich einem zweiten Router. Behebbar, aber kein CGNAT.

Workarounds und ihre Grenzen

Es gibt mehrere Wege, hinter CGNAT trotzdem Fernzugriff zu bekommen. Nicht alle sind gleich gut.

IPv6

Auf dem Papier elegant: IPv6-Adressen sind öffentlich, jedes Gerät hat seine eigene. In der Realität gibt es ein paar Haken. Viele Anbieter rollen IPv6 nur „opportunistisch” aus, ohne stabilen Präfix und ohne Garantie. DynDNS-Provider mit ordentlichem AAAA-Record-Support muss man suchen. Und das Gegenüber — das Hotel-WLAN, das Mobilfunknetz, das Firmen-Gastnetz, von dem aus zugegriffen werden soll — hat oft schlicht kein IPv6.

Für Bastler funktioniert das. Für robusten Fernzugriff bei Kunden ist es zu wackelig.

Klassisches VPN (WireGuard, OpenVPN)

Auch der VPN-Server braucht eine öffentliche IPv4. Was bedeutet: man hostet ihn woanders — kleiner Cloud-Server, statische IP. HA-Instanz und Client verbinden sich beide ausgehend zum VPN-Server, der vermittelt.

Robust, alt, technisch kontrollierbar. Dafür betreibt man einen weiteren Server, und das VPN gibt typischerweise Vollzugriff aufs Netz. Für eine einzelne eigene Installation okay. Wer das bei zehn Kunden ausrollt, schenkt sich Wartungslast — und beim Kunden Vertrauen, weil „der hat doch jetzt auch Zugriff auf den Drucker und das NAS, oder?”.

Tailscale

Mesh-VPN mit DERP-Relays. Jeder Knoten verbindet sich ausgehend zur Steuerebene, hinter CGNAT übernehmen die Relays die Vermittlung. Kein eigener Server.

Zero-Config, robust, CGNAT-tauglich, kostenlos für kleine Setups. Bekanntes Pferd, weiß was es tut. Aber: wer beim Kunden Tailscale installiert, ist im selben Tailnet. Damit auch potenziell im Drucker, NAS, Babyfon. Aus Integrator-Sicht ein größerer Trust-Sprung, als der eigentliche Use-Case braucht.

Cloudflare Tunnel

Persistenter Outbound-Tunnel vom HA-Host zu Cloudflare, das Frontend wird unter einer Subdomain erreichbar. Sehr robust, kostenlose TLS-Zertifikate, CGNAT-tauglich, gut dokumentiert.

Zwei Sachen muss man wissen: der Datenverkehr fließt über US-Infrastruktur — DSGVO-erklärungsbedürftig, wenn man das beim Kunden ausrollt. Und es ist eine Single-Instance-Lösung. Bei zehn Kunden hat man zehn separate Cloudflare-Konfigurationen, die alle ihre eigene Pflege wollen.

WebSocket-Relay (spezialisierter Outbound-Tunnel)

Die Architektur, die HA Fleet Manager nutzt: ein HA-Custom-Plugin baut beim Start eine ausgehende WebSocket-Verbindung zu einem Relay-Server auf. Wenn der Integrator Fernzugriff braucht, wird über dieselbe Verbindung ein Tunnel zur HA-UI geöffnet — auf Wunsch zeitlich befristet und nur nach Konsens des Kunden.

CGNAT-tauglich, weil alles ausgehend. Zugriff bleibt auf das HA-Gerät beschränkt, kein Vollnetz-VPN. Multi-Tenant-fähig, Konsens- und Audit-Mechanik eingebaut, EU-Hosting möglich. Der Preis: man vertraut einer zentralen Relay-Komponente. Das ist bei einem Spezialanbieter mit dokumentierter Architektur leichter als bei einem Generalisten, bleibt aber eine bewusste Entscheidung.

Was bedeutet das für die Architektur

CGNAT wird zunehmen, nicht verschwinden. Anbieter sparen damit reale Kosten, und der IPv4-Pool wird nicht größer. Wer heute noch eine öffentliche IPv4 hat, sollte sich nicht darauf einrichten, sie morgen noch zu haben.

Die langfristig tragfähige Antwort für Home Assistant lautet immer ausgehend. Kein Port-Forwarding, kein Warten auf eingehende Pakete, sondern eine vom HA-Host initiierte Verbindung zu einem Vermittler. Tailscale, Cloudflare Tunnel und spezialisierte WebSocket-Relays folgen alle diesem Muster. Sie unterscheiden sich darin, wer vermittelt, wie tief der Zugriff reicht, und wie Konsens und Audit organisiert sind.

Für eine private HA-Instanz reicht jede dieser Optionen. Sobald mehrere Kundeninstallationen dazukommen, lohnt sich eine Plattform, die diesen Outbound-Tunnel mit Multi-Tenancy, Monitoring und einem Konsens-Workflow kombiniert — genau die Lücke besetzt HA Fleet Manager.