Configurar Clientless SSL VPN para RDP y SSH en Sophos Firewall

Con Clientless SSL VPN, Sophos Firewall ofrece conexiones individuales a servidores internos RDP, SSH, VNC o de archivos directamente en el navegador. El usuario no instala ningún cliente VPN ni obtiene acceso general a una red interna. En su lugar, inicia sesión en el VPN Portal y solo ve los bookmarks publicados por la clientless policy que se le ha asignado.

El nombre parecido puede conducir fácilmente a la configuración equivocada: Clientless Users asigna internamente una IP fija a una identidad. No publica bookmarks ni forma parte de este procedimiento de Remote Access.

El inicio de sesión en el VPN Portal y el inicio de sesión en el destino son dos pasos distintos. Clientless SSL VPN no admite la transferencia de credenciales: la contraseña del VPN Portal no se reenvía automáticamente como inicio de sesión de Windows o SSH. Por tanto, es normal iniciar sesión dos veces mientras no se guarden las credenciales del destino en el bookmark.

El proceso básico es breve:

Definir un sistema de destino fijo, el puerto y el grupo de usuarios autorizado.
Crear un bookmark RDP o SSH en Remote access VPN > Clientless SSL VPN policy > Bookmarks.
Vincular el grupo de usuarios y el bookmark en Policies.
Proteger el VPN Portal, el certificado, la autenticación, MFA y Device Access.
Probar el acceso desde el exterior en VPN > Clientless access connections con un usuario autorizado y otro no autorizado.

Cuándo conviene Clientless SSL VPN y cuándo no

Clientless Access resulta especialmente adecuado para unos pocos destinos fijos, accesos ocasionales o técnicos externos cuando no se debe instalar un cliente VPN en el dispositivo utilizado. De este modo, RDP y SSH no tienen que publicarse directamente en Internet mediante DNAT. En su lugar, el VPN Portal protegido queda accesible públicamente.

Sin embargo, no sustituye a todas las modalidades de Remote Access VPN:

Clientless SSL VPN es adecuado para destinos estáticos individuales RDP, SSH, VNC o de servidores de archivos que pueden utilizarse en el navegador.
Sophos Connect con IPsec o SSL VPN resulta más adecuado cuando un dispositivo administrado necesita varias redes, aplicaciones nativas, DNS o distintos protocolos. La guía de decisión sobre Remote Access explica las opciones.
ZTNA está diseñado para un acceso permanente y específico a aplicaciones con identidad, estado del dispositivo y policies centrales. Los fundamentos se explican en ¿Qué es Zero Trust Network Access?.
Conviene valorar RD Gateway, un jump host o PAM cuando resulten imprescindibles la administración privilegiada, las cuentas personales en el destino, la grabación de sesiones o los workflows de aprobación.

En el caso de RDP, también hay que tener en cuenta que el portapapeles no es compatible con las sesiones clientless desde SFOS 19. Si copiar y pegar u otras funciones RDP nativas son imprescindibles para el workflow, un método de acceso basado en cliente o especializado es la mejor opción.

Clientless SSL VPN no admite direcciones IP de destino dinámicas. Se permite utilizar un nombre de host como destino, pero Sophos Firewall debe resolverlo de forma estable y este debe apuntar al sistema previsto. Un destino que cambia con frecuencia no debe planificarse como un escenario de Dynamic DNS actualizado de forma fiable.

El navegador es solo la interfaz: establece la conexión HTTPS con el VPN Portal, mientras Sophos Firewall establece una segunda conexión con el destino. El bloqueador de ventanas emergentes debe permitir la nueva ventana para el FQDN del portal. SFOS 22 no permite publicar aplicaciones HTTP o HTTPS internas arbitrarias como bookmarks clientless; para ellas se utiliza WAF o ZTNA según los requisitos.

Requisitos y valores de ejemplo

Antes de la configuración, deben aclararse el destino, la identidad y el acceso al portal:

El sistema de destino es accesible desde Sophos Firewall mediante routing y DNS, y el servicio necesario está en ejecución.
Existe un usuario o, preferiblemente, un grupo restringido en Sophos Firewall o en el servidor de autenticación conectado.
El VPN Portal cuenta con un FQDN público o accesible internamente y un certificado de confianza adecuado.
En Authentication > Services se ha seleccionado un método adecuado en VPN portal authentication methods.
Se han preparado MFA y un acceso de recuperación independiente.
Se ha decidido si se permite guardar las credenciales del destino en el bookmark.

El siguiente ejemplo RDP utiliza:

VPN Portal: https://vpn.example.com
Servidor de destino: rdp-app01.intern.example
IP de destino: 10.20.30.25
Puerto RDP: 3389
Bookmark: RDP-Fibu-Test
Grupo: Clientless-RDP-Fibu
Policy: Clientless-RDP-Fibu
Seguridad RDP para la primera prueba: TLS
Automatic login: desactivado
Share session: desactivado

example.com es un dominio reservado para ejemplos y 10.20.30.25 es una dirección privada de ejemplo. El FQDN, la IP, el grupo y los nombres deben sustituirse por los valores del entorno correspondiente. El puerto 3389 solo es correcto si el servidor Windows utiliza realmente el puerto RDP estándar.

Configurar un bookmark RDP

Bookmark con TLS e inicio de sesión personal en el destino

En Remote access VPN > Clientless SSL VPN policy > Bookmarks, se crea un nuevo bookmark con Add:

Introducir RDP-Fibu-Test en Name.
Seleccionar RDP como Type.
Introducir rdp-app01.intern.example o la IP fija 10.20.30.25 en URL.
Utilizar el puerto de servicio 3389. Solo debe introducirse un puerto diferente si se ha configurado deliberadamente de otro modo en el sistema de destino.
Dejar Automatic login desactivado para la primera prueba.
Si es necesario, introducir el dominio de red de Windows, por ejemplo CORP o corp.example.com.
Seleccionar TLS en Protocol security. La tercera opción, RDP, utiliza la seguridad propia del protocolo RDP; Sophos recomienda TLS o NLA.
Dejar Share session desactivado.
Guardar con Save.

Sin Automatic login, el usuario introduce sus credenciales en la ventana RDP que se abre. De esta forma, puede iniciar sesión con una cuenta personal de Windows siempre que el modelo de seguridad del servidor de destino permita este modo TLS.

El certificado del VPN Portal y Protocol security: TLS cumplen funciones distintas. El certificado del portal protege la conexión del navegador con Sophos Firewall. El ajuste RDP protege la conexión posterior desde Sophos Firewall hasta el sistema Windows. Por tanto, un certificado válido del portal no sustituye una configuración adecuada de seguridad RDP.

Cuando el servidor Windows exige NLA

Muchos sistemas Windows exigen Network Level Authentication (NLA). En ese caso, se selecciona NLA en el bookmark. SFOS activa entonces Automatic login, y el nombre de usuario y la contraseña del sistema de destino deben guardarse en el bookmark.

No se trata de una simple opción de comodidad. Todos los usuarios autorizados para este bookmark trabajan en el sistema de destino con la misma identidad de Windows guardada. Para ello solo debe utilizarse una cuenta específica, con privilegios mínimos y credenciales que puedan rotarse. Las cuentas Domain Admin, las cuentas personales de administrador y las cuentas de servicio con privilegios amplios no deben guardarse en un bookmark clientless.

No se debe desactivar NLA en el servidor Windows únicamente para que funcione el ejemplo con TLS. Si las credenciales guardadas o una identidad de destino compartida no son aceptables, Clientless RDP no es adecuado para ese servidor. Una VPN normal, RD Gateway, PAM o un jump host controlado conservan mejor la trazabilidad personal.

También debe dejarse Share session desactivado. Esta opción está destinada a un caso de colaboración planificado de forma consciente. En una sesión compartida, Stop session finaliza la conexión para todos los participantes, mientras que Suspend session solo pausa al usuario actual. No se deben compartir sesiones para la administración privilegiada.

Bookmark VNC para sistemas Linux y UNIX

Un bookmark VNC sigue el mismo principio básico, pero utiliza Type: VNC. En URL se introduce la dirección IP fija del sistema de destino o un hostname con resolución estable. Solo se indica otro puerto VNC si el servicio escucha realmente en un puerto distinto del estándar.

Con Automatic login, SFOS guarda la contraseña del destino en el bookmark VNC. Si la opción permanece desactivada, el usuario introduce la contraseña al abrir la conexión. En un bookmark VNC no se configura ningún nombre de usuario. Share session permanece desactivado para accesos individuales normales y solo se utiliza cuando se requiere expresamente una sesión compartida.

ℹ️ El inicio de sesión en el VPN Portal tampoco se transfiere al sistema de destino en VNC. Por tanto, un login correcto en el portal no demuestra que la contraseña VNC sea correcta ni que la firewall pueda alcanzar el servicio VNC.

Configurar la clientless policy y el VPN Portal

Vincular usuarios y bookmarks en una policy

La mera existencia de un bookmark no hace que el destino sea visible para ningún usuario. La policy vincula la identidad y el recurso:

Abrir Remote access VPN > Clientless SSL VPN policy.
En Policies, seleccionar Add.
Introducir Clientless-RDP-Fibu como Name.
En Policy members, seleccionar únicamente el grupo Clientless-RDP-Fibu.
En Published bookmarks, seleccionar RDP-Fibu-Test.
Guardar con Apply.

Un bookmark group solo resulta útil cuando los mismos usuarios necesitan varios destinos. Para un único destino RDP, solo añade otra capa de administración.

Proteger el VPN Portal

Los usuarios abren las conexiones clientless mediante el VPN Portal. El puerto predeterminado es 443; el puerto y el certificado se configuran en Administration > Admin and user settings > Admin console and end-user interaction. En este ejemplo, el certificado debe contener vpn.example.com como SAN y el navegador debe aceptarlo sin advertencias. Importar y asignar certificados en Sophos Firewall explica la asignación general de certificados.

En Administration > Device access, debe permitirse VPN portal para el acceso que realmente se necesita. Si el portal debe ser accesible desde todas las fuentes WAN, se activa WAN en la matriz. Para redes de origen conocidas, es mejor utilizar la variante más restrictiva: dejar WAN desactivado en la matriz y crear una regla en Local service ACL exception rule con Source zone: WAN, el Source Network / Host concreto, la dirección necesaria de Sophos Firewall como Destination host, Services: VPN portal y Action: Accept. Una excepción Accept adicional no restringe un permiso WAN general ya activado en la matriz. Esto tampoco habilita automáticamente WebAdmin, User Portal, SSH o SSL VPN. Las Firewall Rules no controlan estos servicios locales. La planificación segura se explica en Device Access y Local Service ACL.

⚠️ Un VPN Portal accesible desde la WAN es una superficie pública de inicio de sesión. No debe utilizarse sin MFA, un certificado de confianza, una pertenencia restringida a la policy y la supervisión de los inicios de sesión. Si VPN Portal y SSL VPN utilizan el mismo puerto, los Login security settings no funcionan. Si además utilizan el mismo protocolo, permitir SSL VPN desde una zona también hace accesible VPN Portal, aunque esté desactivado para esa zona en Device access. Se debe utilizar una combinación única de puerto y protocolo para cada servicio local y volver a comprobar el acceso después de cada cambio de puerto.

Para Sophos OTP local, primero se utiliza Specific users and groups en Authentication > Multi-factor authentication. Para el autorregistro mediante una aplicación de autenticación, se activa Generate OTP token with next sign-in, se selecciona VPN portal en Require MFA for y se guarda con Apply. Este flujo directo de código QR en VPN Portal corresponde a SFOS 22. En SFOS 23, con Generate OTP token with next sign-in activado, también se selecciona Share QR code antes de Apply: Email envía el código QR por correo en el siguiente inicio de sesión en VPN o User Portal; Portals lo muestra en User Portal y VPN Portal después del siguiente inicio de sesión en VPN Portal, User Portal o WebAdmin. Para el ejemplo de escaneo en el portal, seleccionar explícitamente Portals. SFOS 22 admite SHA1, SHA256 y SHA512, y Sophos recomienda SHA256 o SHA512. Sin embargo, la aplicación debe admitir el algoritmo elegido: Intercept X for Mobile y Google Authenticator son compatibles; Microsoft Authenticator puede escanear un código SHA256 o SHA512, pero el inicio de sesión posterior falla. Al cambiar el algoritmo, se eliminan los tokens existentes en Issued tokens y después se vuelve a escanear el código QR. Antes de eliminarlos, comprobar que Generate OTP token with next sign-in esté activado para este flujo. La entrega del nuevo código QR sigue la misma distinción de versiones: SFOS 22 lo muestra en el portal; SFOS 23 utiliza Email o Portals en Share QR code, manteniendo Portals para este ejemplo. Activar MFA en Sophos Firewall explica la prueba piloto y el proceso de recuperación. El VPN Portal no admite MFA RADIUS basado en challenge; por tanto, un método RADIUS existente debe probarse específicamente para este inicio de sesión en el portal. Si en su lugar el portal debe utilizar Microsoft Entra ID SSO y Conditional Access, Entra ID SSO para Sophos Connect y VPN Portal describe la cadena de identidad completa.

En Authentication > Services se pueden seleccionar como máximo 20 servidores por método de autenticación. Los ajustes globales Maximum session timeout y Simultaneous logins no son exclusivos de VPN Portal. SFOS comprueba la autorización cada tres minutos, y el límite de sesiones simultáneas solo se aplica a los usuarios añadidos después de establecer el valor. Por tanto, estos límites no deben considerarse controles de acceso inmediatos y específicos del portal.

Probar el acceso desde el exterior

La prueba debe realizarse desde una red realmente externa, por ejemplo, mediante un punto de acceso móvil. Una prueba desde la LAN no demuestra que DNS, el certificado, Device Access y un router anterior funcionen correctamente desde Internet.

Abrir https://vpn.example.com en una ventana privada del navegador.
Comprobar el nombre del certificado, la cadena de certificados y el estado del navegador.
Iniciar sesión con un miembro de Clientless-RDP-Fibu y completar MFA.
En VPN > Clientless access connections, comprobar que aparece RDP-Fibu-Test.
Seleccionar Connect. La sesión debe abrirse en una nueva ventana del navegador.
Con Automatic login desactivado, introducir las credenciales personales de Windows y comprobar el inicio de sesión RDP.
Cerrar correctamente la sesión en el sistema Windows y salir después del VPN Portal.
Probar con un usuario que no pertenezca al grupo. El bookmark no debe aparecer para ese usuario.
Retirar temporalmente el usuario de prueba del grupo de la policy y comprobar que el acceso desaparece después de iniciar una nueva sesión.

El éxito no significa únicamente que se muestre un escritorio. El usuario de la prueba positiva ve exactamente los bookmarks previstos, el de la prueba negativa no ve ninguno, MFA se aplica, el certificado es de confianza, el inicio de sesión en el destino funciona y el final de la sesión puede rastrearse tanto en el portal como en el sistema de destino.

Utilizar los controles de sesión y teclado en el navegador

En las sesiones RDP, VNC, SSH y Telnet, se mueve el puntero al borde superior de la pantalla remota para mostrar las opciones de sesión. En Connection están disponibles Stop session y Suspend session. Después de Suspend session, el mismo usuario reanuda la sesión la próxima vez que selecciona Connect en el VPN Portal. Los demás participantes de una sesión compartida continúan trabajando; en cambio, Stop session la finaliza para todos.

En las conexiones RDP y VNC, Keyboard permite seleccionar combinaciones de teclas y cambiar el idioma del teclado. Para aplicar uno de los idiomas de la lista distinto del inglés, el procedimiento documentado exige que el idioma del servidor de destino esté configurado en US English. Este requisito afecta a la selección de idioma en Keyboard, no al portapapeles.

Opciones para SSH, VNC y servidores de archivos

Bookmark SSH con un Host Key verificado

Para SSH, se selecciona SSH como Type en Bookmarks > Add. Este ejemplo utiliza srv-linux01.intern.example, el puerto 22 y el usuario clientless-test.

El Public host key debe pertenecer al servidor esperado. En un destino Linux, el Host Key público puede mostrarse directamente en la consola de confianza del servidor y se puede documentar su fingerprint:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Estos comandos se ejecutan en el servidor Linux de destino, no en Sophos Firewall. Si el servidor utiliza otro tipo de Host Key, debe adaptarse el nombre del archivo. No se acepta a ciegas un Key procedente de una advertencia del navegador no verificada o de cualquier escaneo de red.

El primer comando muestra el Host Key ED25519 público como ejemplo de identificación en la consola de confianza del destino. Esto no confirma que la compilación instalada de SSH clientless acepte ED25519 o la representación OpenSSH mostrada en Public host key. Antes de insertarlo, confirmar tanto el algoritmo aceptado como la representación serializada de la clave pública mediante la documentación oficial de SSH clientless aplicable a esa compilación o con Sophos Support. La compatibilidad de SSH en Linux, los ajustes de SSH de WebAdmin, SFTP y textos fuente idénticos no demuestran esta compatibilidad del campo. El segundo comando solo muestra el fingerprint para la comparación documentada; el fingerprint no se pega en el campo en lugar del Key.

A continuación, se crea el bookmark SSH completo:

En Name, introducir por ejemplo SSH-Linux-Test.
Seleccionar SSH como Type.
Introducir srv-linux01.intern.example en URL y 22 como puerto.
En Username, indicar clientless-test o el usuario de destino previsto.
Dejar Automatic login desactivado si el usuario debe introducir personalmente la contraseña del destino.
Pegar en Public host key el Host Key público comprobado directamente en el sistema de destino solo después de confirmar el algoritmo y la representación para la compilación instalada de SSH clientless.
Dejar Share session desactivado y guardar con Save.
Añadir el bookmark a la clientless policy en Published bookmarks y guardar con Apply.
En el VPN Portal, seleccionar Connect en VPN > Clientless access connections, introducir la contraseña del destino y comprobar que aparece el terminal esperado. Después, cerrar correctamente la sesión SSH.

Sin Automatic login, el usuario introduce la contraseña del destino al establecer la conexión; el nombre de usuario sigue formando parte del bookmark. Por tanto, distintos nombres de usuario SSH personales requieren bookmarks independientes u otro método de acceso. Con Automatic login, SFOS puede utilizar una contraseña o una Private Key. Las Private Keys privilegiadas o de uso extendido no deben guardarse en un bookmark compartido.

Servidores de archivos con FTP, FTPS, SFTP o SMB

Los bookmarks de servidores de archivos también se crean en Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add. En Type están disponibles FTP, FTPS, SFTP y SMB. URL contiene una dirección IP fija o un hostname estable; Clientless SSL VPN no admite direcciones de destino dinámicas. En Init remote folder se puede indicar opcionalmente la carpeta inicial que verá el usuario después de conectarse.

Los métodos se diferencian principalmente por el transporte y la autenticación en el destino:

FTP, FTPS y SMB pueden utilizarse con o sin Automatic login. Sin credenciales guardadas, el usuario inicia sesión en el sistema de destino después de abrir el bookmark. FTP transmite sin cifrado y no debe utilizarse para nuevos workflows externos.
Para SMB, también se puede introducir opcionalmente el dominio de red de Windows al que pertenecen la cuenta y el sistema de destino, por ejemplo CORP, corp.example o corp.example.com. Estos ejemplos deben sustituirse por el dominio real del entorno.
FTPS protege la conexión FTP mediante TLS. En Public host key también se guarda el certificado esperado del servidor en formato .pem. El certificado y el nombre se verifican directamente en el sistema de destino administrado, no a partir de una conexión sin comprobar.
SFTP utiliza SSH. El bookmark contiene el usuario de destino y, en Authentication method, Password o Private key con la credencial de destino correspondiente. Public host key sirve para verificar la identidad del servidor. La clave privada del usuario y la Host Key pública del servidor cumplen funciones diferentes y no deben confundirse.

⚠️ El formato de entrada de Public host key para SFTP sigue sin estar aclarado: las instrucciones de servidores de archivos para SFOS 22 y 23 indican un certificado de servidor en formato .pem, mientras que las instrucciones independientes de SSH exigen una clave pública del servidor. Esto no confirma un requisito X.509 ni la aceptación de valores OpenSSH o ED25519 en el campo SFTP. Por tanto, los comandos SSH anteriores no constituyen una guía de formato para SFTP. Antes del uso en producción, aclarar con Sophos Support la representación aceptada para SFTP en la compilación instalada y verificar la identidad del servidor directamente en el sistema de destino de confianza; no convertir formatos por suposición ni omitir la verificación de identidad.

También en los bookmarks de servidores de archivos se indica otro puerto de servicio solo si el servicio correspondiente del servidor de destino utiliza realmente un puerto distinto del predeterminado.

Con Automatic login, el nombre de usuario y la contraseña del sistema de destino se guardan en el bookmark para FTP, FTPS y SMB. Todos los usuarios autorizados utilizan entonces esa identidad de destino guardada, por lo que se aplican los mismos requisitos de privilegios mínimos y rotación que en el ejemplo NLA. No se trata de una transferencia de credenciales desde el VPN Portal.

En este procedimiento SFTP, SFOS autentica automáticamente con las credenciales del destino guardadas en el bookmark. No se solicita al usuario la contraseña del destino; el inicio de sesión interactivo opcional de SSH, FTP, FTPS y SMB no se aplica a SFTP.

En el navegador, las sesiones FTP, FTPS y SFTP permiten transferir archivos, crear carpetas y navegar por directorios. SFOS inicia las descargas sin otra confirmación y las guarda en la carpeta de descargas predeterminada del dispositivo. Por eso deben probarse los permisos, la carpeta inicial y archivos no sensibles antes del uso productivo. Un bookmark de servidor de archivos no crea una unidad de red normal de Windows ni sustituye la comprobación de permisos personales en el servidor de destino.

Los botones de la esquina superior derecha de las sesiones FTP, FTPS y SFTP permiten detener la sesión, subir un archivo, crear una carpeta y acceder a la carpeta superior.

Telnet sigue disponible como tipo de terminal, pero no cifra el transporte. No debe utilizarse para nuevos accesos. Los bookmarks HTTP y HTTPS no se encuentran entre los tipos clientless documentados actualmente para SFOS 22. Según la protección necesaria, Web Application Firewall o ZTNA es la arquitectura más adecuada para aplicaciones web internas.

Si un dispositivo antiguo exige Telnet temporalmente, seleccionar Type: Telnet en Bookmarks > Add, introducir el host fijo en URL e indicar un puerto solo si difiere del estándar. Share session es opcional. Limitar este acceso sin cifrar a un grupo reducido y un destino de gestión aislado, y sustituirlo después por SSH.

Si los mismos destinos deben asignarse a varias policies, se crea un grupo en Bookmark groups > Add: introducir el nombre del grupo en Name, seleccionar los bookmarks existentes con Add new item y guardar con Save. La policy publica después el grupo en lugar de cada destino por separado. Un Bookmark Group no amplía los permisos en el sistema de destino; únicamente simplifica la asignación en SFOS.

Al crear o modificar un grupo mediante la XML API, la entidad se llama SSLBookmarkGroup. La documentación de la API para SFOS 23.0 permite caracteres UTF-8 en su Name, prohíbe las comas y mantiene el máximo de 50 caracteres. La documentación de SFOS 22.0 ya indica este máximo, pero no las dos reglas adicionales sobre caracteres; esto no permite determinar cómo las aplican las compilaciones anteriores. Un nombre de ejemplo válido es Clientless-München, como en <Name>Clientless-München</Name>; debe adaptarse al entorno. Tras la llamada a la API, se comprueban el código de estado y el mensaje de la respuesta XML y se vuelve a consultar el grupo guardado: el nombre y los bookmarks incluidos deben coincidir con la asignación prevista. Esta nota se refiere al nombre del grupo en la API, no establece una regla general para los nombres de bookmarks individuales; en la interfaz descrita arriba se siguen los requisitos de los campos de la compilación instalada.

Bookmarks individuales mediante la XML API: El ejemplo Add/Edit para SSLBookmark en SFOS 22.0 y 23.0 es una referencia con ramas según el tipo, no un payload ejecutable común para todos los protocolos. Los valores HTTP y HTTPS que contiene no demuestran la compatibilidad actual en la interfaz ni en la compilación instalada. En el ejemplo, NLA exige que AutoLogin esté activado; para SSH/SFTP, el comentario describe la contraseña o la clave privada como alternativas con AutoLogin activado. Esto no elimina las limitaciones de Host Key SSH y de formato SFTP descritas anteriormente ni implica un inicio de sesión SFTP interactivo.

Sin embargo, la tabla de parámetros marca Private Key, Public Host Key y UserName como campos obligatorios sin especificar el tipo al que se aplican. Restringe URL a caracteres propios de un nombre de host, mientras que la segunda fila Domains, destinada a una lista de dominios/URLs a los que se redirige, exige que los valores comiencen por HTTP:// o HTTPS://. En el ejemplo, esta lista aparece bajo el token literal RefferredDomains; no es el dominio de Windows Domain para RDP/SMB, aunque la tabla también contiene una fila de RDP llamada Domains. No cambiar los nombres de los tokens por suposición ni combinar las reglas contradictorias de la tabla en un payload universal. Antes de realizar un cambio automatizado, aclarar los campos, las condiciones y las representaciones aceptados para el tipo y la compilación instalada mediante la documentación oficial correspondiente o con Sophos Support; hasta entonces, no ejecutar la modificación no confirmada. Antes del cambio, guardar el bookmark real y sus asignaciones como estado inicial; después, comprobar el estado y el mensaje XML y volver a consultar el bookmark guardado, su pertenencia a grupos y su publicación. Si hay discrepancias, revertir únicamente el cambio propio para restaurar ese estado inicial exacto y repetir las pruebas de acceso; no incluir contraseñas ni claves privadas en las salidas de auditoría ni en archivos de payload sin protección.

Diagnosticar errores habituales

No se puede acceder al VPN Portal: comprobar la entrada DNS pública, el puerto, el NAT anterior, Administration > Device access y un posible efecto de compartir el puerto.
Falla el inicio de sesión en el portal: comprobar en Authentication > Services la autenticación del VPN Portal, el estado del usuario, MFA y access_server.log.
No aparece Clientless access connections: el usuario no está asignado a ninguna clientless policy o la policy no publica ningún bookmark.
El bookmark es visible para el usuario equivocado: comprobar Policy members, la pertenencia a grupos y Published bookmarks. Si coinciden varios grupos, Clientless SSL VPN puede combinar los permisos de las policies correspondientes. Las pruebas positiva y negativa deben verificar qué bookmarks ve en consecuencia un usuario real.
El bookmark se abre, pero el destino sigue sin estar accesible: comprobar la resolución DNS desde la perspectiva de Sophos Firewall, la dirección estática del destino, el routing, el puerto de destino, el estado del servicio y el host firewall.
El inicio de sesión en el VPN Portal funciona, pero el de Windows no: los inicios de sesión en el portal y en el destino son distintos. Comprobar el dominio, la cuenta de destino, la contraseña y TLS o NLA.
NLA activa Automatic login: este es el comportamiento documentado. No se debe desactivar NLA sin planificación; en su lugar, hay que reevaluar el modelo de cuentas y acceso.
SSH informa de otro Host Key: detener la conexión y comprobar el cambio directamente en el sistema de destino o con el operador responsable. Un Key inesperado puede indicar una reinstalación, un destino incorrecto o un ataque.

En Diagnostics > Tools > Troubleshooting logs, distintos archivos ayudan en diferentes fases:

vpnportal.log para el VPN Portal;
access_server.log para la autenticación y la autorización;
clientless_access.log para las conexiones clientless y el establecimiento de la conexión con el destino;
oauth_sso_vpn.log en SFOS 22 para los inicios de sesión en VPN Portal mediante SSO; en SFOS 23, oauth_sso_svc.log para OIDC/Entra SSO en VPN Portal. Comprobar también el módulo Authentication de Log viewer para estos inicios de sesión en VPN Portal.

La hora de la prueba, el usuario, el bookmark y el destino deben documentarse juntos. Así es posible distinguir en los logs los problemas del portal, de identidad y del destino. Logs de servicio de Sophos Firewall explica la asignación general de logs y el acceso mediante Advanced Shell.

Funcionamiento y límites conocidos de RDP

Antes de un cambio en producción, registrar la asignación de la policy, la matriz Device Access, las excepciones ACL, el puerto del portal y el certificado. Si falla la prueba positiva o el usuario negativo ve un bookmark, retirar la nueva asignación o publicación, restaurar esos valores al estado anterior, iniciar sesión de nuevo y repetir la prueba negativa. Restaurar cuentas de destino o Host Keys solo si se modificaron realmente.

Las clientless policies deben revisarse periódicamente, al igual que otros permisos de Remote Access. Se eliminan los usuarios, bookmarks y cuentas de destino que ya no sean necesarios. Las contraseñas o Private Keys guardadas deben tener un responsable, una fecha de caducidad y un proceso de rotación. Automatic login y Share session deben formar parte de cada revisión de permisos.

Retirar la publicación no equivale a eliminar: Antes de retirar un elemento, aclarar si se trata de un bookmark individual o de un Bookmark Group y registrar el nombre exacto, la pertenencia actual a grupos y la publicación en todas las policies afectadas. Primero, retirar únicamente la publicación o asignación que ya no se desea; esto no elimina el objeto. Eliminar el objeto exacto solo cuando realmente no se utilice y se hayan aclarado sus dependencias. Si existen relaciones, detener el procedimiento y no eliminar en cascada grupos o policies en producción solo para forzar la eliminación.

Las referencias de Delete para SFOS 22.0 y 23.0 exigen, en ambos casos, Name con un máximo de 50 caracteres y enumeran los valores de estado XML 200, 500 y 504. Para 504, remiten a BookMarkDeleteRelationExists en el caso de los bookmarks y a BookMarkGroupDeleteRelationExists en el de los grupos: son identificadores de mensajes de la documentación sin resolver, no textos de mensajes confirmados en tiempo de ejecución ni un estado HTTP. Las referencias no proporcionan un payload de ejemplo de Delete ni garantizan un comportamiento en cascada; no deducir de ellas una sintaxis de eliminación. Después del cambio, volver a consultar efectivamente los bookmarks y grupos restantes y las publicaciones previstas, y repetir las pruebas positivas y negativas. Si se detecta un acceso inesperado, revertir los cambios propios de asignación al estado inicial registrado; por eso, evitar eliminaciones innecesarias de objetos cuando solo se pretende retirar una publicación.

Para consultar en tiempo real los usuarios remotos conectados, se abre Current activities > Remote users en la consola de administración. Las conexiones pueden filtrarse por fecha de conexión, nombre de usuario, dirección IP de origen y dirección IP asignada (leased IP). El administrador puede seleccionar Disconnect para desconectar al usuario remoto elegido. Primero debe comprobar el usuario y la conexión, ya que la acción interrumpe el acceso. No sustituye la retirada del usuario de la clientless policy ni el cierre correcto de sesión en el destino, y no garantiza que finalicen todas las sesiones posteriores en los sistemas de destino.

La documentación de la columna Mode distingue los siguientes casos:

SSL VPN (remote access): el usuario está conectado mediante SSL VPN de acceso remoto.
User portal (clientless access): según esta correspondencia, el usuario ha iniciado sesión en el User Portal y pertenece a una clientless SSL VPN policy.
User portal: según esta correspondencia, el usuario ha iniciado sesión en el User Portal, pero no pertenece a una clientless SSL VPN policy.

Estas etiquetas proceden de las instrucciones de Remote users para SFOS 22 y 23. En cambio, las instrucciones de Clientless indican el VPN portal como vía de acceso. La terminología es, por tanto, inconsistente; la lista no confirma las etiquetas Mode actuales de la compilación instalada ni un cambio de SFOS 22 a 23. Para la configuración se mantiene el procedimiento del VPN Portal descrito anteriormente. Comprobar por separado el inicio de sesión en el portal, la pertenencia a la policy y los bookmarks realmente visibles, sin deducir la autorización únicamente de una etiqueta Mode.

Antes de cambiar el firmware, use el runbook de Avanet para decisiones de firmware para identificar los cambios que afectan a la compilación instalada y a la versión de destino. Incluya Clientless Access, VPN portal, RDP y el método de autenticación utilizado en la revisión. Después de la actualización, repita todas las pruebas positivas y negativas.

RDP presenta actualmente dos limitaciones que no deben tratarse como errores de configuración:

El portapapeles no es compatible con los bookmarks RDP clientless desde SFOS 19. Por tanto, copiar y pegar entre el dispositivo local y la sesión RDP no es un workflow fiable.
El puntero del ratón puede aparecer como una cruz o una X en lugar de una flecha normal en la sesión RDP HTML5. Sophos no ofrece actualmente ninguna solución alternativa.

Si resultan imprescindibles el portapapeles, las funciones RDP nativas, un acceso más amplio a la red o cuentas personales en un servidor que exige NLA sin guardar credenciales, Clientless SSL VPN no es el atajo adecuado. En ese caso, el acceso debe migrarse de forma deliberada a Sophos Connect, RD Gateway, PAM, un jump host o ZTNA.