Configurar RADIUS SSO con accounting en Sophos Firewall

RADIUS SSO inicia la sesión de un usuario en Sophos Firewall sin un portal cautivo adicional. El usuario ya se ha autenticado en una red inalámbrica, un servidor de acceso a la red u otro sistema RADIUS. A continuación, el firewall recibe un paquete de accounting RADIUS con el nombre de usuario y la IP del cliente y puede usar esta asociación en reglas basadas en usuarios.

El punto decisivo no es solo un inicio de sesión 802.1X correcto. El firewall debe recibir un Accounting-Start utilizable del remitente configurado exactamente. Para Wi-Fi SSO, Sophos usa la Framed-IP-Address de este paquete de inicio. Si falta la IP del cliente, puede que el firewall conozca el nombre de usuario, pero no puede asociarlo al tráfico.

⚠️ RADIUS SSO no es lo mismo que Enable accounting en el objeto del servidor RADIUS. En Authentication > Servers, Enable accounting significa que el firewall envía accounting a un servidor RADIUS. En Authentication > Services > SSO using RADIUS accounting request, el firewall recibe accounting de un cliente RADIUS y crea una asociación de usuario e IP.

Procedimiento rápido

1. Comprobar que el punto de acceso, el controlador o el proxy RADIUS puede generar un accounting start con el nombre de usuario y Framed-IP-Address.
2. Definir el remitente real, la dirección de destino del firewall, el puerto UDP 1813 y un secreto compartido robusto.
3. En Authentication > Services > SSO using RADIUS accounting request, introducir la IP del remitente y el secreto compartido.
4. En Administration > Device access, permitir el servicio RADIUS SSO solo para ese remitente y la dirección correcta del firewall.
5. Preparar una regla de usuario estrictamente limitada con Match known users y registro.
6. Conectar un cliente real y comprobar el paquete de accounting en el firewall.
7. En Current activities > Live users, comprobar el tipo de cliente RADIUS SSO, el usuario y la IP correcta del cliente.
8. Solo entonces probar el tráfico permitido y el deliberadamente no permitido con el Firewall Rule ID esperado.

Cuándo conviene RADIUS SSO

RADIUS SSO es especialmente apropiado para redes Wi-Fi 802.1X o sistemas de acceso a la red en los que la autenticación ya se realiza fuera del firewall. Así, el firewall puede reconocer al usuario sin un segundo inicio de sesión en el navegador.

El procedimiento requiere una relación inequívoca entre el usuario y una dirección IPv4. Los requisitos habituales son:

• El cliente recibe una dirección IPv4 que Sophos Firewall también ve como origen del tráfico.
• El remitente del accounting conoce el nombre de usuario y esa IP del cliente.
• El accounting start llega directamente a una dirección del firewall y sin un cambio inesperado de NAT de origen.
• El remitente RADIUS puede incluir Framed-IP-Address en el paquete de inicio.
• Los objetos de usuario o grupo y la regla de firewall correspondiente ya están planificados.

RADIUS SSO no sustituye a STAS en Sophos Firewall cuando la fuente de identidad son los eventos de inicio de sesión de Windows de Active Directory. Tampoco puede distinguir varios usuarios detrás de la misma IP de RDS o Citrix. Según el tráfico, son más adecuados SATC para Remote Desktop Services o AD SSO por conexión mediante el proxy web directo.

Cuándo detener el procedimiento

No activarlo en producción mientras alguno de estos puntos esté pendiente:

• El paquete de accounting no contiene un nombre de usuario o Framed-IP-Address.
• La dirección indicada en el paquete difiere de la IP de origen que el firewall ve después en el tráfico útil.
• Varios usuarios comparten la misma IP de cliente.
• El remitente real o la dirección de destino del firewall no son inequívocos debido a NAT, HA o el enrutamiento.
• El cliente RADIUS solo puede usar una red completa no fiable en vez de una dirección de origen fija.
• No está clara la estrategia de reglas para usuarios desconocidos o que ya no tienen una sesión iniciada.

Entender la ruta del accounting

En la autenticación RADIUS clásica, el firewall envía un Access-Request al servidor RADIUS. Con RADIUS SSO, la dirección es la contraria:

1. Un cliente se autentica en el punto de acceso, el controlador Wi-Fi o el servidor de acceso a la red.
2. Tras asignar la dirección, esta infraestructura genera un accounting start o lo reenvía mediante un proxy RADIUS.
3. Sophos Firewall recibe el paquete en su servicio RADIUS SSO.
4. Si la IP del remitente coincide con RADIUS client IPv4 y el secreto compartido es correcto, el firewall procesa el mensaje.
5. El nombre de usuario y Framed-IP-Address aparecen asociados en Live users.
6. Solo el tráfico útil posterior puede coincidir con una regla que tenga Match known users.

Que el controlador Wi-Fi envíe directamente al firewall o que un servidor RADIUS como NPS reenvíe el accounting depende del producto. La configuración de Sophos no contiene un procedimiento universal para NPS o controladores. Lo determinante es el paquete que llega realmente al firewall. Una indicación del fabricante como «compatible con RADIUS Accounting» no basta mientras no se hayan comprobado el nombre de usuario y la IP del cliente en el accounting start.

Ejemplo completo

Esta guía utiliza estos valores de ejemplo:

• Remitente RADIUS o de accounting: 10.10.20.15
• Dirección del firewall para RADIUS SSO: 10.10.20.1
• Cliente Wi-Fi: 10.30.40.50
• Puerto de destino del accounting: UDP 1813
• Usuario: EXAMPLE\alex.muster
• Regla de usuario: RADIUS-SSO-WiFi-Out

Las direcciones pertenecen a redes privadas de ejemplo y se sustituyen por las redes reales de gestión, servidores y clientes. En RADIUS client IPv4 no se introduce automáticamente la IP del servidor de autenticación, sino la IP de origen que se ve realmente en la captura de paquetes del firewall.

Preparar el sistema remoto

En el punto de acceso, controlador, servidor de acceso a la red o proxy RADIUS, la autenticación y el accounting deben comprobarse por separado. Un inicio de sesión correcto no demuestra que se genere accounting ni que se reenvíe a Sophos Firewall.

Como mínimo, preparar el sistema remoto así:

1. Activar accounting para el acceso 802.1X o de red afectado.
2. Configurar como destino de accounting la dirección prevista del firewall 10.10.20.1.
3. Usar UDP 1813 o el puerto de accounting acordado expresamente por ambos lados.
4. Configurar un secreto compartido propio y robusto para esta ruta.
5. Enviar el accounting start solo cuando se conozca la IP del cliente.
6. Asegurarse de que se incluyen el nombre de usuario y Framed-IP-Address.
7. Documentar la IP de origen, el enrutamiento y cualquier traducción NAT hacia la interfaz del firewall.

Un accounting stop o una actualización puede mejorar el mantenimiento de la sesión en algunos productos. Sin embargo, la ayuda pública de Sophos indica expresamente que la IP del accounting start es la base del inicio de sesión para Wi-Fi SSO. Por tanto, una actualización posterior no debe sustituir un paquete de inicio completo como criterio de éxito.

En instalaciones APX administradas por SFOS puede influir el tiempo de DHCP. Sophos documenta para ello el parámetro radius_accounting_start_delay con un intervalo de 0 a 60 segundos. No cambiar este valor por sospecha: primero, una captura debe demostrar que el accounting start se genera antes de asignarse la IP. La configuración Wi-Fi general se explica en Configurar Wireless Network en Sophos Firewall.

Para AP6, las notas de la versión 1.5.2167 MR5 incluyen la corrección WIFIX-5189 para un caso en el que faltaba la framed IP en accounting start y accounting update. En un AP6 con firmware antiguo o desconocido, actualizar primero a una versión actual compatible y volver a comprobar el paquete. Esta corrección no demuestra que todas las combinaciones de controlador, proxy o NPS reenvíen correctamente los atributos.

Configurar RADIUS SSO en Sophos Firewall

Introducir el remitente y el secreto compartido

La ruta de menú es:

Authentication > Services > SSO using RADIUS accounting request

Procedimiento:

1. En RADIUS client IPv4, añadir la IP de remitente 10.10.20.15 esperada en la captura.
2. Introducir el Shared secret acordado para esta ruta.
3. Añadir más remitentes solo como entradas propias y documentadas.
4. Seleccionar Apply.

Solo se tienen en cuenta para RADIUS SSO los paquetes procedentes de las direcciones IPv4 configuradas. Una red completa o cualquier dirección de origen no es una alternativa razonable a una planificación ausente del remitente.

Esta configuración no crea un servidor RADIUS en Authentication > Servers ni sustituye la configuración general de un servidor RADIUS en Sophos Firewall. Ese artículo trata las solicitudes que el firewall envía a NPS, MFA u otro servidor RADIUS. RADIUS SSO trata los mensajes de accounting entrantes.

Permitir Device Access de forma limitada

RADIUS SSO es un servicio local del firewall. Una regla LAN-to-WAN o WiFi-to-WAN normal no abre esta ruta de recepción.

En Administration > Device access hay dos opciones limpias:

• Si la zona del remitente es pequeña y completamente fiable, activar RADIUS SSO en la matriz de zonas.
• Si solo se ha previsto un sistema remoto fijo, mantener desactivada la zona y crear una Accept Local service ACL exception rule específica para la IP del remitente, la dirección usada del firewall y el servicio RADIUS SSO.

Una excepción accept adicional no limita una autorización de zona ya activa. Para conseguir una excepción realmente restringida, RADIUS SSO debe permanecer desactivado en la zona afectada. El procedimiento completo se explica en Device Access y Local Service ACL.

Preparar la regla de usuario

Para la primera prueba no hace falta una regla de producción amplia. Una regla limitada aporta pruebas más claras:

1. En Rules and policies > Firewall rules, crear una regla por encima de las reglas WiFi o LAN más generales.
2. Limitar Source Zone y Source Network a la red real de clientes.
3. Seleccionar solo el usuario piloto o un grupo piloto preparado.
4. Activar Match known users.
5. Permitir solo un servicio de prueba inocuo o un destino claramente definido.
6. Activar Log firewall traffic.
7. Definir una segunda combinación de usuario o destino deliberadamente no permitida para la prueba negativa.

RADIUS SSO proporciona una identidad, no una autorización general de red. Crear reglas de firewall en Sophos Firewall explica cómo interactúan usuarios, grupos, servicios y registro.

Validar RADIUS SSO de forma controlada

1. Demostrar el paquete de accounting en el firewall

En Diagnostics > Packet capture, establecer un filtro para la IP del remitente 10.10.20.15, la dirección del firewall 10.10.20.1 y UDP 1813. A continuación, volver a conectar exactamente un cliente piloto.

La captura debe confirmar como mínimo:

• La IP de origen es la RADIUS client IPv4 configurada.
• El destino es la dirección prevista del firewall.
• El puerto de destino es el puerto de accounting configurado.
• Aparece un accounting start para el usuario piloto.
• Framed-IP-Address coincide con la IP actual del cliente 10.30.40.50.

RADIUS accounting contiene datos de identidad y sesión que pueden ser visibles en el paquete. Tratar las capturas como registros de autenticación, conservarlas solo brevemente y no compartirlas sin protección. El uso general se explica en Packet Capture en Sophos Firewall.

2. Comprobar Live User

En Current activities > Live users deben coincidir el usuario, la IP del cliente y el tipo de cliente. Para este procedimiento se espera RADIUS SSO como tipo de cliente.

Un usuario visible con una IP incorrecta no es un éxito parcial. Las reglas de usuario coinciden después con el origen real del tráfico, no con la asociación Wi-Fi deseada.

3. Correlacionar el registro de autenticación

En Log Viewer, buscar el usuario piloto y la hora del incidente. Para el análisis detallado es relevante access_server.log, ya que Sophos procesa allí la autenticación, autorización y accounting de usuarios.

En HA, cada nodo guarda solo los registros del tráfico que él mismo ha procesado. Comprobar el nodo que recibió el accounting en el momento de la prueba. Comprobar servicios y registros de Sophos Firewall mediante CLI explica cómo leer y guardar access_server.log sin reiniciar el servicio de forma descontrolada.

4. Realizar pruebas positiva y negativa

Con el cliente piloto se comprueban por separado cuatro aspectos:

1. Un destino permitido coincide con el Firewall Rule ID esperado y muestra el usuario correcto.
2. Un destino deliberadamente no permitido sigue bloqueado.
3. Un usuario no asignado no recibe la autorización piloto.
4. Tras una nueva conexión o un roaming controlado, siguen siendo correctas la asociación de usuario, IP y regla.

La prueba debe realizarse con tráfico útil real. Una entrada en Live User no demuestra por sí sola la coincidencia de reglas, el enrutamiento ni la ruta de retorno. Probar reglas de firewall de forma fiable describe el procedimiento repetible.

Delimitar los errores por síntoma

No llega ningún paquete de accounting al firewall

Comprobar primero la IP de destino, el puerto UDP, el enrutamiento y la configuración del sistema remoto. Después, revisar Device Access o la Local Service ACL Exception Rule. Un inicio de sesión RADIUS correcto en NPS o en la red Wi-Fi no demuestra que exista la ruta separada de accounting hacia el firewall.

Si el paquete llega con otra IP de origen, investigar exactamente esa causa. No permitir precipitadamente una red completa como cliente RADIUS. Con NAT o HA, documentar y permitir de forma específica la dirección estable del remitente que se ve realmente.

Llega accounting, pero Live Users permanece vacío

Comprobar juntos el secreto compartido, la IP del remitente y el contenido del paquete. Son especialmente importantes el accounting start, el nombre de usuario y Framed-IP-Address. Si falta la IP del cliente, corregir primero el punto de acceso, el controlador o el proxy RADIUS. Reiniciar un servicio del firewall no crea un atributo ausente.

Solo si el paquete está completo y access_server.log sigue sin procesar el evento se guardan la hora, la captura, el CTR y los registros del nodo para Sophos Support. No eliminar la base de datos de autenticación ni limpiar Live Users por sospecha.

El usuario aparece con una IP incorrecta

Esto suele indicar un mensaje de accounting demasiado temprano, una asociación DHCP antigua, roaming o una ruta NAT diferente. Desconectar el cliente, registrar la concesión actual y capturar una única conexión nueva. Lo decisivo es la IP del nuevo accounting start.

En redes inalámbricas administradas por SFOS, cambiar radius_accounting_start_delay solo después de esta prueba y documentando el valor anterior. Los puntos de acceso o controladores de terceros usan sus propios mecanismos de accounting y DHCP; un parámetro inalámbrico de Sophos no cambia esos dispositivos.

Live User es correcto, pero la regla no coincide

En ese caso, la ruta de accounting ya está más avanzada que la política. Comprobar Source Zone, Source Network, usuario o grupo, Match known users, orden de reglas, Firewall Rule ID y la IP real del tráfico. Si coincide la regla #0 o una regla general, corregir la política en vez de cambiar el secreto compartido.

El usuario sigue visible después de cerrar la sesión

Comprobar primero si el sistema remoto envía un accounting stop y si ese paquete corresponde a la misma sesión y asociación de usuario. Después, correlacionar Live User, el tráfico actual del cliente y access_server.log. Una desconexión manual puede limpiar el estado temporalmente, pero no demuestra que el proceso automático sea correcto.

Seguridad, HA y operación

RADIUS accounting usa UDP y no protege el transporte como TLS. El secreto compartido autentica la ruta RADIUS, pero no cifra todos los atributos de identidad y sesión. Por eso, accounting debe estar en una red fiable de gestión o servidores y no atravesar redes ajenas sin protección.

En operación se aplican estos límites:

• Usar un secreto compartido propio y robusto y un responsable documentado para cada remitente.
• Permitir RADIUS SSO solo desde las zonas necesarias y, si es posible, únicamente desde hosts fijos.
• Tratar las capturas, los registros RADIUS y access_server.log como datos operativos personales.
• Finalizar los cambios de DHCP, controlador Wi-Fi, NPS, proxy RADIUS o NAT con una nueva prueba completa.
• En HA, no prometer la conservación ininterrumpida de la asociación del usuario. Tras un failover planificado, comprobar un nuevo accounting start, Live User y tráfico real en el nodo que lo procesa.
• Gestionar usuarios desconocidos o asociaciones ausentes mediante una regla predeterminada segura, no con una regla allow amplia.

Rollback

El rollback se realiza en un orden que no deje abierto el servicio de accounting ni conceda acceso involuntario a usuarios:

1. Restaurar la estrategia anterior de autenticación y reglas para la red piloto.
2. Desactivar la regla piloto y realizar una prueba negativa con un usuario desconocido.
3. Eliminar el destino de accounting del punto de acceso, controlador o proxy RADIUS, o restaurar su estado anterior documentado.
4. Eliminar el remitente en SSO using RADIUS accounting request.
5. Retirar la excepción ACL de RADIUS SSO o la autorización temporal de zona.
6. Volver a comprobar Live Users, Firewall Rule ID y el tráfico normal del cliente.

Documentar en el cambio la configuración original, la responsabilidad del secreto compartido y el retorno probado al método anterior de identificación de usuarios. Eliminar únicamente una entrada de Live User no es un rollback completo.

FAQ