CGNAT MikroTik para ISP: guía práctica en RouterOS

Si operas un ISP o una WISP en Chile, ya conoces el problema de fondo: las direcciones IPv4 públicas se agotaron y cada abonado nuevo que sumas compite por un pool que no crece. Comprar bloques en el mercado secundario es caro y no escala. Ahí entra el CGNAT MikroTik (Carrier-Grade NAT sobre RouterOS), la técnica que te permite servir a miles de suscriptores detrás de un puñado de IPs públicas sin frenar el crecimiento de tu red. En esta guía práctica vemos cómo se implementa CGNAT sobre RouterOS con comandos reales, qué decisiones de diseño importan y dónde están las trampas que se pagan caro en producción.

Qué es CGNAT y por qué un ISP lo necesita

CGNAT es una capa de NAT operada por el proveedor, no por el cliente. En lugar de entregar una IP pública a cada abonado, le asignas una dirección del espacio compartido 100.64.0.0/10 (RFC 6598, reservado justamente para este uso) y traduces todo ese tráfico hacia un pequeño conjunto de IPs públicas en el borde de tu red. El resultado: una relación de sobresuscripción que puede llegar a cientos de clientes por cada IPv4 pública.

El punto donde vive CGNAT suele ser tu BNG o el router de agregación que ya termina las sesiones PPPoE de tus abonados. Ahí es donde el tráfico privado se concentra antes de salir a Internet, y es el lugar natural para aplicar la traducción. Antes de tocar una sola regla conviene tener claro que CGNAT no es inocuo en términos de recursos: introduce estado, consume CPU y complica la trazabilidad. Por eso el diseño importa tanto como la sintaxis.

Direccionamiento: el pool privado y las IPs públicas

El primer paso es definir el rango privado que reparten tus abonados y el pool público hacia el que traduces. En RouterOS el menú es /ip/pool. Un ejemplo mínimo:

/ip/pool
add name=cgnat-clientes ranges=100.64.0.0/10
add name=publicas-out ranges=200.x.x.10-200.x.x.13

El pool cgnat-clientes es el que asignas como remote-address en tus perfiles PPP para las sesiones de abonado; el pool publicas-out es el bloque de IPv4 reales que compartirás. La relación entre ambos define tu nivel de sobresuscripción y, con él, cuántos puertos por cliente vas a poder ofrecer.

Un detalle que se olvida seguido: el espacio 100.64.0.0/10 no es un rango privado cualquiera. Está reservado para CGNAT precisamente para evitar choques con el 192.168.0.0/16 o el 10.0.0.0/8 que ya usan los routers del abonado en su LAN. Si repartieras direcciones 10.x a tus clientes, tarde o temprano colisionarías con el direccionamiento interno de alguno y aparecerían fallas difíciles de diagnosticar. Usar el espacio compartido correcto es parte del diseño, no un detalle cosmético.

CGNAT MikroTik en la práctica: masquerade vs. NAT determinístico

Hay dos formas de configurar CGNAT en RouterOS, y elegir mal te cuesta caro cuando llegue un requerimiento legal o un cliente reclame que "un juego no le conecta".

1. Masquerade simple (rápido, pero opaco)

La opción directa es una regla de srcnat con action=masquerade sobre el tráfico que sale a Internet:

/ip/firewall/nat
add chain=srcnat action=masquerade \
    src-address=100.64.0.0/10 out-interface-list=WAN

Funciona, pero tiene dos problemas serios para un ISP. Primero, la asignación de puertos es dinámica y aleatoria: para saber qué abonado usó qué puerto público en un instante dado tienes que registrar cada conexión, lo que genera volúmenes de logs enormes. Segundo, masquerade recalcula la IP de salida en cada conexión, lo que agrega carga innecesaria cuando la IP pública es fija. Sirve para un laboratorio o un piloto pequeño, no para producción a escala.

2. NAT determinístico con bloques de puertos (recomendado)

La aproximación seria usa action=src-nat con to-addresses y to-ports, asignando a cada franja de IPs privadas un bloque fijo de puertos sobre una IP pública concreta. Como el mapeo abonado → puerto es predecible, no necesitas loggear cada conexión: basta la tabla de asignación para responder un requerimiento. Un esquema simplificado:

/ip/firewall/nat
add chain=srcnat action=src-nat \
    src-address=100.64.0.0/10 \
    to-addresses=200.x.x.10 to-ports=1024-4095
add chain=srcnat action=src-nat \
    src-address=100.64.4.0/24 \
    to-addresses=200.x.x.10 to-ports=4096-7167

En una implementación real defines una regla por cada franja de abonados, distribuyendo los ~64.500 puertos disponibles de cada IP pública en bloques del tamaño que decidas. Menos puertos por cliente = más sobresuscripción, pero también más probabilidad de agotar puertos en abonados con muchos dispositivos y apps que abren decenas de conexiones simultáneas. Ese balance es una decisión de ingeniería, no un valor por defecto.

Criterio	Masquerade	src-nat determinístico
Asignación de puertos	Dinámica / aleatoria	Bloque fijo por abonado
Trazabilidad legal	Requiere loggear cada conexión	Tabla de mapeo estática
Carga por conexión	Mayor (recalcula IP salida)	Menor (IP fija)
Uso recomendado	Piloto / laboratorio	Producción ISP

Trazabilidad y conntrack: lo que no puedes ignorar

Cuando compartes una IP pública entre cientos de abonados, ante un requerimiento judicial debes poder responder qué cliente estaba detrás de una IP y puerto público a una hora determinada. Con NAT determinístico esa respuesta sale de la tabla de asignación de bloques; con masquerade dependes de logs de conexión que hay que almacenar, rotar y respaldar. Definir esto antes de desplegar te ahorra un problema regulatorio grave.

El otro frente es el connection tracking. Todo CGNAT vive del conntrack: cada flujo activo ocupa una entrada en memoria. En un equipo con miles de abonados esto se cuenta en cientos de miles o millones de conexiones simultáneas, y dimensionar mal el hardware se traduce en tabla llena, conexiones caídas y reclamos en hora peak. El síntoma clásico es una red que anda perfecta a las tres de la tarde y se degrada a las nueve de la noche, cuando el número de flujos concurrentes se dispara y la tabla se satura: no es un problema de ancho de banda, es de estado. Puntos a vigilar:

• Capacidad del conntrack y RAM real del equipo que hará de CGNAT.
• Timeouts de UDP y TCP: bajarlos libera entradas antes, a costa de romper sesiones largas si te pasas de agresivo.
• FastTrack: acelera el reenvío, pero salta parte del pipeline de firewall; hay que entender qué tráfico estás eximiendo antes de activarlo bajo CGNAT.
• Protocolos que sufren NAT: algunos juegos, VoIP y aplicaciones P2P se degradan al compartir IP; conviene documentarlo para tu mesa de soporte.

Dónde CGNAT deja de ser suficiente: IPv6

Conviene ser honestos: CGNAT es un puente, no un destino. Cada capa de NAT que agregas resta visibilidad y suma un punto donde algo se puede romper. La salida estructural al agotamiento de IPv4 es desplegar IPv6 y operar en dual-stack: el tráfico que ya habla IPv6 sale nativo, sin traducción, y el CGNAT queda solo para el IPv4 heredado. Eso descarga tu tabla de conntrack y mejora la experiencia de tus abonados en los servicios que ya priorizan IPv6.

Vale recordar además que NAT es un concepto exclusivamente IPv4: en RouterOS el firewall NAT no procesa IPv6, precisamente porque el modelo de IPv6 asume direccionamiento de extremo a extremo. Cuanto antes avances en tu plan de despliegue de IPv6, menos dependerás del CGNAT y más simple será tu red. La combinación correcta para un ISP hoy es CGNAT bien dimensionado para IPv4 + IPv6 nativo creciendo en paralelo.

Checklist antes de desplegar CGNAT en producción

• Definir la relación de sobresuscripción y el tamaño de bloque de puertos por abonado.
• Elegir NAT determinístico si necesitas trazabilidad sin logs masivos.
• Dimensionar RAM y capacidad de conntrack para el peak real, no el promedio.
• Documentar la tabla de mapeo IP privada → IP pública / rango de puertos.
• Tener el plan de IPv6 andando en paralelo, no "para después".

CGNAT bien hecho es transparente para el abonado y sostenible para el operador; mal hecho es una fuente silenciosa de reclamos y un riesgo legal. En MikroTik Chile diseñamos e implementamos CGNAT sobre RouterOS para ISPs y WISPs, dimensionando el equipo, el pool de puertos y la trazabilidad según tu base de abonados real, con IPv6 integrado al plan. Si estás por desplegarlo o ya tienes una implementación que se cae en hora peak, conversemos sobre tu caso.