Captive Portal for Cisco Meraki

Bienvenido a la serie de informes técnicos de Purple. Soy su anfitrión, y hoy cubriremos algo que surge en casi todas las implementaciones de WiFi para invitados empresariales en las que trabajamos: la configuración de un Captive Portal en los puntos de acceso Cisco Meraki MR, y específicamente cómo integrar eso con la plataforma en la nube de Purple mediante la autenticación RADIUS. Ya sea que sea un MSP que incorpora a un nuevo cliente de hotelería o un arquitecto de redes interno en una cadena de retail, este episodio le brindará los pasos de configuración precisos y el razonamiento detrás de cada uno. Pongamos el escenario. Tiene un recinto (podría ser un hotel, un centro de conferencias, un estadio o un parque comercial) que ejecuta puntos de acceso Cisco Meraki MR administrados a través del Meraki Dashboard. El objetivo es implementar una experiencia de WiFi para invitados con marca propia que capture datos de origen, exija la aceptación de los términos de servicio y envíe análisis a una plataforma de marketing. Eso es exactamente para lo que Purple está diseñado, y Meraki es una de nuestras implementaciones de hardware más comunes a nivel mundial. Ahora, el punto arquitectónico clave que debe comprender antes de tocar una sola configuración es este: en Cisco Meraki, la autenticación RADIUS para una página de bienvenida no es procesada localmente por el punto de acceso. El RADIUS Access-Request se origina desde la nube de Meraki (desde la infraestructura del Dashboard), no desde el AP en su LAN. Esta es una distinción crítica que confunde a muchos ingenieros en su primera implementación de Meraki. Significa que su servidor RADIUS, en este caso el endpoint RADIUS en la nube de Purple, debe ser accesible desde Internet, y las reglas de su firewall deben permitir el tráfico desde los rangos de IP del Dashboard de Meraki, no solo desde la subred de su AP local. Encontrará los rangos de IP actuales del Dashboard en la sección Help y luego en Firewall Info dentro de su Meraki Dashboard. Bien, entremos en la configuración. Lo guiaré a través de esto en el orden en que realmente lo haría en una implementación real. Paso uno: configuración del SSID. En el Meraki Dashboard, navegue a Wireless, luego a Configure y después a SSIDs. Seleccione la ranura de SSID que desea usar para el acceso de invitados. Asígnele un nombre claro, algo como GuestWiFi o NombreDelRecinto guion bajo Guest. En Association requirements, configure Security en Open, no encryption. Esto es correcto e intencional: la capa de seguridad para los invitados se maneja mediante el Captive Portal y la autenticación RADIUS, no mediante el cifrado WPA. Si está realizando la implementación en un entorno PCI DSS, querrá asegurarse de que el tráfico de invitados esté aislado en su propia VLAN, lo cual cubriremos en breve. Paso dos: Splash page y autenticación. Aún en la página de Access Control para su SSID, desplácese hacia abajo hasta la sección de Splash page. Establézcalo en Sign-on with y, en el menú desplegable, seleccione my RADIUS server. Esta es la configuración crítica que le indica a Meraki que autentique a los usuarios contra un servidor RADIUS externo antes de otorgar acceso a la red. Debajo de eso, verá la opción Captive portal strength. Establézcala en Block all access until sign-on is complete. Esto es lo que aplica el walled garden; sin esto, los invitados podrían evadir el portal por completo. Paso tres: Configuración del servidor RADIUS. En la sección RADIUS, haga clic en Add server. Necesitará tres datos de su cuenta de Purple: la dirección IP o FQDN del servidor RADIUS, el puerto de autenticación que es UDP 1812 y el shared secret. Purple proporciona estos datos en la sección de configuración del punto de venta del portal. Para contar con redundancia en implementaciones de producción, debe agregar un servidor RADIUS secundario; Purple proporciona un endpoint de failover. Establezca el puerto de contabilidad (accounting port) en UDP 1813 si desea que los datos de la sesión se envíen de vuelta al motor de analítica de Purple, lo cual recomiendo ampliamente para cualquier establecimiento donde el tiempo de permanencia y la duración de la sesión sean métricas significativas. Una nota rápida sobre los atributos RADIUS. Meraki respeta el atributo Session-Timeout devuelto en la respuesta RADIUS Access-Accept. Purple utiliza esto para controlar cuánto dura la sesión de un invitado antes de que se requiera una nueva autenticación. Para un hotel, podría establecer esto en 86,400 segundos (es decir, 24 horas). Para una cafetería, algo como 3,600 segundos (una hora) es más adecuado. El atributo Idle-Timeout también se respeta, pero solo si la contabilidad RADIUS está habilitada. Esto desconecta las sesiones inactivas, lo cual es importante para la gestión de capacidad en establecimientos de alta densidad. Paso cuatro: URL de la Splash page. Diríjase a Wireless, luego a Configure y después a Splash page. Seleccione su SSID de invitados en el menú desplegable. Establezca la Custom splash URL con la URL del portal de Purple para su establecimiento. Esta es la URL a la que Meraki redirigirá a los clientes no autenticados. Meraki añade parámetros de consulta a esta URL, incluido un parámetro login_url, que Purple utiliza para completar el proceso de autenticación. No modifique ni elimine estos parámetros. Paso cinco: el walled garden. Aquí es donde la mayoría de las implementaciones tienen problemas. El walled garden es la lista de dominios y rangos de IP a los que un dispositivo invitado puede acceder antes de haberse autenticado. Sin las entradas correctas, la página del Captive Portal no se cargará, ya que el navegador no podrá comunicarse con la CDN de Purple ni con los proveedores de inicio de sesión social. Navegue de regreso a Access Control para su SSID de invitados. Establezca Walled garden en Walled garden is enabled. En el campo Walled garden ranges, debe agregar lo siguiente. Primero, los dominios de la plataforma Purple: star punto purple punto ai y star punto venuewifi punto com. Segundo, los dominios de CDN que Purple utiliza para servir los recursos del portal: star punto cloudfront punto net y star punto akamaihd punto net. Tercero, la infraestructura de redireccionamiento de Meraki: star punto network-auth punto com. Cuarto, si ofrece opciones de inicio de sesión con redes sociales, necesita los dominios de OAuth correspondientes. Para Google: accounts punto google punto com, star punto googleapis punto com, star punto gstatic punto com. Para Facebook: star punto facebook punto com, star punto fbcdn punto net y connect punto facebook punto net. Para Twitter o X: star punto twitter punto com y star punto twimg punto com. Una nota importante sobre cómo maneja Meraki los dominios con comodines en el walled garden. Meraki sí admite entradas con comodines utilizando el prefijo de asterisco, por ejemplo, star punto cloudfront punto net. Sin embargo, esta es una coincidencia basada en DNS: Meraki resuelve el dominio y permite las direcciones IP resultantes. Esto significa que para los proveedores de CDN como CloudFront o Akamai, donde las direcciones IP resueltas pueden cambiar con frecuencia, debe usar el comodín de dominio en lugar de rangos de IP estáticos. Las entradas de IP estáticas están bien para los endpoints RADIUS de Purple, que son estables, pero no para el tráfico de CDN. Ahora hablemos de dos escenarios del mundo real en los que he trabajado directamente. El primero es un hotel de 350 habitaciones en el Reino Unido. El cliente utilizaba puntos de acceso Meraki MR46 en tres edificios, con unos 400 dispositivos de invitados simultáneos en las horas pico. El despliegue inicial utilizaba una página de bienvenida de tipo click-through: sin RADIUS, solo aceptación de términos. El problema era que no tenían ninguna visibilidad de quién se conectaba, no capturaban correos electrónicos y no tenían forma de realizar campañas de marketing posteriores a la estancia. Los migramos a Purple con inicio de sesión basado en RADIUS. La configuración fue sencilla, pero el inconveniente fue que su firewall ascendente estaba bloqueando el UDP saliente en el puerto 1812 hacia cualquier dirección fuera de la subred local. Una vez que agregamos los rangos de IP del Dashboard de Meraki a la lista de permitidos del firewall, la autenticación funcionó de inmediato. Tras el despliegue, el hotel capturó las direcciones de correo electrónico de aproximadamente el 68 por ciento de los huéspedes que se conectaron en el primer mes, y su equipo de marketing ejecutó una campaña de reactivación que generó un aumento medible en las reservas directas. El segundo escenario es una cadena de retail con 45 tiendas, cada una con puntos de acceso Meraki MR33. El desafío aquí era la escala y la consistencia. Configurar manualmente 45 SSIDs con los ajustes de RADIUS correctos y las listas de walled garden habría sido propenso a errores y habría consumido mucho tiempo. La solución fue utilizar la configuración basada en plantillas de Meraki. Creamos una única plantilla de red con los ajustes correctos de SSID, RADIUS y walled garden, y luego vinculamos las 45 redes de las tiendas a esa plantilla. Cualquier cambio —por ejemplo, agregar un nuevo proveedor de inicio de sesión social al walled garden— se realiza una sola vez en la plantilla y se propaga a todas las tiendas automáticamente. Los análisis de Purple luego agregaron los datos de afluencia y tiempo de permanencia de todas las tiendas, lo que brindó al equipo de operaciones de retail una vista de panel único del comportamiento de los clientes por tienda, por región y por hora del día. Permítame darle tres reglas prácticas que le ahorrarán tiempo en cada implementación de Captive Portal de Meraki. Regla uno: Siempre verifique los rangos de IP del Dashboard de Meraki antes de configurar RADIUS. Los rangos cambian ocasionalmente y, si su firewall los está bloqueando, la autenticación fallará silenciosamente desde la perspectiva del usuario; simplemente verán que la página del portal se congela. Utilice la herramienta de prueba de RADIUS integrada en el Dashboard bajo Access Control para verificar la conectividad antes de entrar en producción. Regla dos: Utilice comodines de dominio en el walled garden, no rangos de IP, para cualquier contenido alojado en CDN. Los rangos de IP de CDN son grandes y cambian con frecuencia. Una entrada de dominio con comodín es más fácil de mantener y más confiable. Regla tres: Habilite la contabilidad de RADIUS en el puerto 1813 incluso si cree que aún no la necesita. Los datos de sesión son valiosos para solucionar problemas de desconexión y para alimentar métricas precisas de tiempo de permanencia en su plataforma de análisis. No cuesta nada habilitarlo y es muy difícil de adaptar después del hecho. Ahora, algunas preguntas rápidas que me hacen con regularidad. ¿Puedo usar la página de bienvenida integrada de Meraki en lugar de Purple? Sí, pero perderá la captura de datos, los análisis, la automatización de marketing y la gestión de consentimiento que cumple con el GDPR. La página de bienvenida integrada está bien para un clic básico, pero no es una plataforma de inteligencia de clientes. ¿Funciona esta configuración en los firewalls Meraki MX así como en los puntos de acceso MR? La configuración de la página de bienvenida de RADIUS es compatible con los puntos de acceso MR. Los dispositivos MX manejan la autenticación VPN del cliente de manera diferente. Específicamente para el WiFi de invitados, estará configurando los SSIDs de MR. ¿Qué pasa con WPA3? Los puntos de acceso Meraki MR son compatibles con WPA3 en SSIDs empresariales. Para implementaciones de Captive Portal de invitados, el SSID suele ser Open, por lo que WPA3 no se aplica directamente. Sin embargo, si está implementando un SSID de Passpoint o OpenRoaming junto con su SSID de Captive Portal —lo cual es compatible con Purple—, ese SSID utiliza WPA3-Enterprise con 802.1X, y ahí es donde WPA3 se vuelve relevante. Para resumir: la integración de Cisco Meraki y Purple está bien probada y es confiable, pero requiere atención en tres aspectos: el enrutamiento de la IP de origen de RADIUS, la configuración completa del walled garden y la configuración del tiempo de espera de la sesión. Si se configuran correctamente estos tres elementos, la implementación es sencilla. El caso de negocio es claro: los establecimientos que implementan una plataforma de WiFi para invitados configurada correctamente con captura de datos obtienen de manera constante retornos medibles en el engagement de marketing y en la información operativa. Si desea profundizar más, consulte la guía de Purple sobre cómo implementar la autenticación 802.1X con RADIUS en la nube, y nuestra guía de implementación de AP inalámbricos de Cisco en el blog de Purple. Ambos enlaces se encuentran en las notas del programa. Gracias por escuchar. Si tiene un escenario de implementación específico que le gustaría que cubramos, póngase en contacto con el equipo técnico de Purple. Nos vemos en el próximo episodio.