Corte automático de morosos en MikroTik: address-list, walled-garden y CoA

Cortar morosos a mano es de los peores usos del tiempo del dueño de un WISP: abrir Winbox, buscar al cliente, deshabilitar el secret o la cola, anotarlo en una planilla... y repetirlo al revés cuando llega la captura de la transferencia. Peor todavía: el cliente cortado "a lo bruto" no sabe por qué no tiene internet, así que llama furioso o llama al soporte — que eres tú también. Esta guía muestra el patrón profesional para suspender morosos en MikroTik RouterOS: bloqueo por address-list, walled-garden con página de aviso de pago, y automatización real con RADIUS y CoA.

1. Por qué NO deshabilitar el secret ni borrar la cola

Las dos formas más comunes de cortar un moroso son también las peores:

• Deshabilitar el ppp secret: el cliente queda sin sesión, sin IP y sin forma de ver un aviso. Para él "se dañó el internet". Y al reactivarlo esperas a que su CPE reintente la sesión.
• Borrar o deshabilitar la cola: el cliente sigue navegando gratis (si solo quitaste la cola) o queda igual de ciego. Además, tocar colas por cobranza es mezclar QoS con negocio — dos planos que no deben cruzarse.

El patrón correcto separa la identidad (la sesión PPPoE sigue viva) del permiso de navegar (una address-list). Suspender = agregar la IP a la lista MOROSOS. Reactivar = sacarla. Nada más se toca.

2. La arquitectura: address-list + walled-garden

1. El cliente moroso entra a la address-list MOROSOS.
2. Reglas de firewall en forward bloquean todo su tráfico excepto lo esencial: DNS y el servidor donde vive la página de pago (el walled-garden).
3. Un dst-nat redirige su tráfico HTTP a la página de aviso: "Tu servicio está suspendido por falta de pago. Paga aquí."
4. Al pagar, la IP sale de la lista y el servicio vuelve solo — la sesión nunca se cayó.

3. Firewall del walled-garden

# Lista de servidores permitidos al moroso (pagina de pago, pasarela)
/ip firewall address-list add list=WALLED-GARDEN address=203.0.113.10 comment="servidor pagina de pago"

# Permitir DNS al moroso (sin DNS no resuelve ni la pagina de aviso)
/ip firewall filter add chain=forward src-address-list=MOROSOS protocol=udp dst-port=53 action=accept comment="MOROSOS: permitir DNS"

# Permitir el walled-garden
/ip firewall filter add chain=forward src-address-list=MOROSOS dst-address-list=WALLED-GARDEN action=accept comment="MOROSOS: permitir pagina de pago"

# Bloquear TODO lo demas del moroso
/ip firewall filter add chain=forward src-address-list=MOROSOS action=drop comment="MOROSOS: drop resto"

# Redirigir su HTTP a la pagina de aviso de pago
/ip firewall nat add chain=dstnat src-address-list=MOROSOS protocol=tcp dst-port=80 dst-address-list=!WALLED-GARDEN action=dst-nat to-addresses=203.0.113.10 to-ports=80 comment="MOROSOS: redirect HTTP a aviso"

4. El gotcha que rompe todo: FastTrack

Este es el error #1 que vemos en redes que "implementaron el corte y no funciona": FastTrack hace bypass del firewall para conexiones establecidas. Si la conexión del moroso ya estaba fasttrackeada, tu regla de drop nunca la ve — el cliente suspendido sigue viendo Netflix tan campante.

# La regla fasttrack-connection NO debe aplicar a morosos
/ip firewall filter set [find action=fasttrack-connection] src-address-list=!MOROSOS

# Al suspender, limpiar las conexiones existentes del cliente
# (si no, las establecidas siguen vivas hasta expirar)
/ip firewall connection remove [find src-address~"10.10.0.55"]

5. HTTPS: lo que el redirect NO puede hacer

Seamos honestos con la limitación técnica: el redirect transparente solo funciona con HTTP (puerto 80). El tráfico HTTPS no se puede interceptar para mostrar tu página — el navegador mostraría un error de certificado, y eso es por diseño de TLS, no un defecto de MikroTik. En la práctica el aviso llega igual por tres vías que sí funcionan:

• El primer sitio HTTP que toque el navegador o el sistema (detección de portal cautivo del teléfono) cae en tu página de aviso.
• La notificación de WhatsApp/SMS con el link directo de pago — que debe salir del sistema de facturación al suspender, no depender del navegador.
• El link de pago está permitido en el walled-garden, así que el cliente siempre puede llegar a pagar.

6. Suspensión manual (mientras no hay sistema)

# Suspender: agregar la IP del cliente a MOROSOS
/ip firewall address-list add list=MOROSOS address=10.10.0.55 comment="cliente001 - factura 2026-07 vencida"

# Limpiar sus conexiones establecidas
/ip firewall connection remove [find src-address~"10.10.0.55"]

# Reactivar: sacar la IP de la lista
/ip firewall address-list remove [find list=MOROSOS and address="10.10.0.55"]

# Ver quien esta suspendido
/ip firewall address-list print where list=MOROSOS

7. Automatización real: RADIUS + CoA (sin cortar la sesión)

El corte manual escala mal. La versión profesional usa RADIUS: el atributo Mikrotik-Address-List mete al abonado en la lista correcta al autenticar, y CoA (Change of Authorization) lo mueve de ACTIVOS a MOROSOS en caliente — lo hemos validado en producción sobre RouterOS 7.23: la sesión PPPoE del cliente no se corta, solo cambia su address-list al instante. La reconexión es el mismo mecanismo al revés.

# En el BNG: aceptar CoA/Disconnect del servidor RADIUS (puerto 3799)
/radius incoming set accept=yes port=3799

# Regla input para permitir CoA SOLO desde el RADIUS
/ip firewall filter add chain=input src-address=10.99.200.250 protocol=udp dst-port=3799 action=accept place-before=0 comment="CoA desde RADIUS"

El disparador de todo es el sistema de facturación: la fecha de vencimiento vence → el sistema manda el CoA de suspensión y la notificación de WhatsApp → el cliente paga (QR/transferencia) → el sistema registra el pago y manda el CoA de reactivación. Cero intervención humana. La base de la integración RADIUS está en nuestra guía de User Manager en ROS 7 y la parte PPPoE en la guía de PPPoE Server.

8. Troubleshooting