Crear y gestionar Guest users de forma segura en Sophos Firewall

Los Guest users de Sophos Firewall son cuentas temporales para personas que no tienen una cuenta de usuario normal. Son adecuadas para visitantes, técnicos externos o participantes en una formación que inician sesión a través del Captive Portal y solo deben tener acceso a internet claramente limitado.

El procedimiento rápido y seguro es el siguiente:

1. Preparar un grupo de invitados restrictivo con las políticas necesarias.
2. En Authentication > Guest user settings, definir el prefijo, el grupo, la contraseña y la limpieza.
3. Decidir si un administrador crea cuentas individuales o múltiples, o si el autorregistro por SMS es realmente necesario.
4. Establecer la validez en Immediately o After first login y entregar las credenciales de forma segura.
5. Probar el Captive Portal, la regla de usuario, la separación de red y un destino permitido y otro bloqueado.
6. Desactivar o purgar la cuenta tras su caducidad y comprobar por separado las sesiones existentes y los registros.

⚠️ Una cuenta de invitado es solo una identidad. No separa una red ni abre una ruta de tráfico. Los invitados deben estar en una zona o VLAN propia y recibir una regla de firewall restrictiva y registrada. Las credenciales, impresiones y mensajes SMS deben tratarse como contraseñas.

Distinguir Guest users, vales y usuarios normales

Un Guest user es un registro de usuario local temporal. El firewall genera el nombre de usuario y la contraseña a partir de los ajustes globales de usuarios invitados. Tras el inicio de sesión, puede asociar el tráfico a esta identidad y aplicar las políticas del grupo seleccionado.

Otros modelos de acceso resuelven tareas diferentes:

• Usuario local o externo normal: Adecuado para personas recurrentes con una cuenta permanente, una fuente de usuarios central o MFA. Crear y gestionar usuarios locales normales explica el modelo mantenido directamente en el firewall.
• Guest user: Adecuado para una persona temporal con una cuenta individual, una validez propia y controles de uso opcionales.
• Vale de hotspot: Es un código para un hotspot inalámbrico. La validez, el tiempo en línea, el volumen de datos y el número de dispositivos se gestionan en el modelo de hotspot. La configuración se explica en Hotspot de Sophos Firewall con vales o contraseña del día.
• Clientless User: Asocia una dirección IP fija a un dispositivo sin que una persona inicie sesión. Este procedimiento se explica en Configurar Clientless Users en Sophos Firewall.

Los Guest users no están destinados al acceso remoto SSL VPN ni al acceso remoto IPsec. La política SSL VPN actual no permite Guest users ni Guest groups como Policy members. Para el acceso remoto se utiliza un usuario normal de una fuente local o externa adecuada. La configuración completa se explica en Configurar el acceso remoto SSL VPN.

La página de ayuda actual de SFOS 23 Edit guest user sigue mostrando campos de SSL VPN y acceso remoto IPsec. Sin embargo, las páginas de SFOS 23 sobre políticas SSL VPN y ajustes IPsec excluyen expresamente a Guest users y Guest groups de estos dos métodos de acceso remoto. Es una contradicción documental sin resolver dentro de la misma versión, no un cambio de versión demostrado. Estos campos no demuestran que se admita el acceso VPN de invitados; para SSL VPN e IPsec se recomienda utilizar un usuario normal. Estas exclusiones no permiten determinar si los invitados pueden usar Clientless SSL VPN, L2TP o PPTP; esas partes de la página Edit siguen sin aclararse.

La misma contradicción existe en las páginas de ayuda de SFOS 22. Las páginas Edit de ambas versiones también describen marcadores del navegador para Clientless SSL VPN policy y direcciones IP asignadas opcionales para IPsec remote access, L2TP y PPTP. Estas descripciones de campos no autorizan a activar dichos métodos para invitados. Para el acceso a internet descrito aquí no se añaden permisos de acceso remoto. Si existe una necesidad de VPN independiente, se utiliza un usuario normal y el procedimiento de VPN correspondiente; las opciones de invitados sin aclarar no se activan experimentalmente en producción.

Configuración de ejemplo y requisitos

El siguiente ejemplo utiliza una red de invitados separada y una cuenta para una visita de un día:

• Zona: Guest
• Red: 10.30.40.0/24
• Nombre del portal: login.example.com
• Grupo de invitados: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 es una red privada de ejemplo y debe sustituirse por la red de invitados real. login.example.com es un nombre de documentación. Debe sustituirse por un FQDN que, desde la red de invitados, se resuelva a la dirección accesible del firewall y que esté cubierto por el certificado del portal. El grupo recibe únicamente las políticas previstas realmente para este acceso de invitados.

Antes de crear cuentas deben cumplirse estos requisitos:

1. La red de invitados, DHCP, DNS, el enrutamiento y NAT se han verificado con una regla de prueba temporal y estrictamente limitada. Esta regla se elimina antes de probar la autenticación; una regla DNS independiente solo debe permitir el tráfico necesario hacia el resolvedor.
2. Las redes internas y los servicios de administración están bloqueados desde la zona de invitados.
3. El Captive Portal solo es accesible desde la zona prevista.
4. Un grupo propio reúne Access Time, cuotas, Traffic Shaping y Sign-in Restriction.
5. Durante la prueba siguen disponibles una cuenta de administrador y una vía de administración independiente.
6. La emisión, caducidad, revocación y conservación de las credenciales están definidas operativamente.

Definir los ajustes globales de usuarios invitados

Antes de crear la primera cuenta, se abre:

Authentication > Guest user settings

Estos valores sirven de plantilla para las nuevas cuentas de invitado. Por ello, cualquier cambio en la plantilla se prueba primero con una cuenta piloto.

Elegir ajustes generales seguros

En Guest user general settings se definen los siguientes campos:

1. Username prefix: guest- en el ejemplo. Es preferible un prefijo neutro a nombres de empresa, sede o cliente que revelen información innecesaria.
2. Group: Seleccionar Guest_Internet. Los Guest users heredan las políticas de este grupo.
3. Password length: 16 en el ejemplo. Sophos permite un máximo de 50 caracteres tanto para el nombre de usuario como para la contraseña en el Captive Portal. La longitud se elige para que sea suficientemente segura y pueda utilizarse de forma fiable a través del canal de entrega previsto.
4. Password complexity: Seleccionar la opción más robusta que sea compatible con el proceso de entrega e inicio de sesión.
5. Disclaimer: Este texto se imprime debajo de las credenciales generadas. Indicar unas condiciones de uso breves, la responsabilidad y un contacto. No debe contener credenciales reales ni detalles técnicos internos. Configurar el aviso de inicio de sesión y los mensajes en Sophos Firewall explica la gestión global de los textos de administración, autenticación, SMTP y SMS.
6. Auto purge on expiry: Activar solo si los registros de usuario caducados deben eliminarse automáticamente y la evidencia operativa necesaria se conserva en otro lugar.
7. Guardar con Apply.

Auto purge on expiry elimina los datos de los usuarios invitados tras su caducidad, pero no afecta a los registros. Esta distinción es importante para la privacidad y el diagnóstico: la limpieza de cuentas y la conservación de registros son procesos separados.

Gestionar grupos de usuarios de forma segura en Sophos Firewall explica cómo interactúan las políticas de grupo, el Main Group y las excepciones de usuario. El Default Group no debe utilizarse de forma casual para invitados. Un grupo restrictivo propio facilita comprender sus efectos y revertir los cambios.

Para la automatización por API: La documentación de la API de SFOS 22 y 23 limita UserNamePrefix a 10 caracteres; guest- está dentro de ese límite. Es una restricción documentada de la API, no una prueba de la validación de todas las versiones de la interfaz gráfica. Se mantiene la recomendación de longitud de contraseña 16. Antes de cambiar la configuración, leer los ajustes actuales y comprobar con una sola cuenta piloto las credenciales realmente generadas, el grupo y la validez.

Los ejemplos de la API no son totalmente coherentes: PasswordComplexity utiliza valores simbólicos en el ejemplo, pero la tabla de atributos lo define como entero; AutoPurgeOnExpiry muestra Enable/Disable en el ejemplo y solo Enable en la tabla. No adivinar estos valores. Antes de una escritura por API, confirmar el esquema admitido para la versión concreta del dispositivo; de lo contrario, utilizar los campos documentados de la interfaz gráfica. Los valores predeterminados y los límites de dígitos de la API no establecen valores predeterminados ni límites de validez universales para la interfaz gráfica.

Activar el autorregistro solo cuando sea realmente necesario

El autorregistro puede activarse en Guest user registration settings. Es más complejo que la entrega controlada por un administrador o una recepción y requiere un proceso SMS fiable:

• Enable guest users registration: Activar solo si los invitados deben registrarse por sí mismos.
• SMS gateway: Seleccionar el proveedor probado previamente.
• Guest username: Utilizar el número de móvil o generar el nombre a partir de Username prefix.
• User validity: Definir la validez máxima de las cuentas autorregistradas en días.
• Default country code: Elegir un valor adecuado para el grupo real de usuarios. Este valor predeterminado se muestra junto al campo del número móvil en la página de registro de invitados.
• CAPTCHA verification: Mantener activado para dificultar los registros automatizados.
• Guardar con Apply.

El firewall admite gateways SMS basados en HTTP y HTTPS. Es preferible utilizar HTTPS para que las credenciales y los parámetros del proveedor no se transmitan sin cifrar. La URL, el método HTTP, el formato del número de móvil, los parámetros de solicitud y el formato de respuesta deben coincidir exactamente con la documentación del proveedor SMS utilizado. Las URL de ejemplo de una guía no deben copiarse a producción.

Test connection envía un mensaje de prueba a un número de móvil. Según Sophos, esta prueba puede fallar con un gateway SMS privado que tenga una dirección IP interna aunque el flujo real funcione. En ese caso no se presupone el éxito: se prueba el registro completo con un dispositivo móvil, el registro del proveedor y el mensaje SMS real.

Mapear correctamente los parámetros del gateway SMS

En Authentication > Guest user settings > SMS gateway > Add, introducir Name, URL, HTTP method con Get o Post, Cell number format y, cuando corresponda, Use country code with mobile phone number y Number prefix. La ayuda de la interfaz gráfica describe Number prefix como compatible con caracteres alfanuméricos y caracteres especiales ASCII. No es una garantía general para la API: su campo CellNumberPreFix excluye expresamente las comas.

Cada parámetro de la solicitud recibe un Name y un Value; SFOS sustituye {mobileno} y {msg} por el número de móvil y el mensaje. Para la respuesta, se asignan Parameter index y Name al Response format. Los nombres de los parámetros no los define SFOS y deben coincidir exactamente con el proveedor. Este esquema utiliza exclusivamente valores de ejemplo reservados:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

Sustituir sms.example.net, mobile, message y status por los valores del proveedor SMS real. Get solicita el recurso especificado; Post envía datos para su procesamiento. El método se elige según la API del proveedor, no por una preferencia general. Los caracteres especiales en los valores de URL exigidos por el proveedor deben codificarse en porcentaje, por ejemplo @ como %40. Las credenciales en la URL o solicitud son secretos y no deben aparecer en capturas, tickets ni logs. Si el proveedor las exige, se utiliza únicamente HTTPS y se documenta su caducidad.

Response format solo describe cómo interpretar la respuesta. En el ejemplo de la documentación, una respuesta como status=302&message=Limit Exceeded indica que se ha superado un límite, no que el SMS se haya enviado correctamente. Comprobar el estado de éxito o error según la documentación del proveedor y verificar la recepción real. Primero guardar el gateway con Save y después ejecutar Test connection con un número de móvil controlado.

Restricciones de la API y parámetros duplicados: Para SFOS 22 y 23, la API documenta un máximo de 100 caracteres y ninguna coma para el Name del gateway, y un máximo de 255 caracteres para ResponseFormat. Estas restricciones de la API no confirman los mismos límites en la interfaz gráfica. Los elementos duplicados de ParameterName y ParameterValue en las listas de solicitud y respuesta no se ignoran. Revisar cada par nombre/valor para detectar duplicados accidentales; conservar repeticiones intencionadas solo si las exige el proveedor. Esto no determina cómo las interpreta el proveedor ni implica que se envíen automáticamente varios SMS. La tabla de URL de la API también incluye FTP y direcciones IPv4, mientras que la ayuda de la interfaz gráfica describe HTTP/HTTPS. Esto no amplía esta guía a FTP ni al transporte sin cifrar: para secretos se utiliza exclusivamente HTTPS. Un estado de operación API 200 no sustituye la recepción real del SMS ni una prueba completa de registro. Utilizar un número de prueba controlado con consentimiento; pueden aplicarse costes del proveedor.

En Administration > Messages > SMS customization, seleccionar Edit, introducir un mensaje que coincida con la plantilla aceptada por el proveedor y guardarlo con Apply. Para el texto del mensaje están disponibles {username}, {password} y {expirydate}. Este paso guarda el mensaje por separado. Si la plantilla no coincide, el proveedor puede rechazar el mensaje y Test connection puede fallar.

La prueba del proveedor es solo una comprobación parcial: En el piloto, un invitado se conecta a la Wi-Fi de invitados, abre Register for internet access, rellena el formulario, completa el CAPTCHA y guarda con Save. Tras un registro correcto aparece la página de inicio de sesión. El SMS recibido realmente debe contener el nombre de usuario y la contraseña; el invitado inicia sesión con estos datos. A continuación, el registro debe aparecer en Authentication > Guest users y el inicio de sesión en Current activities > Live users. El tráfico debe registrarse con el usuario esperado y la Firewall Rule ID. Una regla amplia con Any no sustituye esta comprobación.

Si no hay gateway SMS, responsable o protección clara de la página de registro, el autorregistro permanece desactivado. Una persona responsable crea entonces las cuentas de forma controlada.

Crear cuentas de invitado individuales o múltiples

Crear una cuenta individual con nombre y correo electrónico

Para un visitante concreto, se abre Authentication > Guest users > Add single:

1. En Name, introducir por ejemplo Visitor Zurich 2026-08-11. Es el nombre del registro, no el nombre de usuario posterior.
2. Introducir la dirección de correo electrónico del responsable. Este campo no envía las credenciales; para ello Sophos documenta Add and print o el envío por SMS.
3. Establecer Validity period en el periodo necesario, 1 day en el ejemplo.
4. Elegir Validity start de forma consciente.
5. Guardar con Add o guardar e imprimir las credenciales con Add and print.

Immediately inicia la validez al crear la cuenta. Es adecuado cuando las credenciales se entregan y utilizan inmediatamente. After first login inicia el periodo con el primer inicio de sesión correcto. Esta opción suele ser mejor para cuentas preparadas con antelación porque la validez no caduca antes de la llegada.

Después de crear la cuenta, la lista muestra el nombre de usuario generado. No se debe confundir el nombre del registro con el nombre de usuario al entregar las credenciales.

Generar varias cuentas para un evento

En Authentication > Guest users > Add multiple se definen Number of users, Validity period y Validity start. Add crea las cuentas sin imprimir. Add and print crea las cuentas y las impresiones correspondientes.

Al crear cuentas mediante la API: SFOS 22 y 23 documentan un rango de 1–100 para NoOfUsers por solicitud. No es un máximo verificado para Add multiple en la interfaz gráfica. Dividir las emisiones mayores en lotes de API dimensionados de forma deliberada. Registrar antes la cantidad prevista, la plantilla global y el inicio de validez, y comprobar primero una sola cuenta. Tras cada solicitud, cotejar los nombres de usuario realmente creados y las impresiones; si la respuesta es incierta, leer la lista de cuentas antes de repetir a ciegas la solicitud de creación. El ejemplo de la API omite NoOfUsers aunque la tabla lo marca como obligatorio y no explica los valores 1/2/3 de Expirty Period type. No deducir de él una solicitud completa ni una correspondencia de valores de caducidad; confirmar primero el esquema de la versión. No reinterpretar Name como Username; entregar de forma controlada las credenciales generadas.

Solo deben crearse varias cuentas para un evento concreto. Las impresiones se cuentan, se guardan de forma segura y se entregan a una persona responsable. Las cuentas no utilizadas o caducadas se desactivan o purgan. Un gran inventario de credenciales sin asignar debilita las restricciones técnicas.

Comprobar el grupo, las políticas y los límites de inicio de sesión

Una nueva cuenta de invitado hereda primero el grupo seleccionado en Guest user settings. En Authentication > Guest users > Edit se comprueban el nombre, la contraseña, el número de móvil, el correo electrónico, el grupo y las políticas individuales, y se guarda con Save.

Las políticas específicas del usuario tienen prioridad sobre las políticas de grupo. Por ello, una excepción solo es adecuada cuando está documentada. Para un modelo de invitados uniforme, Access Time, Surfing Quota, Network Traffic, Traffic Shaping y Sign-in Restriction suelen mantenerse agrupados en Guest_Internet. Traffic shaping asocia al usuario con una política QoS que puede definir la asociación de políticas, la prioridad y límites separados de subida y descarga.

En el ejemplo se aplican estos límites:

• Sign-in restriction: User group nodes hereda la limitación del grupo de invitados. Para una excepción individual, limitar Selected nodes o Node range a los orígenes realmente necesarios. Any node solo encaja si los inicios de sesión desde todas las redes son intencionados y están protegidos por separado.
• Simultaneous sign-ins: 1, mientras no se autorice expresamente una cuenta para varios dispositivos. Limita las sesiones simultáneas; se puede heredar el valor global o definir uno individual.
• MAC binding: Normalmente desactivado para dispositivos de invitados cambiantes. El firewall tampoco vincula por direcciones MAC a los usuarios de VPN de acceso remoto. Al activarlo, solo se permite iniciar sesión desde los dispositivos especificados; sus direcciones MAC deben introducirse en MAC address list.
• Quarantine digest: Activar solo si la cuenta utiliza realmente Mail Protection y existe un proceso de cuarentena definido. Envía la lista de correos retenidos al buzón de entrada del usuario.
• Remote access policies: No planificarlas como acceso VPN para Guest users.

La validez de la cuenta resuelve una tarea diferente a las políticas de tiempo y consumo:

• Validity period determina durante cuánto tiempo puede utilizarse la cuenta de invitado.
• Access Time permite o bloquea el acceso a internet en ventanas horarias recurrentes.
• Surfing Quota y Network Traffic Quota limitan el tiempo en línea o el volumen de datos.
• Una regla de firewall determina qué zonas, destinos y servicios son accesibles.

La validez de la cuenta y los límites de tiempo y consumo no sustituyen una regla de firewall restrictiva. Una cuenta válida no debe acceder a un servidor interno si la regla de firewall no lo permite expresamente.

Conectar el Captive Portal y la ruta de tráfico

Los Guest users suelen iniciar sesión a través del Captive Portal. Device Access, DNS, HTTPS, la regla de usuario y el método de autenticación seleccionado deben coincidir. El portal por sí solo no permite el acceso a internet.

Configurar DNS y la regla de usuario por separado

En Rules and policies > Firewall rules, seleccionar el protocolo IP adecuado y Add firewall rule > New firewall rule. La guía de ejemplo de SMS utiliza dos reglas de WiFi a WAN: una para DNS y otra para tráfico de usuarios con Any. En la red de invitados real, se restringen estos valores amplios del ejemplo:

1. Configurar la regla DNS con Action: Accept, Source zones: Guest y la red 10.30.40.0/24 en Source networks and devices. En Destination networks, seleccionar solo los resolvedores previstos y, en Services, solo DNS. Destination zones debe corresponder a la ubicación real de los resolvedores; WAN solo es correcto para resolvedores externos. Esta resolución de nombres necesaria no debe exigir un inicio de sesión previo.
2. Configurar también la regla de usuario con Action: Accept, la misma zona de invitados y red de origen, Destination zones: WAN y solo los destinos y servicios de internet previstos. Activar Match known users, seleccionar Guest_Internet en Users or groups y activar Use web authentication for unknown users. Las páginas de ayuda de SMS de SFOS 22 y 23 todavía denominan esta última opción Show captive portal to unknown users; las páginas actuales de reglas de firewall de ambas versiones utilizan Use web authentication for unknown users. La diferencia de etiquetas no demuestra un comportamiento distinto.
3. Activar Log firewall traffic y guardar cada regla con Save. Comprobar su posición para que ninguna regla anterior de permiso amplio omita la comprobación de usuario y sigan siendo efectivos los bloqueos de redes internas y servicios de administración. NAT y el acceso al portal se siguen comprobando por separado. Antes del inicio de sesión, una conexión no debe disponer de acceso libre a internet más allá de los servicios previos a la autenticación expresamente necesarios.

Guest y 10.30.40.0/24 representan la zona preparada y su red real. Los resolvedores, destinos y servicios de internet se eligen según la finalidad del acceso de invitados, no se establecen todos en Any. Si el propio firewall actúa como resolvedor DNS, se trata de un servicio local: permitir el acceso DNS en Administration > Device access solo desde la zona de invitados, en lugar de copiar una regla DNS hacia WAN.

Verificar el inicio de sesión y las restricciones

Desde la red de invitados se realizan pruebas completas, tanto positivas como negativas:

1. El cliente recibe una dirección, un gateway y DNS de la red de invitados.
2. https://login.example.com:8090 es accesible y muestra el certificado correcto.
3. Una solicitud web normal conduce al portal.
4. Una cuenta de invitado válida puede iniciar sesión.
5. En Current activities > Live users aparecen el nombre de usuario y la IP de origen.
6. La prueba de internet permitida coincide con la regla de usuario y la Firewall Rule ID esperadas.
7. Un destino interno y un servicio no permitido siguen bloqueados.
8. Una cuenta caducada o desactivada, o unas credenciales introducidas deliberadamente de forma incorrecta son rechazadas.

En una red de invitados de doble pila, este proceso se prueba por separado para IPv4 e IPv6, ya que SFOS trata de forma independiente la autenticación web para destinos IPv4 e IPv6. Además, en Authentication > Web authentication > Sign out user se define y se prueba cuándo finaliza la sesión. Never no es apropiado para un acceso de invitados de duración limitada.

El procedimiento completo de reglas, Device Access y HTTPS se explica en Configurar y probar el Captive Portal de Sophos Firewall. La guía de portales Sophos distingue User Portal, VPN Portal y Captive Portal.

Entregar credenciales y operar cuentas

En Authentication > Guest users están disponibles varias acciones operativas:

• Print: Seleccionar los usuarios previstos en la lista y entregar sus credenciales de forma controlada.
• Resend credentials: Reenviar las credenciales mediante el gateway SMS configurado.
• Change status: Establecer una cuenta como activa o inactiva.
• Change password: Asignar una nueva contraseña tras una pérdida o sospecha de exposición.
• View usage: Comprobar el uso de internet y el estado de las cuotas.
• Reset user accounting: Restablecer los contadores de consumo y reiniciar la Network Traffic Quota.

Reset user accounting cambia el estado. Antes se documentan la cuenta, el consumo actual, la hora y el motivo. No se utiliza como primer paso de diagnóstico porque modifica las evidencias y puede conceder más cuota al invitado.

Para la baja, primero se desactiva la cuenta. En Current activities > Live users, se selecciona su sesión activa y se finaliza con Disconnect; después se verifica que fallen un nuevo inicio de sesión y el acceso por la ruta de datos. A continuación se comprueban las impresiones no utilizadas, el acceso SMS y posibles excepciones específicas del usuario. El registro se elimina o se deja que Auto purge on expiry lo retire solo cuando ya no existe ninguna dependencia.

Retirar un gateway SMS de forma segura: Registrar antes el nombre exacto del perfil existente, la selección en Guest user registration settings y cualquier necesidad de Resend credentials. Documentar la configuración sin secretos y guardar los secretos necesarios por separado y de forma segura para preparar una recreación manual; esto no hace reversible la eliminación. Mientras se necesiten el registro o el reenvío de credenciales, seleccionar primero un sustituto y verificar la recepción del SMS, el registro completo, el inicio de sesión y el reenvío con una cuenta piloto controlada. Si se abandona el autorregistro, desactivarlo antes de retirar el perfil; eso por sí solo no resuelve las obligaciones de reenvío. Conservar el perfil antiguo si no se puede verificar una ruta SMS necesaria.

Una eliminación autorizada por API requiere el Name exacto del perfil antiguo; no enviar una eliminación sin un objetivo concreto. La operación documentada no demuestra la existencia de un botón de eliminación concreto en la interfaz gráfica ni de comprobaciones automáticas de dependencias. Después del cambio, volver a leer la lista de perfiles y la selección del gateway, y comprobar las rutas de registro y envío que sigan siendo necesarias.

Antes del piloto se documentan la configuración global, el gateway SMS, el grupo y la regla. Para revertir los cambios, se restablece cada valor modificado; como alternativa, se desactivan el autorregistro y la regla piloto. Restaurar una copia de seguridad completa no es una operación rápida de deshacer: sustituye la configuración actual y reinicia el firewall; en HA, restaurar el Primary también provoca una interrupción. Esta opción se reserva para el procedimiento de emergencia documentado.

Diagnosticar de forma sistemática

El nombre del registro no funciona como nombre de usuario

Con Add single, Name es solo la etiqueta del registro de usuario. El nombre de usuario real se genera a partir de Guest user settings y aparece en la lista o en la impresión de credenciales. Se utiliza exactamente ese valor junto con la contraseña generada o modificada.

La cuenta es válida inmediatamente o aún no lo es

Comprobar Validity start y Validity period. Con Immediately, el tiempo empieza al crear la cuenta; con After first login, empieza con el primer inicio de sesión correcto. También se comprueban la hora y la zona horaria del firewall. Una regla de firewall más amplia no repara una cuenta caducada.

El autorregistro no envía un mensaje SMS

Comprobar si Enable guest users registration está activado, si se ha seleccionado el SMS gateway correcto y si el número de móvil, el country code, la URL, el método HTTP, los parámetros de solicitud y el formato de respuesta coinciden con el proveedor. Después se comprueban el registro del proveedor y la entrega real del SMS.

Un Test connection correcto no prueba todo el flujo de registro y Captive Portal. A la inversa, según Sophos, una prueba fallida contra un gateway interno privado no demuestra automáticamente que la ruta SMS esté rota. En ambos casos se prueba con una cuenta piloto real.

El inicio de sesión funciona, pero el acceso a internet no

En Current activities > Live users, comprobar si el invitado aparece con la IP de origen esperada. Después se revisan el grupo, las excepciones específicas del usuario, la validez, Access Time y las cuotas. En Log Viewer, el tráfico de prueba debe coincidir con la regla de usuario y la Firewall Rule ID esperadas.

Si el usuario no aparece en Live users, primero se inspecciona la ruta de inicio de sesión con access_server.log y la hora documentada de la prueba. Si el usuario es visible, el siguiente control corresponde a la regla, el enrutamiento, NAT, DNS o la política de protección. Diagnosticar errores de autenticación de forma sistemática separa estas fases.

La cuenta de invitado no puede seleccionarse para SSL VPN

Es el comportamiento esperado del producto. Guest users y Guest groups no son Policy members válidos para el acceso remoto SSL VPN ni para el acceso remoto IPsec. Para un técnico externo que necesita VPN se utiliza un usuario normal con permisos mínimos, MFA y la política de acceso remoto adecuada.

Comprobación final

• El invitado solo puede acceder a los destinos previstos; las redes internas y los servicios de administración siguen bloqueados.
• La validez, Access Time, las cuotas y las excepciones coinciden con el proceso de entrega.
• El autorregistro permanece desactivado hasta superar el piloto de SMS y CAPTCHA.
• Live users, el ID de regla y las pruebas positiva y negativa confirman la asignación esperada.
• La baja desconecta las sesiones activas y elimina las credenciales e impresiones que ya no se necesitan.
• Reset user accounting solo se ejecuta con un motivo documentado.

Preguntas frecuentes