CGNAT y Home Assistant — por qué tu port forwarding va a dejar de funcionar

El síntoma

Un clásico del foro de Home Assistant. Alguien abre el puerto 8123 en su router, la regla aparece en verde, la instancia funciona perfectamente en la red local, pero desde fuera no hay manera de llegar. Horas de depuración. Firewall. DDNS. Certificados. Firmware del router. Todo revisado, nada encontrado. Hasta que alguien más abajo en el hilo lanza la pregunta que debería haber sido la primera: «¿Tienes en realidad una dirección IPv4 pública?»

La respuesta suele ser: «Creo que sí».

Y luego el truco. Abrir whatismyip.com, comparar lo que ahí aparece con la IP WAN que muestra el router. Si las dos no coinciden, misterio resuelto. CGNAT. Y a partir de ese momento el port forwarding no está roto en ningún sentido que se pueda arreglar tocando el router: está en un trozo de la red al que internet, por diseño, no llega.

Qué es realmente CGNAT

Carrier-Grade NAT (a veces llamado Large-Scale NAT) es la forma en que los operadores se las arreglan con la escasez de IPv4. En lugar de dar a cada cliente una IPv4 pública propia, comparten un puñado más pequeño de direcciones públicas entre muchos abonados, con un NAT enorme del lado del proveedor que se encarga de la traducción.

Para ti, la consecuencia práctica es esta: tu dirección WAN es de repente privada. Normalmente del bloque 100.64.0.0/10, reservado precisamente para esto. Un paquete entrante desde internet ya no llega a tu router: choca primero contra el NAT del operador, que no tiene la menor idea de a cuál de los mil clientes detrás de esa IP pública va dirigido, y lo descarta. El tráfico saliente sigue funcionando, porque el NAT sí sabe seguir el rastro de una conexión que tú mismo iniciaste.

El port forwarding parte de la base de que tu lado WAN es alcanzable desde fuera. Detrás de CGNAT no lo es. Reconfigurar el router por decimoquinta vez no va a cambiarlo.

A quién le toca

CGNAT ya no es un caso raro:

• Datos móviles: prácticamente todos, en todas partes. Si HA vive en un router LTE en una casa de fin de semana o como enlace de respaldo, estás detrás de CGNAT, garantizado.
• Fibra nueva: muchas operadoras de fibra recientes reparten direcciones CGNAT por defecto en las tarifas residenciales más baratas. Una IPv4 pública estática es un extra, casi siempre de pago.
• Cable: cada vez más, sobre todo en zonas desplegadas hace poco.
• DSL: históricamente pública. Algunos proveedores también están cambiando aquí, sin hacer ruido.

Basta con un cambio de tarifa. A veces incluso un cambio de router con el mismo operador. Y el port forward que ayer funcionaba está muerto hoy.

Comprobación rápida: ¿me afecta?

Tres minutos:

1. Lee la IP WAN en tu router.
2. Consulta la IP pública desde fuera. whatismyip.com en el navegador, o curl ifconfig.me en la terminal.
3. Compara.
   • Idénticas → IPv4 pública, el port forwarding clásico todavía funciona.
   • Diferentes, y la IP WAN empieza por 100.64. hasta 100.127. → CGNAT. El port forwarding no te va a sacar de ahí.
   • Diferentes, y la IP WAN es privada (10.x, 192.168.x, 172.16-31.x) → estás detrás de varias capas de NAT, probablemente un segundo router. Tiene arreglo. No es CGNAT.

Soluciones, y qué falla en cada una

Hay varias maneras de conseguir acceso remoto desde detrás de CGNAT. No todas son igual de buenas.

IPv6

Elegante sobre el papel. Las direcciones IPv6 son públicas, cada dispositivo tiene la suya. En la vida real, hay un par de matices. Muchas operadoras despliegan IPv6 de forma oportunista, sin un prefijo estable ni promesas firmes. Encontrar proveedores de DynDNS que manejen los registros AAAA con decencia cuesta lo suyo. Y el otro extremo de la conexión —el wifi del hotel, la red móvil, la red de invitados de la empresa desde la que te conectas— a menudo no tiene IPv6 ni de lejos.

Para aficionados, funciona. Para acceso remoto fiable a casa de un cliente, demasiado inestable.

VPN clásica (WireGuard, OpenVPN)

El servidor VPN también necesita una IPv4 pública. Lo que significa alojarlo en otro sitio. Un VPS pequeño, IP estática. La instancia de HA y el cliente abren ambos conexiones salientes contra ese servidor VPN, que hace de intermediario.

Probada en batalla. Vieja. Bajo tu control técnico. El precio es que operas un segundo servidor, y una VPN suele abrir toda la red. Bien para una sola instalación propia. Despliégalo en diez clientes y ya te has comprado deuda de mantenimiento, y además has pagado en confianza del lado del cliente, porque «espera, ¿ahora también puedes ver mi impresora y mi NAS?».

Tailscale

Mesh VPN con relays DERP. Cada nodo se conecta hacia afuera al plano de control, y los relays se encargan del puente cuando hay CGNAT. Sin servidor propio.

Cero configuración, robusto, amistoso con CGNAT, gratis para escalas pequeñas. Caballo conocido, sabe hacer su trabajo. El problema es el mismo que con WireGuard: instalas Tailscale en casa de un cliente y ya está en tu tailnet. Lo que significa potencialmente dentro de su impresora, su NAS y su vigilabebés. Un salto de confianza mayor del que el caso de uso realmente pide.

Cloudflare Tunnel

Túnel saliente persistente desde el host de HA hasta Cloudflare. El frontend pasa a ser alcanzable bajo un subdominio. Muy estable en la práctica, certificados TLS gratis, amistoso con CGNAT, bien documentado.

Dos cosas que conviene saber. El tráfico va por infraestructura estadounidense, lo que pone a uno en aprietos a la hora de explicarlo bajo RGPD cuando lo despliegas en casa del cliente. Y es un montaje single-instance: diez clientes son diez configuraciones de Cloudflare, cada una con su propio mantenimiento.

Relay por WebSocket (túnel saliente especializado)

La arquitectura que usa HA Fleet Manager. Una integración personalizada de Home Assistant abre, al arrancar, un WebSocket saliente de larga vida hacia un servidor relay. Cuando el integrador necesita acceso remoto, se abre por esa misma conexión un túnel hasta el frontend de HA, con duración limitada y solo después de que el cliente haya dado su consentimiento de forma explícita.

Amistoso con CGNAT, porque todo nace hacia afuera. El acceso queda acotado al dispositivo de HA, sin VPN a toda la red local. Multi-tenant, consentimiento y auditoría integrados, hosting en la UE sobre la mesa. El precio es que confías en un componente relay central. Más fácil de tragar cuando se trata de un proveedor especializado con una arquitectura documentada que cuando es una caja negra de un generalista, pero sigue siendo una decisión consciente de confianza.

Qué significa esto para la arquitectura

CGNAT va a más, no a menos. Las operadoras se ahorran dinero real con él, y el pool de IPv4 no va a crecer. Quien hoy todavía conserva una IPv4 pública no debería confiar en seguir teniéndola mañana.

La respuesta que aguanta a largo plazo para Home Assistant es siempre saliente. Sin port forwarding, sin esperar paquetes entrantes, solo una conexión iniciada por el host de HA hacia un intermediario que se encarga del resto. Tailscale, Cloudflare Tunnel y los relays WebSocket especializados siguen todos ese patrón. En lo que se diferencian es en quién hace de intermediario, hasta dónde llega el acceso y cómo se organizan el consentimiento y la auditoría.

Para una sola instalación privada de HA, cualquiera de estas opciones sirve. En cuanto se acumulan varias instalaciones de cliente, el argumento a favor de una plataforma que combine ese túnel saliente con multi-tenancy, monitorización y un flujo de consentimiento se vuelve difícil de rebatir, y ese es el hueco que HA Fleet Manager está pensado para llenar.