¿Por qué dejó de funcionar de repente el reenvío de puertos? 6 causas comunes

El reenvío de puertos es frágil porque depende de una cadena de asignaciones estáticas. Estas son las seis razones más comunes por las que deja de funcionar de la noche a la mañana.

1. Tu IP WAN cambió (IP dinámica)

La mayoría de los ISP residenciales usan DHCP con tiempos de concesión de 24h–7d. Cuando la concesión se renueva, *podrías* obtener una IP nueva. La regla de reenvío en el router apunta a tu **IP LAN**, pero los *usuarios externos* llegan a la **IP WAN antigua**.

Solución: DNS dinámico (DDNS) — No-IP, DuckDNS, script DDNS de Cloudflare — para que `tuhost.ddns.net` siempre resuelva a la IP WAN actual.

2. Tu IP LAN cambió (Expiración de concesión DHCP)

El servidor DHCP del router le dio a tu servidor/PC una nueva IP privada (por ejemplo, 192.168.1.50 → .55). La regla de reenvío aún apunta a la IP LAN antigua.

Solución: **Reserva DHCP** (concesión estática) en el router: vincula la dirección MAC a una IP fija. O configura una IP estática en el dispositivo *fuera* del grupo DHCP.

3. Actualización de firmware del router / Reinicio / Restablecimiento de fábrica

• Auto-actualización reinició el router → se vació la tabla NAT (temporal). Las reglas persisten en la configuración, pero el estado se reseteó.
• Restablecimiento de fábrica (pico de energía, presión de botón, gestión remota del ISP) → **todas las reglas personalizadas se fueron**.

Solución: Haz una copia de seguridad de la configuración (`/backup` o exportación de la interfaz web). Desactiva la auto-actualización si es inestable. SAI para el router.

4. Firewall local / Antivirus bloqueando

Windows Defender, antivirus de terceros (Norton, Bitdefender), o `ufw`/`iptables` en Linux comenzaron a bloquear el puerto entrante después de una actualización.

Solución: Agrega una regla de entrada para el puerto TCP/UDP en la *máquina de destino*. Prueba con `nmap -p PUERTO IP_LAN` desde otro dispositivo en la LAN.

5. Servicio movido / Conflicto de puerto

• Moviste el servidor de juegos / Plex / Home Assistant a otra máquina pero no actualizaste la regla de reenvío.
• Otra aplicación (por ejemplo, Steam, cliente de torrents, contenedor Docker) ocupó el mismo puerto.

Solución: `netstat -anob` (Win) / `ss -tulpn` (Linux) para ver quién posee el puerto. Actualiza la regla de reenvío a la nueva IP LAN.

6. CGNAT / Bloqueo de puertos a nivel del ISP

El ISP te movió detrás de **NAT de grado operador (CGNAT)** (común en Starlink, 5G para el hogar, fibra en algunas regiones). Compartes una IP pública con cientos de usuarios—**no hay puertos entrantes posibles**. O el ISP comenzó a bloquear puertos «sospechosos» (25, 80, 443, 8080, 3389, 22).

Solución: Solicita una **IP pública estática** al ISP (a menudo costo extra). O usa **Tailscale Funnel / Cloudflare Tunnel / ngrok / VPN VPS proxy inverso** para evitar el CGNAT por completo.

Lista de verificación de depuración

1. ¿Puedes acceder a `https://IP_LAN:PUERTO` desde otro dispositivo en la LAN? → El servicio funciona.
2. ¿Muestra `canyouseeme.org` / `portchecker.co` abierto? → La ruta WAN funciona.
3. Revisa el registro del router: «DROP IN=WAN OUT=…» → Bloqueo del ISP.