Cómo saber si una regla de firewall o NAT está bloqueando una conexión entrante al servidor doméstico

Prueba desde fuera de la red doméstica y sigue la conexión hacia adentro hasta que el paquete desaparezca.

Una conexión entrante a una aplicación autoalojada puede fallar porque el servicio no está escuchando, el firewall del host la rechaza, el router reenvía el puerto o dirección incorrectos, la WAN está detrás de CGNAT o doble NAT, o la respuesta sale por la puerta de enlace equivocada. El diagnóstico más seguro mantiene la exposición pública limitada, verifica un servicio TCP o UDP a la vez, y usa la salida del listener, contadores del router, registros del firewall y capturas de paquetes para identificar la primera etapa faltante.

Confirma que el Servicio Está Escuchando en la Interfaz Esperada

Comienza en el propio servidor doméstico. Verifica que el proceso esté en ejecución, que el puerto TCP o UDP previsto esté abierto, y que el listener esté vinculado a la dirección LAN o a todas las interfaces requeridas en lugar de solo 127.0.0.1 o una red solo para contenedores.

La guía de Baeldung para probar puertos explica que un socket en modo LISTEN está listo para aceptar conexiones, pero la dirección de enlace aún decide qué interfaces pueden acceder a él.

Prueba el servicio desde otro dispositivo LAN usando la IP privada del servidor y el puerto exacto. Si falla, detente en el servidor o en el camino local VLAN; una regla NAT no puede reenviar tráfico con éxito a un servicio que no es accesible desde el lado del router en la LAN.

Usa un Cliente Externo en Lugar de Probar Desde la Misma LAN

Desconecta un teléfono del Wi-Fi o usa un sistema en otra conexión a internet. Prueba la IP pública o dominio, puerto externo y protocolo correcto mientras el servicio objetivo está escuchando activamente.

La guía de Lifewire sobre reenvío de puertos señala que la regla del router y el firewall del equipo deben permitir la conexión, y recomienda verificar los puertos abiertos desde fuera de la red en lugar de confiar en un navegador local que puede encontrar comportamiento de NAT-loopback.

Registra si el cliente ve un tiempo de espera, rechazo inmediato, error TLS o respuesta de la aplicación. Un rechazo suele significar que un host accesible no tiene un servicio aceptando en esa ruta; un tiempo de espera silencioso es más consistente con filtrado, reenvío faltante, NAT ascendente o un destino inalcanzable.

Compara la Dirección WAN del Router con la Dirección Pública

Lee la dirección WAN que muestra el router doméstico y compárala con la dirección pública reportada por un servicio externo. Deben coincidir para un reenvío de puertos IPv4 ordinario a menos que otro router ascendente realice el primer NAT.

Si la dirección WAN del router es privada, compartida o diferente de la dirección pública, la regla de reenvío puede estar detrás de doble NAT o NAT de grado operador. En esa condición, el paquete nunca llega a la regla del router sin importar cuántas veces se cambie el firewall local.

Reenvía el mismo puerto en la puerta de enlace ascendente cuando la controles, solicita una dirección pública usable al ISP, o elige una VPN, túnel saliente o relé cuando el reenvío entrante no esté disponible. No debilites el firewall del servidor para compensar un paquete que nunca llega al router doméstico.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Observa los Contadores NAT y los Registros del Firewall Durante una Prueba

Vacía o registra los contadores relevantes del router, habilita el registro en la regla de prueba limitada, luego envía un intento de conexión externo. La pregunta útil es si el paquete WAN coincide con la regla NAT y si el paquete traducido coincide con la regla de permiso.

Un caso de solución de problemas de MikroTik captura el requisito común para ambas una regla NAT y una regla de firewall. La traducción cambia el destino; no garantiza que el firewall permita el flujo reenviado.

Si ningún contador cambia, inspecciona la dirección pública, puerto externo, interfaz y NAT ascendente. Si NAT incrementa pero la regla de permiso no, revisa el orden de las reglas y el destino traducido. Si ambos incrementan, captura en el servidor para ver si el paquete llega.

Verifica el Destino Interno, Protocolo y Ruta de Retorno

Confirma que la regla NAT apunta a la dirección reservada actual del servidor y al puerto interno correcto. Verifica si la aplicación espera TCP, UDP o ambos, porque una prueba TCP exitosa no dice nada sobre un servicio solo UDP.

La guía de solución de problemas de PortForward destaca dos errores frecuentes: reenviar al equipo incorrecto y dejar un firewall de software bloqueando la aplicación después de crear la regla del router.

Cuando el paquete llega al servidor pero no regresa respuesta, inspecciona la puerta de enlace del servidor, el enrutamiento por políticas, la red del contenedor y la ruta asimétrica multi-NIC. El servicio debe enviar su respuesta de vuelta por una ruta que preserve el estado del firewall y NAT creado por el paquete entrante.

Elimina la Regla de Prueba Cuando No Necesite Permanecer Pública

Una vez identificada la capa que falla, aplica la corrección más pequeña y repite la misma prueba de afuera hacia adentro. No abras un rango de puertos ni desactives todo el firewall solo para ver si algo cambia.

La guía de ZimaSpace para verificar la exposición del servidor doméstico ofrece la siguiente comprobación de seguridad después de que una regla de reenvío comienza a funcionar.

Mantén una regla pública solo cuando el servicio esté intencionadamente expuesto a internet, autenticado, parcheado, registrado y aislado de las interfaces de gestión. Para paneles privados, SSH, SMB y archivos personales, una VPN o túnel autenticado suele ser un límite más claro que un puerto reenviado permanente.