Configurar y probar Captive Portal en Sophos Firewall

Captive Portal autentica a usuarios que ya están conectados a una LAN o red Wi-Fi. Después, Sophos Firewall puede asociar su tráfico a una identidad y aplicar reglas a usuarios o grupos concretos.

La interacción es importante: el portal crea la asignación de usuario, pero no concede por sí mismo acceso a Internet. También se necesita una regla de firewall adecuada. DNS, routing, NAT y la segmentación de red deben funcionar de forma independiente.

El proceso completo se resume en seis pasos:

1. Comprobar la fuente de autenticación y el grupo permitido.
2. Autorizar Captive Portal para la zona del cliente en Administration > Device access.
3. Si se utiliza un servidor DNS externo, crear una regla DNS limitada sin referencia al usuario.
4. Crear una regla de usuario con Match known users y Use web authentication for unknown users.
5. Definir HTTPS, página de destino y cierre de sesión en Authentication > Web authentication.
6. Comprobar el login por el puerto 8090, el usuario en Live users y la Rule ID en Log Viewer.

Qué hace Captive Portal y qué no hace

Captive Portal es adecuado para dispositivos BYOD, clientes no administrados o redes sin detección transparente de usuarios. El usuario abre una página web, es redirigido al login y queda vinculado en el firewall a su IP de origen. El firewall puede utilizar esa identidad como criterio de coincidencia.

Otros portales y métodos de autenticación resuelven tareas distintas:

• Un Wireless Hotspot está pensado para accesos de invitados con vouchers, contraseña diaria o condiciones de uso. El procedimiento completo está en Configurar Sophos Firewall Hotspot.
• Un Guest user es una cuenta local temporal para Captive Portal. Crear y operar de forma segura usuarios invitados explica el grupo, la validez, la entrega de credenciales, el autorregistro y la limpieza.
• VPN Portal pertenece a Remote Access. Captive Portal no crea un túnel VPN y no debe utilizarse como portal público de login.
• STAS, AD SSO o SATC detectan usuarios sin login en el navegador siempre que sea posible. Captive Portal puede actuar como alternativa para dispositivos que la detección transparente no identifica.
• Para iniciar sesión con Microsoft se aplica el procedimiento específico Captive Portal con Microsoft Entra ID SSO.

La descripción general de los portales de Sophos ayuda a distinguir User Portal, VPN Portal, WebAdmin y Captive Portal.

⚠️ Captive Portal no sustituye la segmentación. Una red BYOD o de invitados permanece en su propia zona o VLAN y solo accede a los destinos y servicios necesarios. El login mejora la asignación de usuarios, pero no convierte automáticamente una red demasiado amplia en una red segura.

Requisitos y ejemplo

Antes de configurar deben estar claros estos puntos:

• Funciona una fuente de autenticación local o externa. Con Active Directory ya se han probado la conexión al servidor y el grupo; Conectar Active Directory a Sophos Firewall explica la configuración.
• Se conocen la zona del cliente, la red de origen y el grupo de usuarios permitido.
• El cliente recibe una dirección IP, un gateway y servidores DNS correctos.
• Para el nombre productivo del portal existen un registro DNS y un certificado aceptado por los clientes.
• Una regla MASQ/SNAT existente y el routing cubren el tráfico de Internet que se permitirá después.
• Hay un usuario permitido y otro no permitido para la prueba de aceptación.

El ejemplo utiliza:

• Zona del cliente: LAN
• Red del cliente: 10.30.40.0/24
• Objeto de red: BYOD_10.30.40.0_24
• IP del firewall en la zona del cliente: 10.30.40.1
• Grupo de usuarios: BYOD_Internet
• Nombre de la regla: LAN-BYOD-to-WAN-Captive
• Servidor DNS interno: 10.20.0.53
• Nombre del portal: login.example.com

Estos valores no se copian sin comprobarlos. Zona y red deben corresponder a la interfaz real del cliente, 10.30.40.1 se sustituye por su IP de firewall y el grupo debe proceder de la fuente de autenticación utilizada. Desde la red del cliente, el nombre del portal debe resolver exactamente a esa dirección accesible del firewall.

Configurar Captive Portal paso a paso

1. Seleccionar el método de autenticación

En Authentication > Services, Firewall authentication methods define qué fuentes consulta el firewall durante el login. Puede ser la base de datos local o un servidor AD, LDAP o RADIUS ya configurado. Crear y probar usuarios locales normales explica el grupo, la contraseña, Local, Sign-in Restriction y el ciclo de vida de este modelo. El orden es relevante: si hay varios servidores, SFOS los comprueba de arriba abajo.

Para el ejemplo, el grupo BYOD_Internet debe existir en el firewall. Con Active Directory se importa previamente. Solo entonces puede seleccionarse en la regla de usuario y asignarse de forma inequívoca durante la prueba.

Una conexión correcta al servidor no basta. Por eso, más adelante se comprueba con un login real que contraseña, grupo y regla de usuario funcionan juntos.

2. Autorizar Captive Portal para la zona de origen

En Administration > Device access, en la fila Captive portal, se activan únicamente las zonas desde las que los usuarios deben iniciar sesión. En el ejemplo es LAN. Después, guardar con Apply.

Device Access controla el acceso a un servicio local del firewall. Una regla LAN-to-WAN normal no sustituye esta autorización. Captive Portal tampoco debe habilitarse preventivamente para WAN u otras zonas internas. Device Access y Local Service ACL también explica la excepción del Web Proxy, que puede hacer accesibles los portales locales a pesar de una tabla de zonas más restrictiva.

Si los clientes utilizan el propio firewall como resolver DNS, DNS también debe estar permitido para su zona en la misma matriz. Con un servidor DNS separado se necesita la siguiente regla de tránsito.

3. Permitir DNS antes del login

El navegador solo puede abrir login.example.com o la web solicitada si DNS ya funciona antes de la autenticación. Si el servidor DNS no está en el firewall, se crea una regla en Rules and policies > Firewall rules > Add firewall rule > New firewall rule:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: zona del servidor DNS
• Destination networks: objeto de host para 10.20.0.53
• Services: DNS
• Log firewall traffic: activar para la prueba

Esta regla no tiene condición de usuario porque el cliente todavía no está autenticado. Solo permite DNS al resolver previsto, no tráfico arbitrario antes del login. Si hay varios servidores DNS, se añaden sus objetos de host de forma específica.

La regla DNS se coloca de modo que el resolver sea accesible antes del login. En el ejemplo queda justo antes de la regla de usuario y por encima de cualquier regla general que descarte o trate de otro modo el DNS de esta red. Después se guarda con Save.

Sobre la tabla de reglas se selecciona el protocolo correspondiente, IPv4 o IPv6. Si los clientes solo alcanzan el resolver por IPv4, basta con la regla DNS IPv4. Si también utilizan DNS por IPv6, se crea una regla IPv6 igual de limitada con los objetos de red y host IPv6 adecuados.

4. Crear la regla de usuario

Ahora se crea la regla de acceso propiamente dicha:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: los destinos de Internet necesarios o Any
• Services: solo los servicios necesarios
• Match known users: activado
• Use web authentication for unknown users: activado
• Users or groups: BYOD_Internet
• Log firewall traffic: activado

También aquí se selecciona IPv4 o IPv6 sobre la tabla de reglas. En una red dual stack se crea una regla de usuario independiente, con los objetos de red apropiados, para cada familia de protocolos que se permita realmente; una regla IPv4 no cubre IPv6.

Match known users convierte la identidad en criterio de coincidencia. Use web authentication for unknown users dirige al login una solicitud web coincidente cuyo usuario aún no está autenticado. El grupo determina quién puede usar la regla después del login.

En SFOS 22 y 23, Use web authentication for unknown users no es el único desencadenante de un inicio de sesión. Si la opción está activada, una solicitud web coincidente cuyo usuario aún no está autenticado activa la autenticación. Si está desactivada, este ajuste permite inicialmente la solicitud sin iniciar sesión; sin embargo, una Web Policy asignada puede seguir bloqueándola y activar así la autenticación web. Lo decisivo es si una Web Policy para usuarios o grupos desconocidos está configurada en Block. El proceso posterior depende de AD SSO:

• Con AD SSO, tanto si la autenticación se activa mediante la regla como si se debe a Block en la Web Policy para usuarios desconocidos: SFOS intenta primero el inicio de sesión transparente. Si falla, redirige a Captive Portal. Tras iniciar sesión correctamente, se vuelve a cargar la página y se evalúa de nuevo la Web Policy del usuario.
• Sin AD SSO, con activación mediante la regla: la solicitud web coincidente cuyo usuario aún no está autenticado se redirige directamente a Captive Portal.
• Sin AD SSO, solo con bloqueo mediante la Web Policy: aparece una página de bloqueo. En ella puede mostrarse un enlace a Captive Portal; en este caso no debe esperarse una redirección automática como la que se produce con la activación mediante la regla.

Por tanto, ante un login inesperado o una página de bloqueo, se comprueban primero de forma conjunta la regla que realmente ha coincidido en Log Viewer, el ajuste de esa regla, la Web Policy para usuarios o grupos desconocidos y el estado de AD SSO en Authentication > Web authentication. Antes de realizar cambios, se documentan los valores actuales. La prueba se realiza con un cliente piloto sin sesión existente y únicamente para el acceso previsto para ese cliente: no se debe eliminar Block de forma general, flexibilizar las reglas de usuario ni cambiar AD SSO globalmente solo para forzar una redirección. Después del login, se comprueban Current activities > Live users, el usuario y la Rule ID en Log Viewer, así como un destino permitido y otro que deba seguir bloqueado. Si el comportamiento es inesperado, se restauran los valores modificados y se repiten las mismas comprobaciones.

En Services, Any solo tiene sentido si el grupo realmente necesita acceso completo a Internet. Para un acceso limitado se seleccionan conscientemente HTTP, HTTPS y otros protocolos necesarios. El tráfico no web no puede mostrar una página de login; primero hay que autenticarse con un navegador o con la URL directa del portal.

La regla debe estar por encima de una regla Allow amplia basada en IP. De lo contrario, esa regla anterior procesa el tráfico y la regla de usuario no se evalúa. Tras comprobar la posición, guardar con Save. Planificar correctamente las reglas de firewall explica la evaluación básica.

5. Definir HTTPS, redirección y cierre de sesión

Authentication > Web authentication no activa el acceso al portal, sino que configura su comportamiento.

Captive Portal admite como máximo 50 caracteres tanto para el nombre de usuario como para la contraseña. Conviene probar este límite con una cuenta real antes del despliegue, especialmente con directorios externos y nombres de usuario generados automáticamente.

Para producción son importantes estas decisiones:

• Show user portal link muestra en la página de Captive Portal un enlace a User Portal. Solo se activa si los usuarios necesitan realmente ese portal y debe ser accesible desde su zona.
• Use insecure HTTP instead of HTTPS permanece desactivado. HTTP transmitiría las credenciales sin cifrar. SFOS 22 no admite Microsoft Entra ID SSO con esta opción; en SFOS 23, esta restricción se aplica a OpenID Connect SSO en su conjunto.
• Show web page after sign-in puede redirigir al usuario a la página solicitada originalmente o a una página interna definida.
• Open web page: In new browser window mantiene abierta la página de Captive Portal para logout y keepalives. Si se sustituye la misma pestaña, el cierre de sesión resulta menos visible.
• When captive portal page is closed or redirected cierra la sesión cuando el firewall deja de recibir keepalives. También puede ocurrir tras Sleep o un cambio de red.
• When user is inactive evalúa un periodo y la cantidad de datos transferidos en él. SFOS cierra la sesión del usuario cuyo tráfico queda por debajo del umbral configurado. El periodo y la cantidad se eligen para que el tráfico normal en segundo plano no mantenga activas indefinidamente todas las sesiones obsoletas.
• Never exige cierre manual y puede conservar durante más tiempo asignaciones obsoletas entre usuario e IP.

No hay un timeout universalmente adecuado. Las sesiones más cortas son más importantes en dispositivos compartidos y con usuarios cambiantes; en dispositivos asignados a una persona, el login puede ser menos intrusivo. Cada opción se prueba con Sleep, cambio de Wi-Fi y cierre de sesión manual. Estas opciones locales de cierre de sesión no se aplican a Microsoft Entra ID SSO en SFOS 22 ni a OpenID Connect SSO en su conjunto en SFOS 23.

Antes de la prueba de aceptación, se documentan la versión de SFOS utilizada y el método de inicio de sesión. Las opciones locales de cierre de sesión mencionadas no son un mecanismo adecuado para evitar cierres de sesión inesperados con estos métodos de SSO; esta excepción no permite deducir que la sesión sea ilimitada ni que exista un timeout concreto del IdP. La prueba de SSO se realiza exclusivamente mediante HTTPS con un certificado válido y de confianza. HTTP no se activa ni siquiera para diagnosticar problemas. El inicio de sesión, la asignación visible del usuario y el cierre de sesión se comprueban con una cuenta piloto en el flujo de SSO realmente utilizado, en lugar de dar por supuesto el efecto de los ajustes locales de cierre de sesión.

Además, Authentication > Services > Global settings > Maximum session timeout limita la duración total de los usuarios autenticados. SFOS comprueba la autorización cada tres minutos; Access Policies, Surfing Quota y el límite de transferencia de datos también pueden finalizar una sesión. Este valor global afecta a más métodos que Captive Portal, por lo que se revisan las demás formas de autenticación antes de cambiarlo.

Guardar con Apply.

Device Console también contiene valores globales para las versiones TLS mínimas de Captive Portal, X-Frame-Options y una cadena de cifrado compartida con Web Proxy. Comprobar de forma segura los ajustes HTTP Proxy explica por qué estos valores no son una lista general de tuning y cómo probar y revertir un cambio mediante pruebas del portal y del proxy.

En Captive portal appearance se pueden personalizar el logotipo, los textos y los colores. Si se utiliza Custom HTML en lugar del diseño predeterminado, deben seguir funcionando el marcador <div id="__loginbox"></div> y el bloque request-url especificado por Sophos con su script de redirección. Por eso, el HTML, CSS o JavaScript propio se prueba primero con Preview y después con una cuenta piloto. Un portal visualmente correcto no es un éxito si la plantilla impide el inicio de sesión, la redirección o el cierre de sesión; Reset to default permite deshacer la personalización.

<div id="__loginbox"></div>
<div id="request-url" style="display:none;">{url}</div>
<script>
var redirect_url = document.getElementById("request-url").innerHTML;
</script>

El bloque de script debe situarse inmediatamente antes de </body>.

6. Comprobar el nombre y el certificado del portal

La URL directa de diagnóstico es:

https://<Firewall-IP>:8090

En el ejemplo se puede abrir primero https://10.30.40.1:8090. Para producción, https://login.example.com:8090 es más comprensible si el nombre resuelve al firewall y figura en el certificado.

Abrir la URL con la IP demuestra que el portal es accesible. Sin embargo, si el certificado seleccionado solo cubre login.example.com, el navegador mostrará normalmente un aviso de nombre no coincidente para https://10.30.40.1:8090. No se introducen credenciales después de omitir este aviso. Para validar el nombre del certificado y la cadena de confianza se utiliza la URL FQDN.

Se abre Administration > Admin and user settings. Antes del cambio se anotan el valor actual de Redirect users y el Certificate seleccionado. En Admin console and end-user interaction, bajo Redirect users, se elige después Firewall’s configured hostname o A different hostname; en el ejemplo se introduce login.example.com. En Certificate se selecciona el certificado que cubre ese nombre. Con Check settings se prueba la redirección antes del despliegue. La selección afecta también a otros portales locales. Después del cambio, comprobar WebAdmin, User Portal y VPN Portal.

Si falla alguna de estas pruebas, se vuelven a seleccionar el valor de redirección anotado y el certificado anterior y se guarda con Apply. Después se vuelven a probar la redirección y los portales.

Un certificado de confianza pública evita avisos en dispositivos no administrados. Con una CA interna o firmada por el firewall, la CA debe instalarse como fiable en todos los clientes. Gestionar certificados en Sophos Firewall explica el nombre, la cadena completa y la asignación segura.

Probar completamente el login y la regla de usuario

La prueba comienza con un cliente sin sesión existente. En Current activities > Live users se puede desconectar una sesión de prueba anterior.

1. Comprobar que el cliente tiene una dirección de 10.30.40.0/24, el gateway previsto y el servidor DNS correcto.
2. Abrir directamente https://10.30.40.1:8090 o la URL FQDN preparada. La URL con IP prueba el acceso al portal independientemente de la redirección automática, pero puede generar un aviso de nombre no coincidente si el certificado solo cubre login.example.com. Para validar el certificado se utiliza la URL FQDN.
3. Sin sesión existente, abrir una página HTTP normal y comprobar la redirección a Captive Portal. Una página HTTPS con HSTS guardado no es una prueba fiable.
4. Iniciar sesión con un usuario permitido. Si Sophos MFA local está activo, el token OTP debe registrarse antes en User Portal. Activar MFA para Sophos Firewall explica la configuración.
5. En Current activities > Live users, comprobar nombre de usuario, IP del cliente y tipo de autenticación.
6. Probar una web permitida y, de forma consciente, un destino o servicio no permitido.
7. En Log Viewer, filtrar por la IP del cliente. La entrada debe mostrar el usuario esperado y la Rule ID de LAN-BYOD-to-WAN-Captive.
8. Con un usuario ajeno a BYOD_Internet, comprobar que el login no concede acceso mediante esta regla.
9. Provocar logout, Sleep o cambio de red y comprobar cuándo desaparece el usuario de Live users.

En una red dual stack, la prueba se realiza por separado para IPv4 e IPv6. SFOS mantiene ambas asignaciones de usuario separadas y las dos variantes requieren reglas de firewall adecuadas; una prueba IPv4 correcta no demuestra el acceso IPv6.

Delimitar los errores más habituales

El portal no aparece

Primero se abre la URL directa por el puerto 8090. Si no es accesible, comprobar la zona de origen y Captive portal en Device Access, la IP del cliente, la asignación de zonas, DNS y el FQDN del portal.

Si la URL directa funciona pero el login automático no, con frecuencia una regla más general procesa antes el tráfico o falta Use web authentication for unknown users. Además, solo una solicitud web coincidente puede activar el login; las aplicaciones no web no muestran Captive Portal.

Se rechaza el login

En Authentication > Services, comprobar la fuente y el orden de autenticación. Después revisar la conexión al servidor, la contraseña, el grupo, la cuota y, con MFA local, el registro OTP completo. Los horarios recurrentes permitidos o bloqueados se comprueban por separado con Access Time para usuarios y grupos. El procedimiento de Surfing Quota y Network Traffic Quota muestra si, en cambio, se ha agotado el tiempo de Internet o el volumen de datos consumido.

Si el error no se sitúa claramente en el portal, Solucionar sistemáticamente los errores de autenticación en Sophos Firewall separa la accesibilidad, la selección del servicio, Live Users, la Main Group y el posterior recorrido del tráfico.

Para logins clásicos es relevante access_server.log. oauth_sso_captive.log solo se necesita para Microsoft Entra ID SSO. Logs de servicio de Sophos Firewall explica cómo leerlos sin reiniciar servicios precipitadamente.

Login correcto, pero sin acceso

Un login correcto solo confirma la autenticación. Zona del cliente, red de origen, grupo, destinos, servicios, posición de la regla, NAT y routing también deben coincidir. Log Viewer muestra qué Rule ID procesa realmente el tráfico. Por qué una regla Sophos Firewall no coincide ofrece una comprobación sistemática.

El usuario es desconectado inesperadamente

Comprobar la opción de sign-out y sus umbrales de tiempo y datos, la ventana del portal abierta, Sleep, cambios de red e inactividad. Revisar también Maximum session timeout en Authentication > Services > Global settings, junto con Access Time, Surfing Quota y Network Traffic Quota. Con When captive portal page is closed or redirected, la asignación termina cuando dejan de llegar keepalives; puede no ser visible al cerrar la ventana.

El login tarda unos dos minutos en aparecer

Si se utiliza STAS en la misma red, su fase de aprendizaje puede retrasar la redirección. Primero se comprueban el estado de STAS y los clientes no autenticados. El procedimiento general no cambia para ello un valor CLI global; el artículo sobre STAS explica la relación.

Varios usuarios comparten la misma IP de origen

Captive Portal asigna generalmente la identidad del usuario a una IP de cliente. Por eso, las direcciones IP introducidas en Multi-user hosts para Per-Connection AD SSO mediante Direct Web Proxy no pueden utilizar Captive Portal. Per-Connection AD SSO para hosts multiusuario explica el procedimiento adecuado y la regla independiente sin Match known users para el tráfico restante.

Preguntas frecuentes