CAPsMAN MikroTik: WiFi gestionado y centralizado en RouterOS

Si administras una red con más de tres o cuatro puntos de acceso MikroTik, ya conoces el problema: cambiar la contraseña del SSID corporativo significa entrar equipo por equipo, la configuración se desincroniza entre APs con el tiempo, y cuando un cliente reclama que "el WiFi anda lento en la sucursal" no tienes visibilidad centralizada de qué radio está saturado. CAPsMAN es la respuesta de RouterOS a ese dolor. En esta guía repasamos qué es CAPsMAN MikroTik, las dos implementaciones que conviven hoy en RouterOS v7, y cómo se arma un despliegue de WiFi gestionado pensado para oficinas, retail, sucursales e ISPs, no para el hogar.

Qué es CAPsMAN y por qué centralizar el WiFi

CAPsMAN significa Controlled Access Point system Manager. La idea es simple y potente: en lugar de configurar cada punto de acceso de forma autónoma, defines toda la política inalámbrica (SSIDs, seguridad, canales, VLANs) una sola vez en un controlador, y los puntos de acceso —llamados CAP (Controlled Access Point)— la reciben y la aplican automáticamente al conectarse. El controlador puede ser un router que ya tengas en el core, una CHR o un equipo dedicado; no necesita radios propias.

La comunicación entre el CAPsMAN y sus CAPs ocurre a nivel de capa 2 mediante un protocolo propio de MikroTik (ethertype 0x88BB), o sobre IP cuando el AP está en otra subred. Esto habilita el beneficio operativo real de CAPsMAN MikroTik: cambias un parámetro en el controlador y se propaga a decenas de APs sin tocarlos uno por uno. Para quien opera una red distribuida, eso se traduce en menos ventanas de mantención, configuración consistente y una única fuente de verdad.

• Provisioning automático: un AP nuevo se enrola, se identifica y recibe su configuración sin intervención manual.
• Gestión de SSID y seguridad centralizada: rotar una passphrase o migrar a WPA3 es un solo cambio.
• Visibilidad: tabla de registros de clientes, estado de cada radio y roaming, todo desde el controlador.
• Reemplazo en frío: si un AP muere, el repuesto se enrola y hereda la misma configuración por regla de provisioning.

Las dos CAPsMAN de RouterOS: cuál corresponde a tu hardware

Aquí está el punto que más confusión genera en terreno, y conviene tenerlo claro antes de comprar equipos. En RouterOS v7 conviven dos implementaciones de CAPsMAN que no son interoperables entre sí: un CAP del menú nuevo solo se une a un CAPsMAN del menú nuevo, y un CAP legacy solo a un CAPsMAN legacy.

La regla práctica: si tu hardware es reciente (hAP ax, cAP ax, la familia con WiFi 6/7), usarás el menú /interface/wifi, que además es el único que te da WPA3 y fast roaming. Los equipos con el chipset y paquete wireless clásico siguen con /caps-man. Si tienes un parque mixto, planifica dos controladores o una migración por etapas; no intentes mezclarlos bajo un mismo CAPsMAN. Si no estás seguro de en qué categoría cae tu inventario, en nuestra página de infraestructura inalámbrica detallamos cómo lo abordamos por generación de equipo.

Anatomía de un despliegue CAPsMAN

Independiente de la implementación, la arquitectura lógica es la misma y se compone de cuatro piezas: el manager (habilita el controlador), la configuration (el perfil que agrupa SSID, seguridad y canal), el datapath (cómo se reenvía el tráfico del cliente) y las reglas de provisioning (qué configuración recibe cada AP que se enrola).

Veamos un ejemplo mínimo en el menú actual /interface/wifi. Primero, en el controlador definimos un perfil y activamos el CAPsMAN:

# --- En el controlador (CAPsMAN) ---
/interface/wifi/configuration
add name=cfg-corp mode=ap ssid="Empresa-Corp" \
    security.authentication-types=wpa2-psk,wpa3-psk \
    security.passphrase="clave-robusta-aqui"

/interface/wifi/capsman
set enabled=yes interfaces=all \
    ca-certificate=auto certificate=auto

# Regla: todo AP que se enrole recibe cfg-corp de forma dinámica
/interface/wifi/provisioning
add action=create-dynamic-enabled master-configuration=cfg-corp

Con certificate=auto y ca-certificate=auto, el controlador genera su propia CA y certificado para cifrar el canal de control CAPsMAN-CAP. Del lado del punto de acceso, la configuración es igual de breve:

# --- En cada punto de acceso (CAP) ---
/interface/wifi/cap
set enabled=yes \
    discovery-interfaces=bridgeLocal \
    caps-man-addresses=10.0.0.1

El AP usa discovery-interfaces para descubrir al controlador por capa 2, o caps-man-addresses para apuntar directo a su IP cuando está en otra subred. Al conectarse, sus radios aparecen en el controlador, la regla de provisioning las evalúa y —si hacen match— crea las interfaces WiFi dinámicas con el perfil cfg-corp. No configuraste el SSID en el AP: lo heredó.

En equipos con el paquete wireless, el flujo conceptual es idéntico pero con la sintaxis legacy: /caps-man manager set enabled=yes certificate=auto, perfiles separados en /caps-man configuration, /caps-man security y /caps-man datapath, y el AP se activa con /interface wireless cap.

Datapath: forwarding local vs. central y VLAN por SSID

Una decisión de diseño que define el rendimiento de tu red es dónde se procesa el tráfico de los clientes. CAPsMAN ofrece dos modos:

• Forwarding local: el tráfico del cliente se entrega a la LAN directamente en el AP (se pone en un bridge local). El controlador solo gestiona; los datos nunca lo atraviesan. Es lo que quieres en la mayoría de despliegues empresariales: escala bien y no conviertes al controlador en cuello de botella.
• Forwarding central: el tráfico se tuneliza desde cada AP hasta el CAPsMAN, que lo entrega a la red. Útil cuando necesitas un punto único de aplicación de políticas, pero concentra carga y ancho de banda en el controlador.

El objeto datapath es también donde amarras cada SSID a su VLAN. En el modelo legacy lo expresas con vlan-mode=use-tag y vlan-id=20 dentro de /caps-man datapath; en el menú nuevo, el datapath del perfil de configuración cumple el mismo rol. Así separas, por ejemplo, el SSID corporativo (VLAN 20), el de invitados con Hotspot (VLAN 90) y el de dispositivos IoT (VLAN 110), todo entregado con etiqueta 802.1Q al switch, sin cablear ni configurar VLANs AP por AP. Esta integración WiFi + VLAN + bridge es donde CAPsMAN deja de ser "administrar APs" y pasa a ser parte del diseño de red; si el tramo cableado y el troncal de VLANs no están bien resueltos, el WiFi tampoco lo estará, y por eso solemos revisarlo junto en una tarea de soporte.

Provisioning a escala y operación diaria

La verdadera potencia de CAPsMAN MikroTik aparece cuando tienes decenas de APs. Las reglas de provisioning no tienen por qué ser una sola: puedes discriminar qué configuración entregas según atributos del AP que se enrola. Los criterios de match disponibles incluyen:

• identity-regexp — por nombre del equipo (ej. todos los que empiezan con cap-piso3-).
• common-name-regexp — por el common name del certificado del AP.
• address-ranges / ip-address-ranges — por rango de IP de gestión.
• radio-mac — para fijar una configuración a una radio específica.

Con esto, un mismo controlador aprovisiona planta por planta o sede por sede con perfiles distintos. La acción create-dynamic-enabled hace que las interfaces se creen y borren solas según el AP esté conectado, dejando la configuración del controlador limpia. Y con el parámetro upgrade-policy (por ejemplo require-same-version) el controlador puede forzar que los CAP corran la misma versión de RouterOS que él, evitando el clásico problema del parque con firmware disparejo.

En la operación diaria, todo lo observas desde el controlador: la lista de remote-cap te muestra cada AP conectado con su modelo, serie y uptime; la tabla de registros lista cada cliente asociado con su SSID, tasa de datos y señal. Un comando de provision reevalúa las reglas sin reiniciar nada, y si migras a WPA3 o rotas la passphrase, el cambio baja a todos los APs de golpe. Ese es el modelo de operación que buscas cuando el WiFi es parte de un servicio y no un accesorio.

Cuándo CAPsMAN suma y cuándo revisar el diseño

CAPsMAN brilla en despliegues multi-AP donde la consistencia y la operación centralizada importan: retail con varias tiendas, edificios de oficinas, campus, hotelería, o un ISP/WISP que ofrece WiFi gestionado a sus clientes empresa. En cambio, para un único AP no aporta gran cosa, y en redes densas con requisitos de roaming exigentes hay que dimensionar bien canales, potencia y solapamiento de celdas —CAPsMAN centraliza la gestión, pero no compensa un plan de RF mal hecho ni un troncal cableado sin VLANs. La decisión legacy vs. WifiWave2, el modo de forwarding y el esquema de VLANs son las tres definiciones que conviene cerrar antes de desplegar.

En MikroTik Chile diseñamos, implementamos y operamos WiFi gestionado con CAPsMAN sobre RouterOS para empresas e ISPs, integrado con el resto de la red: VLANs, firewall, Hotspot y monitoreo. Si estás evaluando centralizar tu inalámbrico o migrar un parque legacy a WiFi 6/7 con WPA3, conversemos tu caso con un ingeniero en una sesión de consultoría y lo revisamos a nivel de topología.