Configurar el acceso remoto SSL VPN en Sophos Firewall

SSL VPN sigue siendo un método importante de acceso remoto en Sophos Firewall, especialmente cuando los usuarios trabajan desde hoteles, redes Wi-Fi de invitados, redes móviles o redes externas restrictivas. Sin embargo, lo crucial no es solo si el túnel se establece. Lo importante es si el firewall limita adecuadamente el acceso, si DNS funciona, si MFA se aplica y si las reglas del firewall permiten el tráfico desde la zona VPN de manera controlada.

El artículo describe la configuración del acceso remoto SSL VPN en Sophos Firewall desde el lado del firewall. Para la instalación del cliente, consulte Configurar Sophos SSL VPN con Sophos Connect en Windows, Configurar Sophos SSL VPN con Sophos Connect en macOS, Configurar Sophos SSL VPN en iPhone y iPad y Configurar Sophos SSL VPN en Android.

Para la decisión básica entre IPsec, SSL VPN, clientes móviles y ZTNA, consulte primero Sophos Connect o SSL VPN: ¿Qué solución de acceso remoto es adecuada?.

¿Qué artículo de SSL VPN es adecuado?

SSL VPN consta de configuración del firewall, portal, cliente, autenticación y análisis de errores posterior. Dependiendo de la tarea, se recomienda un punto de partida diferente:

Esta separación es importante: un problema de usuario en el portal VPN, un perfil .ovpn obsoleto, una regla de firewall faltante y un problema de DNS a menudo parecen iguales para el usuario. Para el análisis, estas capas deben separarse.

Imagen objetivo

Una configuración limpia de SSL VPN consta de varios componentes:

1. Los usuarios o grupos están autorizados en la política SSL VPN correcta.
2. Las configuraciones globales de SSL VPN definen la puerta de enlace, el puerto, el certificado, el rango de arrendamiento, DNS y criptografía.
3. El portal VPN es accesible solo en la medida necesaria y está protegido con MFA.
4. Las reglas del firewall permiten el tráfico desde la zona VPN solo a los destinos necesarios.
5. Se decide conscientemente entre túnel dividido o túnel completo.
6. Los clientes importan un perfil .ovpn actualizado.
7. Los registros, Packet Capture y los datos de soporte pueden evaluarse en caso de error.

Muchos problemas de SSL VPN surgen porque solo se documenta la descarga del cliente. En la práctica, se deben considerar conjuntamente el portal, la autenticación, la política SSL VPN, la regla del firewall, DNS y NAT.

⚠️ SSL VPN es un punto de entrada accesible públicamente. MFA y contraseñas fuertes son importantes, pero no reemplazan la limitación a través de Device access, grupos de usuarios restringidos, perfiles actualizados, registros y revisiones regulares.

Requisitos previos

Antes de la configuración, se deben aclarar estos puntos:

• Sophos Firewall con la versión actual de SFOS.
• Accesibilidad pública del firewall o un reenvío de puertos previo.
• FQDN o dirección IP pública para el acceso VPN.
• Certificado para el portal VPN y SSL VPN, idealmente coincidente con el FQDN.
• Usuarios o grupos para acceso remoto.
• Servidor de autenticación: local, Active Directory, RADIUS o Microsoft Entra ID.
• Concepto de MFA/OTP para el portal VPN y el acceso remoto.
• Redes de destino internas, servidores DNS y dominio de búsqueda.
• Decisión entre túnel dividido o túnel completo.
• Reglas de firewall para el tráfico desde la zona VPN.
• Proceso para actualización del cliente y redistribución del archivo .ovpn.

Si se va a utilizar Microsoft Entra ID SSO, la autenticación debe estar correctamente preparada antes de descargar la configuración VPN. El procedimiento se describe en Configurar Microsoft Entra ID SSO para Sophos Connect y el portal VPN.

1. Preparar objetos locales

Primero, las redes de destino deben existir como hosts u objetos de red:

Hosts and services > IP host

Objetos típicos:

No se deben liberar simplemente áreas de red internas completas si solo se necesitan servidores o subredes individuales. Cuanto más estrechamente definidos estén los objetos, más fácil será la regla del firewall más adelante.

2. Verificar configuraciones globales de SSL VPN

Las configuraciones globales se aplican a todas las políticas de acceso remoto SSL VPN:

Remote access VPN > SSL VPN > SSL VPN global settings

Protocolo y puerto

SSL VPN puede usar TCP o UDP según la configuración. UDP suele ser más eficiente, TCP puede funcionar mejor en redes restrictivas. La decisión debe probarse con las redes desde las que los usuarios realmente trabajan.

En cuanto al puerto, se deben evitar superposiciones:

• El puerto estándar de SSL VPN suele ser 8443.
• El portal VPN utiliza por defecto 443 en las versiones actuales de SFOS.
• Las reglas WAF y SSL VPN no deben superponerse en la misma IP WAN con el mismo puerto y protocolo.
• Si SSL VPN y el portal VPN utilizan el mismo puerto, las funciones de seguridad de inicio de sesión pueden no funcionar como se espera.

Si WAF, el portal VPN, el portal de usuario y SSL VPN se ejecutan en la misma IP WAN, se debe documentar conscientemente el puerto, el protocolo y el certificado. Para los fundamentos de WAF, consulte Configurar Sophos Firewall WAF y evitar errores comunes.

Certificado y nombre de host de anulación

En SSL server certificate se debe usar un certificado que coincida con el FQDN público. Un error de certificado en el portal VPN o en el perfil SSL VPN provocará casos de soporte innecesarios más adelante.

En Override hostname se especifica qué nombre de host o dirección IP usarán los clientes en el perfil .ovpn. Esto es especialmente importante en:

• múltiples direcciones IP WAN,
• enrutador previo,
• NAT o reenvío de puertos antes del firewall,
• IP WAN dinámica con DDNS,
• FQDN separados para WebAdmin, portal VPN y SSL VPN.

Si el campo queda vacío, pueden aparecer varias direcciones de interfaz en el perfil. Esto puede funcionar, pero en entornos productivos suele ser menos claro que un FQDN limpio.

Rango de arrendamiento

Sophos Firewall asigna direcciones a los clientes SSL VPN desde el rango de arrendamiento configurado. Este rango no debe colisionar con redes internas, rutas estáticas, VPNs de sitio a sitio o áreas de red domésticas típicas.

Se deben evitar especialmente subredes comunes como:

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 10.0.0.0/24
• 10.0.1.0/24

Si el rango de arrendamiento colisiona con la red doméstica de un usuario, a veces el túnel se conecta con éxito, pero los destinos internos permanecen inaccesibles. Esto parece un problema de regla de firewall, pero es un problema de enrutamiento en el endpoint.

Para las reglas de firewall, se deben usar los hosts del sistema ##ALL_SSLVPN_RW y en IPv6 ##ALL_SSLVPN_RW6, no hosts manualmente replicados con rangos de arrendamiento antiguos.

Direcciones IP estáticas de SSL VPN y tiempo de vida de la clave

Las direcciones IP estáticas de SSL VPN pueden ser útiles en casos individuales, por ejemplo, para accesos de administración, accesos especiales estrictamente registrados o aplicaciones heredadas con autorización basada en IP. Sin embargo, no son adecuadas como estándar para todos los usuarios. Cuantas más asignaciones estáticas existan, más difícil será la operación, el análisis de errores y las migraciones futuras.

En la lista de problemas conocidos se documenta un caso especial concreto: en SSL VPN con autenticación local y una IP de SSL VPN asignada estáticamente, la reautenticación después de que expire el tiempo de vida de la clave puede fallar. El firewall puede tratar la dirección de arrendamiento ya asignada como un conflicto. Los usuarios deben reconectarse manualmente, aunque el túnel funcionaba antes. Un valor típico de tiempo de vida de la clave es 18000 segundos.

Si un usuario debe volver a iniciar sesión repetidamente después de varias horas, no solo se debe verificar MFA, la versión del cliente y la regla del firewall. Además, estos puntos deben incluirse en el análisis:

• ¿Se utiliza autenticación local para SSL VPN?
• ¿El usuario tiene una dirección IP de SSL VPN estática?
• ¿El problema ocurre aproximadamente después de que expire el tiempo de vida de la clave?
• ¿Funciona el mismo usuario de manera más estable con asignación de IP dinámica?
• ¿Es realmente necesaria una IP estática o basta con una regla sobre el grupo de usuarios, el host del sistema SSL VPN y el registro?

Como medidas pragmáticas, Sophos menciona dos direcciones: planificar el tiempo de vida de la clave para que cubra la jornada laboral normal, o usar asignación de IP dinámica. En muchos entornos, la asignación dinámica es más limpia, ya que las reglas del firewall deberían controlarse de todos modos a través de la zona VPN, el grupo de usuarios, los objetos de destino y los hosts del sistema SSL VPN.

DNS y nombre de dominio

Para la resolución de nombres internos, se configuran servidores DNS y opcionalmente un nombre de dominio en las configuraciones globales de SSL VPN. En entornos de Active Directory, esto suele ser un servidor DNS interno o un controlador de dominio.

Además, se debe permitir DNS desde la zona VPN en Administration > Device access si el firewall se utiliza como resolver DNS en el diseño de VPN.

Si DNS no funciona en el túnel, se debe probar por separado:

• ¿El destino es accesible por dirección IP?
• ¿El servidor DNS interno está permitido por la regla del firewall?
• ¿El cliente recibe el dominio de búsqueda correcto?
• ¿El cliente realmente usa el perfil .ovpn actual?
• ¿La configuración local de DNS o DoH del endpoint interfiere?

3. Crear política SSL VPN

La política se crea en:

Remote access VPN > SSL VPN

Procedimiento:

1. Seleccionar Add.
2. Usar Configure manually.
3. Asignar un nombre, por ejemplo, SSLVPN-Remote-Users.
4. En Policy members, seleccionar los usuarios o grupos autorizados.
5. Establecer túnel dividido o túnel completo.
6. En túnel dividido, seleccionar los Permitted network resources.
7. Opcionalmente, configurar Disconnect idle clients.
8. Guardar y luego probar con un usuario de prueba.

Importante: si los usuarios o grupos se ingresan en una política SSL VPN más reciente que ya están en una política SSL VPN anterior, Sophos Firewall elimina esta asignación de la política anterior. Por lo tanto, se deben evitar superposiciones de políticas y definir claramente qué política se aplica a cada grupo de usuarios.

4. Decidir entre túnel dividido o túnel completo

Túnel dividido

En el túnel dividido, solo el tráfico hacia los recursos internos permitidos pasa por el túnel VPN. El tráfico de Internet del usuario continúa directamente a través de la red local del usuario.

El túnel dividido suele ser adecuado para:

• Acceso a pocas aplicaciones internas,
• Menor carga en el firewall,
• Mejor rendimiento del usuario,
• Pequeñas ubicaciones externas y usuarios móviles.

La seguridad depende entonces más del endpoint, el entorno de red local y los recursos internos permitidos.

Túnel completo

En el túnel completo, todo el tráfico del usuario remoto se enruta a través del firewall. En Sophos Firewall, esto corresponde a la opción Use as default gateway.

El túnel completo es más adecuado cuando:

• Se desea controlar el tráfico de Internet de manera centralizada,
• Se deben aplicar Web Protection, DNS Protection o registros para usuarios VPN,
• Los usuarios trabajan desde redes inseguras,
• El cumplimiento requiere evaluación centralizada.

En el túnel completo, la política SSL VPN por sí sola no es suficiente. Se necesitan reglas de firewall adicionales y NAT/SNAT para el tráfico de Internet desde la zona VPN. Además, se deben probar previamente el rendimiento, el ancho de banda, el filtrado web y los registros.

5. Crear reglas de firewall para la zona VPN

El establecimiento del túnel no significa que el tráfico esté permitido. Para acceder a los recursos internos, se necesita una regla de firewall adecuada:

Rules and policies > Firewall rules

Regla recomendada para túnel dividido:

Para el túnel completo, se necesita además una regla de VPN a WAN o Any, según el diseño. Las redes de origen deben seguir siendo los hosts del sistema SSL VPN. Luego se debe verificar si existe una regla SNAT adecuada.

Si una conexión está establecida pero no funciona el acceso, primero se debe verificar el Log Viewer. Para la metodología, consulte Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.

6. Asegurar el portal VPN y Device Access

Los usuarios suelen descargar Sophos Connect y el archivo .ovpn a través del portal VPN:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Verificar al menos:

• Puerto y certificado del portal VPN.
• Métodos de autenticación del portal VPN.
• MFA para el portal VPN y el acceso remoto.
• Device Access para VPN Portal solo en las zonas necesarias.
• Device Access para SSL VPN en la zona WAN solo si es necesario externamente.
• No dejar el portal de usuario abierto permanentemente en WAN si no es necesario.

Para el endurecimiento de los servicios locales del firewall, consulte Device Access y Local Service ACL en Sophos Firewall. Para los fundamentos de MFA, consulte Activar MFA para Sophos Firewall WebAdmin, portal VPN y acceso remoto.

El portal VPN solo tiene sentido para los usuarios si ellos o sus grupos están incluidos en una política de acceso remoto adecuada. Si falta la asignación de la política, el usuario no verá las descargas de configuración necesarias.

Si el portal VPN o SSL VPN deben permitirse en la zona WAN, esto debe documentarse conscientemente. En muchos entornos, no basta con abrir el servicio a nivel mundial y confiar en MFA. Donde sea posible, se deben considerar redes de origen fijas, limitación por país, Threat Feeds, revisión de registros o un diseño de acceso remoto previo.

7. Distribuir el perfil del cliente

Después de la configuración de la política y el portal, se distribuye el archivo .ovpn. Esto puede hacerse a través del portal VPN o controlado por el proceso de administración.

Importante:

• Después de cambios en la puerta de enlace, puerto, certificado, DNS, rango de arrendamiento, política o autenticación, el perfil debe recargarse.
• Una actualización de Sophos Connect no reemplaza un perfil .ovpn antiguo.
• Los nombres de perfil deben ser claros.
• Los perfiles antiguos deben eliminarse en caso de cambio de ubicación, cambio de puerta de enlace o cambio de usuario.
• Windows, macOS, iOS, Android y Linux utilizan rutas de cliente diferentes en algunos casos.

Para actualizaciones de clientes y mantenimiento de versiones, consulte Verificar y actualizar de manera segura la versión del cliente Sophos Connect.

Probar después de la configuración

Con un usuario de prueba, no solo se debe verificar si Sophos Connect muestra Connected.

Lista de pruebas:

• El usuario ve en el portal VPN la descarga de Sophos Connect y la configuración SSL VPN.
• El archivo .ovpn se puede importar.
• MFA se solicita como se espera.
• El cliente recibe una dirección del rango de arrendamiento SSL VPN.
• Aparece una ruta a las redes internas permitidas en el endpoint.
• Los nombres DNS internos se resuelven.
• El acceso a los servidores permitidos funciona.
• Las redes no permitidas permanecen bloqueadas.
• Log Viewer muestra la regla de firewall correcta.
• Packet Capture muestra tráfico a través de una interfaz tun, si es necesario.
• En túnel completo, también funciona el acceso a Internet y SNAT.

Si la prueba se realiza solo con un usuario administrador, es fácil pasar por alto errores de grupo y política. Es mejor un usuario piloto normal del grupo objetivo.

Prueba de aceptación por escenario

Antes de un despliegue amplio, se deben documentar al menos estos casos de prueba de manera clara:

Para entornos productivos, cada prueba debe incluir una hora, un usuario, una plataforma de cliente y un objetivo concreto. Declaraciones como “VPN funciona” o “VPN no funciona” son demasiado imprecisas para casos de soporte posteriores.

Recopilar registros y pruebas

En caso de problemas con SSL VPN, primero se debe aclarar si el error está en el inicio de sesión, en el establecimiento del túnel o en el acceso a los destinos internos. Esta separación ahorra tiempo, ya que de lo contrario se revisan autenticación, perfil del cliente, enrutamiento y reglas de firewall de manera desordenada.

Para una prueba reproducible, se deben anotar estos datos:

Luego, se debe realizar la verificación en este orden:

1. Verificar autenticación: En Log Viewer y, si es necesario, en los registros de autenticación, verificar si el usuario, MFA, grupo y servidor de autenticación son exitosos. En Microsoft Entra ID SSO, también es relevante oauth_sso_vpn.log.
2. Verificar estado del túnel: Verificar conexión SSL VPN, dirección de arrendamiento y estado de OpenVPN. En el lado del firewall, sslvpn.log y openvpn-status*.log son útiles.
3. Verificar regla de firewall: En Log Viewer, buscar tráfico desde la zona VPN y verificar qué regla realmente coincide. La regla debe tener activado Log firewall traffic.
4. Verificar flujo de paquetes: Si Log Viewer no es suficiente, filtrar en Packet Capture por fuente, destino y servicio. Es importante si los paquetes son solo Incoming o también Forwarded.
5. Verificar lado del destino: Si el tráfico sale del firewall pero no hay respuesta de vuelta, es más probable que se trate de una ruta de retorno, firewall del servidor, firewall local del host o un conflicto de red que de la política SSL VPN.

Para la asignación de los archivos de registro más importantes, consulte Resolución de problemas de Sophos Firewall: Servicios y registros. Para el análisis de reglas con Log Viewer, Policy Test y Packet Capture, consulte Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.

Resolución de problemas

El usuario no ve la configuración SSL VPN en el portal VPN

Por lo general, falta la asignación de la política. Se debe verificar si el usuario o su grupo están incluidos en la política SSL VPN bajo Policy members. Además, se deben verificar autenticación, MFA y accesibilidad del portal VPN.

Si el inicio de sesión y la asignación de la política parecen correctos, pero la descarga del archivo .ovpn falta o falla, también se debe verificar el límite de ID de usuario de Sophos Firewall. Esto es especialmente relevante si varios usuarios utilizan el portal, pero solo algunas descargas fallan inesperadamente.

El túnel se conecta, pero los sistemas internos no son accesibles

Primero, verificar si existe una ruta al destino interno en el endpoint. Luego, buscar tráfico desde la zona VPN en Log Viewer. Si no hay tráfico visible, el cliente no alcanza el firewall como se espera o el perfil está obsoleto.

Si el tráfico es visible pero la regla incorrecta coincide, se debe corregir el orden de las reglas o la definición de servicio/destino. Si no hay respuesta de vuelta, es probable que se trate de enrutamiento, firewall del destino, firewall local del servidor o un conflicto de red.

DNS no funciona

Se debe verificar si el acceso por dirección IP funciona. Si es así, el error probablemente esté en DNS. Luego, verificar servidores DNS en las configuraciones globales de SSL VPN, nombre de dominio, Device Access para DNS desde la zona VPN y comportamiento DNS del endpoint.

El acceso solo funciona para algunos usuarios

Entonces, es más probable que se trate de membresía de grupo, asignación de política, direcciones IP estáticas de SSL VPN, estado de MFA o perfiles obsoletos que de un error global del firewall. También se deben verificar asignaciones de políticas duplicadas.

El usuario debe reconectarse después de varias horas

Si SSL VPN funciona inicialmente, pero después de varias horas se requiere un nuevo inicio de sesión o una reconexión manual, primero se deben verificar patrones de tiempo, autenticación y modelo de arrendamiento. Esto es especialmente relevante con autenticación local y una IP de SSL VPN asignada estáticamente.

Procedimiento práctico:

1. Anotar la hora de la conexión y la desconexión.
2. Comparar el momento con el tiempo de vida de la clave configurado.
3. Verificar si el usuario tiene una dirección IP de SSL VPN estática.
4. Probar asignación de IP dinámica para un usuario piloto, si es posible operativamente.
5. Buscar en sslvpn.log, openvpn-status*.log y Log Viewer autenticación, dirección de arrendamiento y nuevo inicio de sesión.
6. Si se elige un tiempo de vida de clave más largo, documentar el cambio y no entenderlo como un reemplazo de MFA o control de sesión limpio.

Si las IPs estáticas solo se utilizan para que las reglas del firewall parezcan más simples, se debe revisar el diseño. Generalmente, los grupos, los objetos de destino claramente nombrados, los servicios restringidos y el registro son una mejor base que las direcciones IP de usuarios individuales.

El túnel completo no tiene acceso a Internet

Con Use as default gateway, se necesita una regla de firewall para el tráfico desde la zona VPN hacia Internet y una regla SNAT adecuada. Además, las políticas web, DNS y de seguridad deben planificarse de manera que no bloqueen inesperadamente a los usuarios VPN.

La conexión está establecida, pero las transferencias grandes se cuelgan

Si el inicio de sesión, DNS y los accesos pequeños funcionan, pero RDP, transferencias de archivos, aplicaciones web o descargas grandes se cuelgan, se deben verificar MTU y MSS. El patrón de error a menudo se ajusta a la fragmentación, PPPoE, conexiones tuneladas o una ruta asimétrica, no solo a SSL VPN en sí.

Para el análisis sistemático, consulte Verificar MTU y MSS de Sophos Firewall en problemas de VPN.

WAF o portal colisiona con SSL VPN

Si WAF, el portal VPN, el portal de usuario y SSL VPN se ejecutan en la misma IP WAN, el puerto y el protocolo deben separarse claramente. Especialmente crítico son las combinaciones compartidas de IP WAN, puerto y TCP. En caso de caídas poco claras, verificar Log Viewer y Packet Capture.

El perfil está obsoleto después de un cambio

Después de cambios en la política SSL VPN, puerta de enlace, DNS, certificado, puerto o autenticación, se debe volver a descargar e importar el archivo .ovpn. Muchos problemas aparentes del cliente son perfiles obsoletos.

Lista de verificación de operación

Antes del despliegue productivo

• FQDN y certificado para el portal VPN y SSL VPN verificados.
• El rango de arrendamiento SSL VPN no colisiona con redes internas o redes domésticas típicas.
• La política SSL VPN contiene los usuarios o grupos correctos.
• Se ha decidido conscientemente entre túnel dividido o túnel completo.
• Los recursos de red permitidos están definidos estrechamente en túnel dividido.
• Los servidores DNS y el nombre de dominio están configurados correctamente.
• Existe una regla de firewall de VPN a destinos internos y registra.
• En túnel completo, existen regla de Internet y SNAT.
• Device Access para SSL VPN y VPN Portal está configurado conscientemente.
• MFA está probado para acceso remoto.
• El usuario de prueba puede descargar, importar el perfil y alcanzar los destinos internos.

Para la operación continua

• Aplicar MFA para el portal VPN y el acceso remoto.
• Revisar regularmente los grupos VPN.
• Mantener las reglas de firewall para VPN ajustadas y registradas.
• Controlar el rango de arrendamiento antes de cambios de red.
• Usar direcciones IP estáticas de SSL VPN solo de manera dirigida y revisarlas regularmente.
• Documentar DNS y dominio de búsqueda.
• Renovar certificados de portal y SSL VPN antes de que expiren.
• Seguir las versiones de Sophos Connect.
• Planificar la redistribución del perfil después de cambios.
• Evaluar registros a largo plazo a través de Syslog o Sophos Central si la trazabilidad es importante.

Para archivos de registro y servicios, consulte Resolución de problemas de Sophos Firewall: Servicios y registros.

Revisar regularmente casos especiales

• Las direcciones IP estáticas de SSL VPN están justificadas y documentadas.
• El tiempo de vida de la clave se ajusta al modelo operativo y se ha probado con reconexión.
• El perfil .ovpn antiguo se redistribuye después de cambios.
• El portal VPN, el portal de usuario, WAF y SSL VPN no colisionan en la misma IP WAN con puerto y protocolo.
• Los usuarios con derechos especiales o acceso de administrador se revisan por separado.

FAQ