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.

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

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 Accept 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 y Services: VPN portal. 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. 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 comparten el mismo puerto y protocolo, sus zonas accesibles pueden influirse mutuamente; este efecto de compartir el puerto debe comprobarse por separado.

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

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.

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 que se pega en Public host key dentro del bookmark. 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.
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.

Otros tipos de bookmarks

SFOS 22 también documenta:

VNC para el acceso gráfico a sistemas Linux o UNIX configurados a tal efecto.
FTP, FTPS, SFTP y SMB para acceder a servidores de archivos desde el navegador. Esto no crea una unidad de red montada de forma normal. Para datos confidenciales, es preferible utilizar SFTP o FTPS en lugar de FTP sin cifrar.
Telnet como tipo de terminal. Como Telnet 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.

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 para los inicios de sesión en el VPN Portal mediante SSO.

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

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.

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.