Solucionar errores de autenticación en Sophos Firewall

Un error de autenticación en Sophos Firewall puede producirse en puntos muy distintos. El servidor puede estar accesible, pero no seleccionado para el servicio afectado. El inicio de sesión puede funcionar mientras el grupo principal, una cuota o una regla de firewall impiden el acceso. También puede ocurrir que el firewall no vea al usuario y procese el tráfico únicamente según su dirección IP.

El procedimiento rápido y seguro separa estas capas de forma deliberada:

1. Anotar el usuario, la IP de origen, el servicio afectado, la hora y el resultado esperado.
2. Comprobar desde la zona de origen real que el portal o el servicio de autenticación sea accesible.
3. En Authentication > Services, comprobar que el servidor correcto esté seleccionado para el servicio afectado y ocupe la posición prevista.
4. Ejecutar Test connection en el servidor de autenticación, pero considerarlo únicamente una prueba de las credenciales y de la conexión con el servidor.
5. Generar un inicio de sesión nuevo y comprobar el usuario, la IP de origen y Client Type en Current activities > Live users.
6. En Authentication > Users, comprobar el estado, el grupo principal, los demás grupos, las anulaciones del usuario y User ID.
7. Comprobar Access Time, cuotas, MFA y Sign-in Restrictions únicamente para el usuario realmente afectado o su grupo efectivo.
8. Solo después de confirmar la identidad, probar con tráfico real la regla de firewall, Rule ID, política web o VPN, NAT y routing esperados.

⚠️ No modificar de forma amplia y por simple sospecha los servidores de autenticación, el orden de los grupos, las cuotas ni Device Access. Reiniciar un servicio, ejecutar Purge AD users o crear una regla Any no es un primer paso normal de diagnóstico. Primero hay que demostrar en qué capa se interrumpe el proceso.

Cinco capas en lugar de un único error de inicio de sesión

En la práctica ayuda utilizar un modelo sencillo. El acceso de un usuario no pasa por una sola comprobación, sino por al menos cinco capas independientes:

1. Accesibilidad: El cliente y el firewall alcanzan el portal, el proxy o el servidor de autenticación por la ruta prevista.
2. Servicio y método: En Authentication > Services está seleccionado el servidor de autenticación correcto para ese servicio concreto.
3. Identidad: El firewall reconoce al usuario esperado y lo muestra con la IP de origen correcta y el Client Type apropiado.
4. Autorización: Coinciden el estado del usuario, el grupo, el grupo principal, Access Time, la cuota, MFA y los permisos específicos del servicio.
5. Tráfico posterior: Una regla de firewall, Web Policy o VPN Policy permite los destinos necesarios y funciona la ruta de retorno.

Esta separación evita dos conclusiones erróneas frecuentes. Un Test connection correcto no demuestra que funcione el inicio de sesión SSO. A la inversa, que un usuario aparezca en Live users todavía no demuestra que su tráfico coincida con la regla o política prevista.

Definir un caso de prueba reproducible

Antes del primer cambio se define un único caso de prueba. Como valores de documentación seguros pueden utilizarse, por ejemplo:

• Usuario: auth-pilot@example.com
• IP del cliente: 192.0.2.25
• Zona de origen: LAN
• Servicio: Firewall authentication, User portal, VPN portal, SSL VPN o Web admin console
• Hora de la prueba: hora local del firewall, con fecha y minuto
• Grupo esperado: Internet-Standard
• Regla esperada: LAN-Users-to-WAN
• Resultado esperado: inicio de sesión correcto y acceso HTTPS a un destino de prueba definido

example.com y 192.0.2.0/24 son valores de documentación. El nombre de usuario, la IP de origen, la zona, el grupo, la regla y el destino deben sustituirse por valores piloto reales. El usuario piloto debería utilizar el mismo origen de autenticación y grupo de permisos que el usuario afectado, pero no tener privilegios administrativos innecesarios.

Si es posible, se prueba además un usuario de comparación que funcione y proceda del mismo origen. Si ambos fallan, la causa probablemente está en el servicio, el servidor o la accesibilidad. Si solo falla uno, es más probable que se deba al objeto de usuario, los grupos, las cuotas, MFA o Sign-in Restrictions.

Comprobar el servicio, la accesibilidad y el servidor

Comprobar Device Access solo para el servicio necesario

Los portales y servicios locales de autenticación no se habilitan mediante reglas de firewall normales. En Administration > Device access, o mediante una Local service ACL exception rule específica, el servicio necesario debe ser accesible desde la zona de origen prevista o desde las redes de origen conocidas.

Según la prueba pueden ser relevantes distintas entradas, por ejemplo Captive portal, User portal, VPN portal, SSL VPN, AD SSO o Client Authentication. Solo se comprueba el servicio que realmente se necesita. Una habilitación general para LAN o WAN ocultaría el problema y podría exponer otros servicios de administración o portales. Device Access y Local Service ACL en Sophos Firewall explica cómo limitar el acceso de forma segura.

La accesibilidad por sí sola aún no es autenticación. Ver la página de un portal solo confirma que el cliente alcanza el servicio local. Todavía no se han comprobado el nombre de usuario, la contraseña, el token SSO, el grupo ni la regla de firewall posterior.

Comprobar el método de autenticación por servicio

En Authentication > Services, cada servicio tiene su propia selección de servidores. Por eso no basta con comprobar si existe un servidor AD, LDAP, RADIUS o Entra; también hay que verificar que esté seleccionado para el servicio afectado:

• Firewall authentication methods para el tráfico de usuario y la autenticación clásica del firewall;
• User portal authentication methods para User Portal;
• VPN portal authentication methods para VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para estos inicios de sesión VPN;
• Administrator authentication methods para administradores con nombre propio;
• SSL VPN authentication methods para SSL VPN.

Cuando hay varios servidores, también importa el orden. No se desplaza un servidor a la primera posición de forma precipitada. Primero se documentan el orden actual, Default Group y el usuario de comparación que funciona. De lo contrario, un cambio podría afectar a otros usuarios o servicios. Para administradores externos, TACACS+ para WebAdmin de Sophos Firewall separa además la autenticación del servidor, el perfil de administrador local y un fallback seguro frente al bloqueo.

Interpretar correctamente Test connection

En Authentication > Servers, Test connection comprueba las credenciales y la conexión entre el firewall y el servidor. Si falla, primero se corrigen DNS, routing, puerto, seguridad de la conexión, cadena de certificados, cuenta de servicio o contraseña.

Sin embargo, una prueba correcta solo representa la primera capa. Para AD SSO no comprueba Kerberos, NTLM, SPN, Redirection Location, la confianza del navegador ni el acceso real del usuario. En los inicios de sesión de portales y VPN también hay que comprobar por separado la selección del servicio, el grupo, MFA y la política. Conectar Active Directory con Sophos Firewall describe la configuración básica completa de AD.

Utilizar Live Users como primera prueba de identidad

Después de un inicio de sesión nuevo se abre Current activities > Live users. Al menos tres datos son importantes:

Para el Client Authentication Agent, el tipo de cliente debe ser Authentication agent. También hay que comprobar por separado la ruta hacia 1.2.3.4:9922, la Authentication Server CA y el match real de la regla de firewall.

• User: ¿El usuario detectado corresponde realmente a la cuenta piloto?
• IP address: ¿La dirección coincide con la conexión observada del cliente?
• Client Type: ¿Se utilizó la ruta esperada, por ejemplo AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO o un tipo de VPN?

Si el usuario no aparece, la capa de identidad todavía no se ha completado correctamente. En ese caso no se continúa buscando en la regla de usuario posterior. Si aparece el nombre del equipo en lugar del usuario conectado, un servicio del sistema operativo, como Windows Update, puede haber enviado las credenciales NTLM del dispositivo. Un inicio de sesión interactivo real y una nueva solicitud web permiten aislar este caso.

Un usuario externo de AD, LDAP o RADIUS normalmente aparece en Authentication > Users solo después de su primer inicio de sesión correcto en un servicio del firewall. Por ello, que no exista un registro local del usuario no demuestra que falte la cuenta en el directorio. Para una cuenta gestionada directamente en SFOS, crear y gestionar usuarios locales normales explica, en cambio, todo el proceso de cuenta, servicio, pruebas y baja.

Para repetir la prueba de forma limpia se puede desconectar una sesión normal existente en Live users. Cuando se desconecta manualmente una sesión AD SSO, el usuario puede tardar hasta tres minutos en volver a iniciar sesión. Los Clientless Users no se desconectan allí mediante Disconnect; deben establecerse como Inactive en Authentication > Clientless users.

Comprobar el objeto de usuario, el grupo principal y las restricciones

Si el usuario está visible o ya se ha creado un registro local, se continúa en Authentication > Users. No se modifican valores a ciegas, sino que primero se documentan las propiedades efectivas:

• estado Active o Inactive;
• campo Group como grupo principal para usuarios AD;
• Other group memberships;
• anulaciones de políticas específicas del usuario;
• Access Time y Sign-in Restriction;
• Surfing Quota y Network Traffic Quota;
• asignación MFA para el servicio afectado;
• propiedad adicional User ID.

No equiparar el grupo principal con los demás grupos

Un usuario AD puede pertenecer a varios grupos. Sophos Firewall muestra el grupo principal efectivo en el campo Group y las demás pertenencias por separado. Las reglas de firewall, Web Policies y algunas otras funciones pueden tener en cuenta varios grupos. En cambio, Access Time, las cuotas, MFA y varias funciones de acceso remoto solo utilizan el grupo principal o una asignación explícita al usuario.

Por ello, el orden de los grupos no se modifica como solución rápida. Primero debe quedar claro qué función falla y qué lógica de grupos admite. Después de un cambio planificado, se vuelve a autenticar al usuario y se comprueba de nuevo el grupo principal.

El procedimiento operativo completo, desde la creación de grupos y el Default Group hasta Reorder, los grupos múltiples, las excepciones de usuario y la reversión, se describe en Gestionar correctamente los grupos de usuarios y el grupo principal en Sophos Firewall.

Tratar Access Time, cuotas y MFA como causas independientes

Un Captive Portal inesperado o un inicio de sesión rechazado también puede deberse a un horario bloqueado, una Surfing Quota o Network Traffic Quota agotada o un registro MFA incompleto. Estas opciones se comparan en el usuario y en su grupo efectivo.

Las comprobaciones y rutas de recuperación correspondientes se explican en Access Time para usuarios y grupos, Surfing Quota y Network Traffic Quota y MFA para Sophos Firewall. No se restablece una cuota ni se amplía una política de Access Time antes de demostrar cuál es su asignación efectiva.

Atribuir el límite de User ID solo después de ver el valor

En Show additional properties se puede mostrar User ID. Un valor superior a 65535 está fuera del rango admitido; en ese caso el usuario no puede autenticarse ni convertirse en Live User. La cantidad de usuarios visibles no basta para este diagnóstico porque los grupos comparten el mismo rango de ID.

Si la ID es válida o el usuario sigue sin aparecer por completo, se continúa con el diagnóstico general. Purge AD users solo corresponde a un caso de limpieza demostrado. El procedimiento especializado y seguro está en Comprobar el límite de User ID de Sophos Firewall.

Continuar específicamente con el método utilizado

En cuanto se conocen el servicio y la capa del fallo, se profundiza únicamente en el método correspondiente. Así se mantiene acotado el diagnóstico y no se modifican varios sistemas de autenticación a la vez.

Inicio de sesión clásico y Captive Portal

Para un inicio manual se comprueban la URL directa del portal, Device Access, el método de autenticación seleccionado, el estado del usuario, la contraseña y MFA. En Captive Portal también hay que comprobar si la conexión desconocida alcanza la regla prevista con Use web authentication for unknown users y si DNS funciona antes del inicio de sesión.

La configuración completa, incluido el puerto 8090, Live Users, la regla de usuario y el cierre de sesión, está en Configurar y probar Captive Portal en Sophos Firewall.

AD SSO con Kerberos o NTLM

Una prueba de conexión AD correcta no es suficiente para SSO. También deben ser correctos el nombre de host o FQDN, la resolución DNS, Redirection Location, el certificado, la confianza del navegador, Domain Join y, para Kerberos, el HTTP-SPN adecuado. Si Kerberos recurre a NTLM o a Captive Portal, primero se comprueba esta ruta de nombres y confianza.

nasm.log es relevante para los errores de NTLM y Kerberos. No se modifican a ciegas SPN ni Domain Join; primero se guarda el estado existente en el firewall y el controlador de dominio.

STAS, SATC y hosts multiusuario

Con Synchronized User ID Authentication, la identidad de dominio de Windows y la IP del cliente llegan mediante Security Heartbeat. El estado del endpoint, el dominio UPN, sAMAccountName, la validación de AD y Live users deben coincidir; un heartbeat verde por sí solo no demuestra la regla de usuario.

Con STAS debe seguirse la misma IP del cliente a través de los eventos de Windows, STA Agent, Collector y firewall. Si el usuario solo falta en Live Users, se comprueban la accesibilidad del Collector, las redes supervisadas, Exclusion List y Client Authentication. El procedimiento completo se encuentra en Configurar STAS en Sophos Firewall.

Varios usuarios simultáneos detrás de una IP de servidor de terminales necesitan un modelo de sesión. SATC para Remote Desktop Services puede asociar varios protocolos a una sesión. En cambio, Per-Connection AD SSO para hosts multiusuario solo se aplica a conexiones HTTP y HTTPS a través de Direct Web Proxy. Una asignación normal basada en IP no puede distinguir de forma fiable a varios usuarios detrás de la misma dirección.

RADIUS SSO, Entra ID y VPN

RADIUS SSO necesita eventos de accounting con la IP correcta del cliente; una prueba de acceso RADIUS correcta no demuestra esta ruta de accounting. RADIUS SSO con accounting describe la configuración y comprobación de Framed-IP-Address.

Con Microsoft Entra ID SSO también se comprueba el flujo OAuth específico del servicio. Captive Portal, VPN Portal y WebAdmin utilizan Redirect URIs, métodos de autenticación y archivos de log distintos. Un inicio de sesión correcto en uno de estos servicios no demuestra que los demás funcionen.

En VPN, después de la autenticación también se comprueba si el usuario o su grupo se encuentra en la política de acceso remoto correcta. Un estado de túnel verde todavía no demuestra el acceso a destinos internos.

La autenticación funciona, pero el tráfico sigue bloqueado

Cuando el usuario aparece en Live users con la IP esperada, el diagnóstico pasa a la autorización y a la ruta de paquetes. Un flujo de prueba real debe mostrar:

1. ¿Qué Firewall Rule ID procesa la conexión?
2. ¿Contiene esta regla al usuario esperado o a un grupo admitido?
3. ¿Está activado Log firewall traffic?
4. ¿Selecciona la regla la Web Policy, Application Policy, IPS Policy o Traffic Shaping Policy correcta?
5. ¿Coinciden el destino, el servicio, NAT, la ruta y la ruta de retorno?

Una regla IP general situada por encima de la regla de usuario puede procesar antes el tráfico. También puede coincidir la regla de usuario correcta, mientras una Web Policy, TLS Inspection, DNS, routing o el sistema de destino bloquean el acceso posterior. Por ello, un cambio de autenticación no debe utilizarse como solución para un error de routing o de política ya demostrado.

Probar correctamente una regla de Sophos Firewall explica la validación completa con Log Viewer, Policy tester y Packet Capture.

Correlacionar Log Viewer y los archivos de log

En Log viewer se comprueba el módulo Authentication con el usuario anotado, la IP de origen y un periodo de prueba reducido. Después se busca la misma hora en el módulo de firewall o VPN. Así se distingue si falla el inicio de sesión o si solo se bloquea el flujo de datos posterior.

Para la autenticación, autorización y accounting clásicos, access_server.log es el primer archivo que se comprueba. En Advanced Shell, los siguientes comandos son de solo lectura:

cd /log
tail -n 200 access_server.log

Según el método, se añade únicamente el archivo correspondiente:

tail -n 200 nasm.log
tail -n 200 oauth_sso_captive.log
tail -n 200 oauth_sso_webadmin.log
tail -n 200 oauth_sso_vpn.log

• nasm.log corresponde a NTLM y Kerberos.
• oauth_sso_captive.log corresponde al flujo Entra SSO de Captive Portal.
• oauth_sso_webadmin.log corresponde a Entra SSO para WebAdmin.
• oauth_sso_vpn.log corresponde a Entra SSO para VPN Portal, IPsec y SSL VPN.

Los comandos solo leen las últimas 200 líneas. No activan debug ni reinician servicios. Solo después de seleccionar el método se añaden otros archivos como vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log o csd.log. Logs de servicios de Sophos Firewall explica la asignación.

En un clúster HA, cada nodo solo almacena logs y reportes del tráfico que procesa. Por eso se documentan el rol, la hora de la prueba y el nodo que procesó el intento, y los archivos se comprueban en ese nodo. Un archivo vacío en el otro dispositivo no refuta el problema.

Delimitar el error según el síntoma

Test connection funciona, pero SSO no

El servidor de autenticación y sus credenciales están accesibles. A continuación se comprueban Authentication > Services, Device Access, Live Users y el flujo SSO específico del método. Para AD son especialmente relevantes DNS, FQDN, Redirection Location, SPN, la confianza del navegador, Domain Join y nasm.log.

Aparece Captive Portal en lugar del inicio de sesión transparente

Primero se determina si AD SSO o STAS debería reconocer al usuario antes del acceso web. Después se comprueban Client Type en Live Users, el módulo Authentication, Access Time, las cuotas y las credenciales. El portal es un síntoma de una identidad ausente o rechazada, no automáticamente un error del portal.

Aparece el nombre del equipo en lugar del nombre de usuario

Un servicio del sistema puede enviar las credenciales NTLM del endpoint aunque ningún usuario haya iniciado sesión de forma interactiva. Se inicia sesión con un usuario real, se abre una nueva sesión del navegador y se repite la prueba. Si el nombre del equipo permanece, se comprueban la ruta del navegador o proxy, el método SSO y nasm.log.

El usuario no aparece en Live Users

Primero se comprueban la selección del servicio, Device Access y el método concreto. En STAS, el Collector y el firewall deben ver la misma IP; en Captive Portal, el inicio de sesión debe completarse realmente; con servidores externos, el registro local del usuario solo se crea después de un inicio correcto. User ID, Sign-in Restriction y las cuotas solo se comprueban cuando existe un registro de usuario correspondiente.

El usuario está visible, pero el grupo o la política son incorrectos

En Authentication > Users se comparan el grupo principal, Other group memberships y las anulaciones del usuario. Después se comprueba si la función concreta admite varios grupos. El orden de los grupos solo se modifica durante una ventana de mantenimiento planificada, ya que también puede desplazar MFA, cuotas, Access Time, VPN y otras políticas.

El inicio de sesión funciona, pero Internet o el destino VPN siguen inaccesibles

La autenticación ya no es la primera capa de error. Se comprueban Firewall Rule ID, el orden de las reglas, logging, la política web o VPN, NAT, la ruta y la ruta de retorno con un flujo real. Tanto la identidad del usuario como la ruta de paquetes deben ser correctas.

El error solo aparece tras un failover HA o de forma esporádica

Se documentan el build de firmware, el cambio de roles, el rol del nodo activo, la hora de inicio de sesión y el método de autenticación. Se prueba un nuevo inicio de sesión y una nueva conexión tras el failover. Después se revisan los logs del nodo que procesó el intento. Una sesión existente no debe considerarse una prueba de una nueva autenticación correcta.

Condiciones de parada y datos para soporte

No se sigue modificando la configuración productiva cuando:

• el servicio afectado o el método de autenticación no están claramente identificados;
• Test connection falla y DNS, ruta, puerto, TLS o las credenciales siguen sin aclararse;
• el usuario piloto aparece con un Client Type inesperado o una IP de origen incorrecta;
• no se puede explicar la asignación del grupo principal, una anulación de usuario o una cuota;
• una prueba negativa obtiene acceso de forma inesperada;
• solo una habilitación amplia de Device Access o una regla de firewall amplia parece hacer funcionar la prueba;
• un problema HA no puede asignarse a un nodo de procesamiento y a un momento concreto.

Antes de escalar se recopilan como mínimo:

• modelo del appliance, versión de SFOS y build completo;
• en HA, ambos roles y el nodo de procesamiento;
• origen de autenticación y servicio afectado;
• usuario de prueba, IP de origen, Client Type y periodo;
• orden de los servidores en Authentication > Services;
• resultado de Test connection con su significado limitado;
• estado, grupo principal, otros grupos, anulaciones y User ID;
• evento de Authentication, Firewall Rule ID y resultado del flujo de prueba real;
• logs de autenticación, portal, VPN y firewall correspondientes.

Los nombres de usuario y grupos pueden contener información sensible. El paquete solo se entrega por el canal de soporte previsto. Antes de reiniciar servicios, activar debug o limpiar datos, se crea un Consolidated Troubleshooting Report y una exportación de logs específica.

Lista de comprobación

• El caso de prueba contiene usuario, IP de origen, servicio, hora y resultado esperado.
• El servicio local solo es accesible desde la zona o el origen previstos.
• El servidor correcto está seleccionado para el servicio afectado en Authentication > Services.
• Test connection no se ha confundido con una prueba SSO completa.
• Live Users muestra el usuario, la IP y el Client Type esperados.
• Se han comprobado el estado, el grupo principal, otros grupos, las anulaciones y User ID.
• Access Time, cuotas, Sign-in Restriction y MFA solo se han evaluado en la ruta efectiva del usuario.
• El éxito de la autenticación y el flujo posterior de firewall, web o VPN se han probado por separado.
• Log Viewer y el archivo de log adecuado se han correlacionado para el mismo periodo.
• En HA se ha comprobado el nodo de procesamiento.
• No se ha utilizado un reinicio general, purge ni una habilitación amplia como solución rápida.
• Los datos para soporte se han guardado antes de realizar más cambios.

Preguntas frecuentes