1) ¿Qué es NAT y por qué se usa todavía?
NAT, o Traducción de Direcciones de Red, es la técnica que permite que muchos dispositivos con IP privadas (por ejemplo, 192.168.0.10) salgan a Internet usando una sola IP pública. El router “reescribe” direcciones y puertos para que las respuestas sepan volver a tu equipo. Esto resolvió dos dolores históricos: escasez de IPv4 y exposición directa de equipos domésticos/empresa a Internet.
Aunque IPv6 está diseñado para devolver la conectividad “extremo a extremo”, NAT sigue vigente por tres razones prácticas:
hay demasiados servicios y redes que aún dependen de IPv4;
en muchas organizaciones el perímetro ya está montado alrededor de NAT y port-forwarding;
la ofuscación que genera (no seguridad real, pero sí reducción de superficie directa) encaja con políticas conservadoras.
En mi día a día, una máxima me ha salvado tiempo: “NAT traduce, el firewall decide”. Es decir, que NAT por sí solo no te protege; quien bloquea o permite tráfico es tu política de firewall. Aun así, NAT aporta una capa de no enrutabilidad directa que, combinada con reglas mínimas y buen monitoreo, construye un perímetro sano.
Claves rápidas:
IP privadas RFC1918 dentro; IP pública fuera.
La “tabla de traducciones” es el corazón de NAT.
La sesión existe mientras el estado (puerto/tiempo) está activo.
2) Cómo funciona NAT paso a paso (con ejemplos claros)
Imagina que desde tu portátil (192.168.1.20) abres https://ejemplo.com en el puerto 443. Tu router cambia el origen a su IP pública (digamos 203.0.113.5) y asigna un puerto fuente temporal (p. ej., 54123). En su tabla guarda: 192.168.1.20:54123 → 203.0.113.5:54123. Cuando llega la respuesta desde Internet a 203.0.113.5:54123, el router “deshace” la traducción y la regresa a 192.168.1.20:54123.
Este mecanismo es transparente para la mayoría de las apps, pero no todas. Protocolos que “anuncian su propia IP/puertos” en la carga útil (p. ej., SIP, FTP activo) requieren ayudas (ALG) o configuraciones extra (modos pasivos, STUN/ICE, etc.).
En redes pequeñas me funciona documentar tres cosas por cada servicio publicado:
Origen/Destino (quién accede y a qué);
Puertos exactos (incluye rangos UDP/TCP);
Tiempo de vida (timeouts de NAT y del servicio).
Con eso, el troubleshooting se vuelve repetible.
Cuando una app “misteriosamente” deja de conectarse solo desde ciertas PCs, reviso si el puerto efímero se agota por conexiones masivas (descargas, P2P). Ajustar los timeouts o ampliar el pool de puertos ha sido el arreglo silencioso más efectivo que he aplicado.
3) Tipos de NAT: estática, dinámica y PAT/NAPT (cuándo elegir cada una)
NAT estática (1:1): Mapea una IP privada a una pública fija. Es simple y estable. Lo uso para exponer servidores que necesitan misma IP siempre (p. ej., un SMTP on-prem).
NAT dinámica (muchas:pool): Varias IP privadas “toman prestada” una IP pública de un pool. Útil cuando necesitas rotación sencilla de salidas.
PAT/NAPT (muchas:1 con puertos): El caballo de batalla doméstico/SMB: muchos hosts comparten una IP pública y se diferencian por puertos fuente. Excelente para navegación masiva.
Elección práctica:
¿Servicio entrante crítico y estable? Estática.
¿Varios destinos saliendo con cierta diversidad? Dinámica.
¿Ahorro de IPs y uso general? PAT/NAPT.
Cuando publico un servicio “raro” con puertos no estándar, evito colisiones eligiendo puertos altos (p. ej., 49152-65535) y documentando el port-forward exacto. Y si alguien sugiere “abre todo y prueba”, freno: mínimo puerto expuesto siempre.
4) CGNAT: traducción a gran escala para ISPs y empresas
CGNAT (Carrier-Grade NAT) es NAT a lo bestia, operado por el ISP. Miles de clientes salen a Internet por pocas IP públicas. Desde el lado del abonado, esto luce como doble NAT: tu router hace NAT y, más arriba, el backbone del ISP vuelve a hacer NAT.
Impactos que conviene anticipar:
Port-forwarding roto: publicar tu servidor casero suele ser imposible, porque no controlas la capa de NAT del ISP.
Geolocalización rara: sesiones “salen” por IPs compartidas; algunos servicios detectan ubicaciones o reputaciones inesperadas.
Trazabilidad por puertos: muchos ISPs asignan rangos de puertos por cliente para poder rastrear abusos y cumplir normativas.
Cuando necesito acceso desde fuera y estoy bajo CGNAT, voy por dos caminos: pido IP pública (a veces es un extra de pago) o monto túneles/VPN de overlay (Tailscale/ZeroTier) y me olvido de abrir puertos. En mi caso, esto último ha sido “instalar, autorizar, listo”.
5) Impacto de NAT en aplicaciones reales: VoIP/SIP, juegos, FTP y SaaS
VoIP/SIP: Este protocolo anuncia IP/puertos dentro de los mensajes. Con NAT, eso se desalineaba y terminaba en audio unilateral o registros fallidos. ¿Mi atajo? Desactivar SIP ALG del router y dejar que el PBX/cliente gestione la travesía con STUN/ICE. He visto que solo con apagar el ALG, la señalización y el RTP vuelven a la vida.
Juegos/Consolas: Muchos juegos abren puertos dinámicos y dependen de UPnP. Me ha pasado que en doble NAT UPnP engaña a una capa pero la otra lo bloquea. Resultado: NAT “estricta”. La solución estable fue evitar doble NAT (modo bridge en el CPE del ISP) o usar túneles.
FTP/FTPS: El FTP activo trae dolores porque el servidor inicia la conexión de vuelta. Detrás de NAT, eso suele bloquearse. Mejor FTP pasivo con rangos PASV fijos expuestos en el firewall. Y ojo con FTPS: como va cifrado, los ALG no “leen” puertos en la sesión; sin rangos definidos no hay milagro.
SaaS/Oficina remota: Con suites de videollamadas modernas (WebRTC), lo que marca la diferencia son STUN/TURN confiables y timeouts de NAT razonables. Si la llamada se cae a los 30–60 min, reviso timers.
6) NAT y seguridad: beneficios, límites y buenas prácticas de hardening
NAT no es un firewall, pero su uso correcto reduce exposición: nadie puede “rutar” directamente a tus hosts internos. Aun así, los riesgos vienen cuando abrimos puertos o dejamos servicios escuchando sin control. Mis prácticas de cabecera:
Principio de mínimo puerto expuesto: abre solo lo imprescindible, y documenta quién/para qué.
Listas de control + geo/IP: combina NAT con ACL/Reglas por origen.
Registro (logging): guarda quién fue mapeado a qué puerto y cuándo; clave ante incidentes.
Rotación de puertos publicados cuando hay abuso o escaneo persistente.
UPnP con freno: si lo habilitas, que sea en una sola capa y con auditoría.
Más de una vez, el “misterio” de RDP expuesto se solucionó cerrándolo y montando acceso remoto por VPN. Menos superficie, más control.
7) NAT vs. IPv6: escenarios híbridos, NAT64/NAT46 y transición ordenada
Con IPv6, cada dispositivo puede tener una IP global única. Idealmente, NAT sobra. Pero el mundo es híbrido, y ahí entran:
Dual-stack (IPv4+IPv6): conviven ambas pilas; NAT sigue para IPv4.
NAT64/NAT46: pasarelas que permiten que clientes IPv6-only accedan a servicios IPv4, o viceversa.
DNS64: “forja” registros A/AAAA para que el cliente IPv6 crea que todo es alcanzable por IPv6 y la pasarela haga el resto.
Mi regla práctica: si puedes activar IPv6 en tu entorno, hazlo; reduce dependencia de NAT para nuevos servicios, pero no desmontes IPv4 sin plan. Empezar por servicios internos y apps web es un camino suave.
8) Problemas comunes y troubleshooting (hairpin, doble NAT, UPnP, ALG)
Doble NAT: dos routers consecutivos haciendo NAT. Síntomas: juegos con NAT estricta, port-forward que “no abre”, VPNs caprichosas. Arreglo: poner el primer router en bridge o replicar el port-forward en ambos (si controlas los dos).
Hairpin NAT (NAT loopback): acceder a tu propio dominio público desde dentro de tu LAN. Necesitas una regla src-nat/masquerade específica y cuidar el orden de reglas para que el flujo LAN→WAN→LAN no se rompa.
ALG: a veces ayudan (SIP, FTP), a veces estorban (variantes de SIP). Mi política: si rompe, apágalo y ajusta la app (STUN/ICE, PASV).
Exceso de sesiones: dispositivos IoT/descargas pueden agotar puertos efímeros. Solución: ampliar rango, subir límites, y tocar timeouts sensatamente.
La primera vez que resolví hairpin en Mikrotik, fue cuestión de añadir una masquerade de retorno y moverla por encima de reglas genéricas. Un cambio de orden… y magia.
9) Port-forwarding seguro y registro de eventos (logging)
El port-forwarding es abrir una “ventana” desde Internet hacia adentro. Para que sea seguro:
Nombra y documenta cada regla (quién, qué puerto, por qué, hasta cuándo).
Prefiere VPN o reverse proxy cuando se pueda (WireGuard, Tailscale; o Nginx/Traefik con auth).
Limita origen (IP/país) cuando sea viable.
Usa puertos altos no obvios para servicios legacy (no confundir con seguridad por oscuridad; es para evadir ruido).
Activa logs de NAT y guárdalos el tiempo necesario. Cuando hubo incidentes, poder reconstruir “qué IP interna fue traducida a qué puerto/externo” marcó la diferencia.
10) Preguntas frecuentes sobre NAT
¿NAT mejora la seguridad?
Ayuda a no exponer equipos por defecto, pero la seguridad la pone el firewall y las buenas prácticas.
¿Por qué no me funciona el port-forward si abrí el puerto?
Sospecha de doble NAT o CGNAT del ISP. Si es CGNAT, necesitas IP pública o VPN/overlay.
¿Qué hago con SIP y audio unilateral?
Primero desactiva SIP ALG, verifica STUN/ICE, y ajusta timeouts.
¿FTP se corta con FTPS?
Define rangos PASV fijos y publícalos; los ALG no inspeccionan dentro del cifrado.
Conclusión
NAT sigue siendo el “traductor” indispensable en redes IPv4, pero no es un sustituto del firewall. Entender cómo mapea puertos, qué rompe (y por qué) y cómo convivir con CGNAT/IPv6 te ahorra horas de trial-and-error. Mi receta personal: abre lo mínimo, registra todo, y usa túneles cuando Internet público se pone en tu contra.