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:

Comprobar la fuente de autenticación y el grupo permitido.
Autorizar Captive Portal para la zona del cliente en Administration > Device access.
Si se utiliza un servidor DNS externo, crear una regla DNS limitada sin referencia al usuario.
Crear una regla de usuario con Match known users y Use web authentication for unknown users.
Definir HTTPS, página de destino y cierre de sesión en Authentication > Web authentication.
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.

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.

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

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 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.

Para producción son importantes estas decisiones:

Use insecure HTTP instead of HTTPS permanece desactivado. HTTP transmite las credenciales sin cifrar y no funciona con Entra ID SSO.
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 es más adecuado si la sesión debe finalizar tras un periodo de inactividad definido.
Never exige cierre manual y puede conservar durante más tiempo asignaciones obsoletas entre usuario e IP.

No hay un timeout universal. Las sesiones cortas son más importantes en dispositivos compartidos y con usuarios cambiantes; en dispositivos personales el login puede ser menos intrusivo. Cada opción se prueba con Sleep, cambio de Wi-Fi y cierre manual. Estas opciones locales no se aplican a Entra ID SSO.

Guardar con Apply.

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. Para validar el nombre del certificado y la cadena de confianza se utiliza la URL FQDN.

Los ajustes están en Administration > Admin and user settings > Admin console and end-user interaction. En Redirect users se elige 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. La selección afecta también a otros portales locales. Antes de cambiarla, comprobar WebAdmin, User Portal y VPN Portal.

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.

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

Comprobar que el cliente tiene una dirección de 10.30.40.0/24, el gateway previsto y el servidor DNS correcto.
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.
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.
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.
En Current activities > Live users, comprobar nombre de usuario, IP del cliente y tipo de autenticación.
Probar una web permitida y, de forma consciente, un destino o servicio no permitido.
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.
Con un usuario ajeno a BYOD_Internet, comprobar que el login no concede acceso mediante esta regla.
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; 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.

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.

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, la ventana del portal abierta, Sleep, cambios de red e inactividad. 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.

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

¿Funciona Sophos Firewall Captive Portal sin Active Directory?

Sí. También puede autenticar usuarios con la base de datos local, LDAP o RADIUS. La fuente debe estar seleccionada en Firewall authentication methods y los usuarios o grupos deben corresponder a la regla de firewall posterior.

¿Debe Captive Portal ser accesible desde Internet?

No. Está pensado para usuarios que ya se encuentran en una red interna, BYOD o Wi-Fi. Para el acceso externo se utilizan VPN Portal y una configuración adecuada de Remote Access. En Device Access, Captive Portal solo debe autorizarse para las zonas de clientes que realmente lo necesiten.