Configurar el acceso remoto SSL VPN en Sophos Firewall

El acceso remoto SSL VPN se configura en Sophos Firewall desde Remote access VPN > SSL VPN. Para obtener un acceso seguro, deben encajar seis componentes:

Asignar usuarios o grupos a una policy SSL VPN.
Configurar globalmente el protocolo, el certificado, el gateway, el rango de direcciones y DNS.
Elegir de forma consciente Split Tunnel o Use as default gateway.
Permitir el tráfico de la zona VPN mediante reglas de firewall restrictivas.
Proteger VPN Portal, la autenticación, MFA y Device Access.
Distribuir un perfil .ovpn actualizado o, en Windows, un archivo de provisioning .pro, y probar tanto los accesos permitidos como los denegados.

⚠️ SSL VPN es un punto de entrada accesible públicamente. MFA y las contraseñas seguras no sustituyen a los grupos de usuarios limitados, las Local Service ACLs, las reglas de firewall, los perfiles actualizados, los logs y las revisiones periódicas.

Este artículo aborda la configuración del firewall. La instalación se explica por separado para Windows, macOS, iPhone y iPad, Android y Linux. Para decidir previamente entre SSL VPN, IPsec y ZTNA, consulte Sophos Connect o SSL VPN.

Preparar los requisitos y los objetos

Antes de empezar, deben estar definidos el acceso público, los usuarios autorizados y los destinos internos:

una versión actual de SFOS y un cliente Sophos Connect actualizado;
un FQDN público o una dirección IP pública;
certificados para el túnel SSL VPN y VPN Portal;
usuarios o grupos y servidores de autenticación;
un método MFA para el portal y el túnel;
un rango de direcciones SSL VPN que no se solape con otras redes;
redes internas de destino, servidores DNS y dominio de búsqueda;
la decisión entre Split Tunnel y Full Tunnel;
un proceso para distribuir perfiles y actualizar clientes.

Los destinos internos se crean primero como hosts u objetos de red:

Hosts and services > IP host

El siguiente ejemplo utiliza:

LAN_Server: 10.10.10.0/24 para servidores internos;
LAN_Client: 10.10.20.0/24, si los usuarios remotos necesitan realmente esta red de clientes;
DNS_Internal: 10.10.10.10 para el DNS interno o el controlador de dominio;
SSLVPN_Users: grupo de usuarios para Policy members.

No se deben permitir redes internas completas si basta con servidores o subredes concretos. Los servidores DNS también necesitan un objeto claramente definido para que posteriormente se puedan entender la ruta y la regla de firewall.

Configurar los ajustes globales de SSL VPN

Los ajustes globales se aplican a todas las policies de acceso remoto SSL VPN y forman parte de la configuración .ovpn:

Remote access VPN > SSL VPN > SSL VPN global settings

Estos valores también se utilizan para las conexiones SSL Site-to-Site entre dos Sophos Firewall. Al cambiar el puerto, el protocolo, el certificado u Override hostname, deben comprobarse tanto los perfiles de Remote Access como los túneles SSL Site-to-Site existentes y volver a distribuir sus configuraciones.

Antes de cambiar los valores globales del perfil, documente Protocol, Port, Override hostname, SSL server certificate, los valores de asignación y DNS y la configuración de los pares SSL Site-to-Site afectados. Incluya también cualquier NAT o redirección de puertos aguas arriba en el plan de respaldo. Si falla la prueba de aceptación, restaure estos valores y la configuración Site-to-Site anterior y repita con el perfil antiguo las pruebas del portal, del túnel y de los accesos permitidos y denegados.

Protocolo, certificados, gateway y puerto

SSL VPN admite TCP y UDP. UDP suele ser la opción inicial más eficiente; TCP puede servir como alternativa probada cuando las redes externas bloquean UDP. La elección debe comprobarse en redes reales de hoteles, telefonía móvil o invitados.

El puerto predeterminado de SSL VPN es 8443; VPN Portal utiliza de forma predeterminada 443. Para cada servicio accesible públicamente, una combinación única de IP WAN, puerto y protocolo es la opción más fácil de entender.

Sophos utiliza dos certificados distintos:

El SSL server certificate seleccionado en los ajustes globales de SSL VPN es utilizado por el servidor SSL VPN.
El certificado HTTPS de VPN Portal se selecciona en Administration > Admin and user settings.

Ambos certificados deben coincidir con el FQDN público utilizado en cada caso. Con certificados de una CA externa, también debe estar disponible la cadena de certificados necesaria.

Override hostname determina el FQDN o la dirección IP pública del perfil del cliente. Es especialmente importante cuando hay NAT previo, varias interfaces WAN o DDNS. Si el campo queda vacío, el perfil puede contener varias direcciones de interfaces. Sophos Connect prioriza los gateways DDNS y prueba otras entradas en orden inverso; por eso, un FQDN único resulta más sencillo de probar y mantener.

VPN Portal y SSL VPN pueden compartir técnicamente el mismo puerto y protocolo. Sin embargo, en ese caso los ajustes de Login Security no funcionan como está previsto y VPN Portal queda accesible desde las zonas habilitadas para SSL VPN. WAF debe diferenciarse de VPN Portal por la IP WAN o el puerto, y de SSL VPN por la IP WAN, el puerto o el protocolo. Sophos Firewall WAF explica otras dependencias de WAF.

Rango de direcciones y DNS

El rango de direcciones IPv4 debe ser privado y no puede solaparse con redes internas, VPNs site-to-site, rutas estáticas, otros pools de acceso remoto ni redes domésticas habituales. Son especialmente frecuentes 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 y 10.0.1.0/24.

La documentación de SFOS 22 se contradice sobre el prefijo permitido para los pools IPv4 más pequeños. La ayuda del campo indica /24 como límite y afirma que no pueden seleccionarse subredes /25 o más pequeñas, mientras que la FAQ actual también describe subredes más pequeñas distribuidas internamente entre varias instancias OpenVPN. Por tanto, prevalece la versión de SFOS utilizada: compruebe qué prefijo ofrece su interfaz y verifique después el número real de direcciones disponibles.

Según la FAQ de Sophos, el número de instancias SSL VPN simultáneas depende de las CPU del modelo de firewall. Cada instancia crea una interfaz tun0 y necesita su propia subred para routing y distribución interna. SFOS divide el pool configurado; estas direcciones se consumen antes de asignar leases a los clientes. Como ilustración, la FAQ cita 192.168.0.0/27, ocho instancias simultáneas y una sola IP restante asignable. No es una capacidad universal ni una red de ejemplo recomendada: compruebe los leases reales en el build y modelo de destino; el conflicto entre la ayuda del campo y la FAQ descrito arriba sigue vigente.

SFOS 23: El rango IPv4 seleccionable depende del modelo de firewall; los modelos más grandes admiten subredes con más direcciones IP. La ayuda de SFOS 23 indica /24 como la subred más pequeña seleccionable. Es un límite de selección dependiente del modelo, no una garantía de un número concreto de leases para clientes. La división interna según las CPU explica el consumo de direcciones, pero no los rangos de selección admitidos. Esto no resuelve el conflicto de SFOS 22 ni convierte la ilustración /27 en una recomendación de configuración.

Antes de cambiar el rango, documente el build de SFOS, el modelo, el rango anterior y las asignaciones estáticas, y conserve los valores anteriores para la reversión. Seleccione en la interfaz solo un rango admitido por el modelo de destino, mantenga las direcciones estáticas de los usuarios dentro del rango estático resultante y compruebe los leases realmente disponibles. Después, vuelva a conectar a un usuario piloto y pruebe el lease, DNS y los destinos permitidos y bloqueados. Si falla la aceptación, restaure los valores y asignaciones anteriores y repita las pruebas. Si el build, la interfaz, la ayuda o la FAQ se contradicen, detenga el despliegue de capacidad que dependa de ello hasta aclararlo con soporte; no fuerce una máscara.

API XML de SFOS 23 – estado 551: La fila de estado sin procesar de Configure SSLVPN Tunnel Access hace referencia al identificador de ejecución no resuelto Message.SSLVPNInvalidLeaseIPv4Mask. No permite deducir un texto de mensaje confirmado, una causa de rechazo establecida ni un nuevo rango de máscaras admitido. Si la API devuelve 551, conserve la respuesta completa y los ajustes anteriores. Antes de cualquier cambio, compruebe StartIP, SubnetMask y la selección de pool admitida por el build instalado y el modelo, mediante la ayuda aprobada para ese entorno o con Sophos Support; no fuerce una máscara.

Tras una corrección admitida, verifique la respuesta de la API, los ajustes realmente guardados en el firewall de destino y el lease de un usuario piloto que haya vuelto a conectarse. Conserve los valores y asignaciones anteriores para la reversión descrita arriba. Si el diagnóstico o el texto del mensaje siguen siendo relevantes para la aprobación y no se han aclarado, mantenga el despliegue pendiente.

Un pool pequeño no es un control de acceso; para ello se utilizan la policy y las reglas de firewall. En las reglas se utilizan los hosts del sistema ##ALL_SSLVPN_RW y, para IPv6, ##ALL_SSLVPN_RW6.

Los servidores DNS internos se introducen en IPv4 DNS. Domain name contiene el dominio de búsqueda que se añade a los nombres de host cortos. Con Split Tunnel, el servidor DNS o su red también debe figurar en Permitted network resources y ser accesible mediante una regla de firewall desde la zona VPN. Con Full Tunnel desaparece la ruta específica de Split Tunnel, pero no la necesidad de la regla de firewall.

Si el propio firewall actúa como resolver DNS, introduzca su dirección adecuada en IPv4 DNS. Además, permita DNS para la zona VPN en Administration > Device access. Una prueba por dirección IP y otra independiente por nombre de host permiten distinguir un problema de routing de uno de DNS.

Direcciones IP estáticas, sesiones simultáneas y tiempos

Las direcciones IP SSL VPN estáticas son posibles para casos especiales justificados, como una autorización heredada basada en IP, y deben encontrarse dentro del pool configurado. Sin embargo, un usuario con una dirección IP SSL VPN estática no puede establecer varias sesiones de acceso remoto simultáneas.

Independientemente de ello, Simultaneous logins, en Authentication > Services o directamente en el usuario local, limita los inicios de sesión simultáneos. El valor global solo se aplica a los usuarios creados posteriormente.

Key lifetime controla el momento del rekey y no es un timeout de inactividad ni una duración máxima de sesión. Las conexiones inactivas se gestionan mediante los ajustes globales de inactividad y, opcionalmente, mediante Disconnect idle clients en la policy. Ante desconexiones inesperadas, deben comprobarse por separado estos valores, la asignación de IP estática, los inicios de sesión simultáneos y los logs.

Disconnect dead peer after es un valor global en segundos y cierra los clientes que no responden. Los valores predeterminados son 180 segundos para TCP y 100 segundos para UDP; SFOS admite valores de 60 a 110 para UDP. Disconnect idle peer after, en cambio, se especifica en minutos y cierra sesiones realmente inactivas. Antes de aumentar un valor, utilizar sslvpn.log, el log del cliente y las pruebas de pérdida de paquetes para determinar qué temporizador se activa realmente.

El Override global timeout de una policy solo puede acortar el valor global de inactividad. Si el valor de la policy es mayor, sigue aplicándose el valor global. Una página antigua de troubleshooting de Sophos recomienda un valor mayor en la policy para usuarios individuales, pero la ayuda de campos actual de SFOS 22 lo contradice expresamente. Para permitir sesiones más largas, no realizar un aumento ineficaz en la policy; ajustar el valor global después de evaluar el impacto y volver a probar con el mismo grupo de usuarios.

Crear la policy SSL VPN

La policy se crea manualmente o mediante el asistente:

Remote access VPN > SSL VPN

Sophos recomienda el asistente especialmente para la primera policy SSL VPN. Solo muestra los ajustes globales para revisarlos y no permite modificarlos. Aplica los servidores y métodos de autenticación seleccionados, configura Device Access para VPN Portal y SSL VPN y crea la policy y la regla de firewall. La primera vez crea el grupo de reglas Automatic VPN rules al principio de la tabla de reglas y activa la nueva regla. Las reglas posteriores del asistente se colocan al final de este grupo. Después de cada ejecución, compruebe su posición y la Rule ID que coincide realmente. En entornos existentes, Configure manually suele ser más transparente:

Seleccionar Add > Configure manually.
Introducir, por ejemplo, SSLVPN-Remote-Users en Name.
Seleccionar el grupo SSLVPN_Users en Policy members.
Definir Split Tunnel o Use as default gateway.
Con Split Tunnel, seleccionar LAN_Server y DNS_Internal como Permitted network resources. Utilizar aquí objetos de red o de host, no interfaces: seleccionar una interfaz no garantiza el acceso a su subred.
Configurar opcionalmente Disconnect idle clients y Override global timeout.
Guardar y comprobar la configuración con un miembro normal del grupo de destino.

Los usuarios y grupos invitados no se pueden utilizar como Policy members. Si un usuario o grupo ya pertenece a una policy SSL VPN anterior, SFOS elimina esa asignación de la policy previa. Por tanto, los solapamientos deben comprobarse antes de guardar.

Un Override global timeout específico de la policy solo se aplica si es inferior al valor global de inactividad. Un valor superior no anula el límite global.

Split Tunnel o Full Tunnel

Con Split Tunnel, solo se enrutan por la VPN las redes IPv4 e IPv6 y los destinos FQDN compatibles seleccionados en Permitted network resources. Los destinos FQDN solo se admiten para IPv4. El resto del tráfico de Internet permanece local. Esto reduce la carga del firewall y la latencia, pero exige planificar con precisión los recursos y DNS.

Cuando cambia la dirección IP de un destino FQDN permitido, los túneles existentes no se actualizan automáticamente. Los usuarios afectados deben desconectarse y volver a conectarse.

Con Full Tunnel se activa Use as default gateway. Todo el tráfico del usuario pasa entonces por el firewall. Permitted network resources no se aplica como límite de acceso. Los destinos y servicios internos deben restringirse mediante reglas de firewall; el acceso IPv4 a Internet también requiere una regla SNAT/MASQ adecuada.

Full Tunnel permite centralizar el control web, DNS y de logs, pero aumenta el consumo de ancho de banda, la carga del firewall y el trabajo relacionado con la privacidad y el soporte. Por eso debe probarse con aplicaciones reales y usuarios simultáneos.

Reglas de firewall, Device Access y autenticación

Reglas de firewall y DNS

El establecimiento del túnel aún no permite acceder a los recursos internos. Para ello se crea una regla:

Rules and policies > Firewall rules

Ejemplo para Split Tunnel:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: únicamente los servicios de aplicación necesarios y DNS
Log firewall traffic: activado

La regla debe situarse por encima de reglas VPN más amplias. Una prueba negativa hacia un destino no permitido muestra si una regla general situada más abajo concede acceso de forma involuntaria.

Para IPv4 Full Tunnel se añade una regla de VPN a WAN y una regla SNAT/MASQ adecuada. IPv6 requiere un routing IPv6 planificado y reglas de firewall IPv6 propias. Si no hay acceso, resultan útiles Log Viewer, Rule ID y la guía para probar reglas de firewall.

VPN Portal, Device Access y MFA

El portal, los servicios locales y la autenticación se comprueban en ubicaciones distintas:

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

Como mínimo, se necesita:

SSL VPN en las zonas desde las que se debe poder establecer el túnel;
VPN Portal únicamente en las zonas realmente necesarias;
DNS en la zona VPN solo cuando el firewall actúa como resolver;
los VPN portal authentication methods adecuados;
los SSL VPN authentication methods adecuados;
MFA para el portal y el túnel.

Cuando un método de autenticación contiene varios servidores, SFOS los consulta en el orden mostrado. Cada método admite un máximo de 20 servidores. Si existen nombres de usuario idénticos o un mecanismo de respaldo, compruebe qué servidor procesa realmente la solicitud.

Las reglas de firewall normales no controlan estos servicios locales. Las redes de origen más limitadas, las direcciones IP concretas o los países se configuran mediante Local Service ACL Exception Rules. El procedimiento completo de seguridad se explica en Device Access y Local Service ACL.

El web proxy del firewall es un caso especial: las solicitudes HTTP y HTTPS que lo atraviesan se consideran internas para los servicios locales. Por tanto, los usuarios con acceso al proxy pueden acceder a VPN Portal aunque no esté habilitado para su zona de origen. Si se utiliza el proxy, compruebe esta accesibilidad por separado en lugar de confiar únicamente en la matriz de zonas de Device Access.

Los Third-party Threat Feeds también pueden bloquear el acceso dirigido al propio sistema y a los servicios VPN. Esto permite bloquear adicionalmente fuentes no deseadas conocidas; Threat Feeds en Sophos Firewall explica su configuración y sus límites.

VPN portal authentication methods controla el inicio de sesión en el portal y la descarga del perfil; SSL VPN authentication methods, el inicio de sesión en el túnel. WebAdmin es una interfaz de administración independiente y no necesita habilitarse desde la zona WAN para utilizar SSL VPN.

SSO según la versión de SFOS: En SFOS 22, Microsoft Entra ID se configura con Server type: Microsoft Entra ID SSO. En SFOS 23, abra Authentication > Servers > Add, seleccione Server type: OpenID Connect y después IdP vendor: Microsoft Entra ID o IdP vendor: Google Workspace. La configuración de la aplicación, el servidor, las Redirect URIs y los grupos se explica en Microsoft Entra ID SSO para Sophos Connect y Google Workspace OIDC en Sophos Firewall, respectivamente. Estas variantes no confirman la disponibilidad GA de ningún build.

Antes de descargar el perfil, seleccione el mismo servidor IdP configurado en Authentication > Services para VPN portal authentication methods y SSL VPN authentication methods, y pulse Apply para cada servicio; en SFOS 22 debe ser el mismo servidor Entra. Compare la Redirect URI completa en el proveedor elegido, incluidos FQDN, puerto y ruta, y compruebe los endpoints de inicio de sesión necesarios. Un SSO correcto no sustituye la pertenencia a grupos, Policy members ni reglas de firewall restringidas. Antes del cambio, conserve las asignaciones de servicios, el orden de servidores y los perfiles que funcionan. Tras cambios en SSO, vuelva a descargar e importar la configuración actual y pruebe con un usuario piloto normal el portal, el túnel, MFA en el IdP, DNS y los destinos permitidos y bloqueados. Si falla, restaure las asignaciones, el orden y los perfiles correspondientes documentados y repita las pruebas; no retire el acceso anterior antes de superar la aceptación.

Para el OTP nativo de SFOS, seleccione los usuarios o grupos de destino en Authentication > Multi-factor authentication y active VPN portal y SSL VPN remote access en Require MFA for. Con Generate OTP token with next sign-in, el usuario debe escanear primero el código QR en VPN Portal; solo entonces puede comenzar la prueba del túnel.

VPN Portal no admite autenticación RADIUS con Challenge MFA. Sophos Connect tampoco admite un challenge OTP, sino que envía conjuntamente la contraseña y el OTP; se admiten los métodos Call y Push. El método seleccionado debe probarse con un usuario piloto normal. Consulte MFA para Sophos Firewall para obtener más información.

Distribuir y actualizar el perfil del cliente

Si cambian valores globales relevantes para el perfil, como el protocolo, el puerto, la interfaz, el certificado del servidor o Override hostname, vuelva a descargar el archivo .ovpn actual desde VPN Portal, distribúyalo de forma protegida y, si la implementación es manual, impórtelo de nuevo en el cliente. Update policy no es aquí el primer paso ni sustituye la nueva importación manual. El uso documentado corresponde a una conexión aprovisionada mediante .pro: después de cambiar el puerto de SSL VPN o el protocolo, ejecute Update policy en esa conexión; esta vía de aprovisionamiento obtiene automáticamente los demás cambios de configuración. Si se modifican, por ejemplo, el puerto, el gateway, el certificado del servidor o el protocolo, puede ser necesario volver a iniciar sesión. Una actualización del software Sophos Connect no sustituye un perfil obsoleto. Conserve de forma segura el perfil que se sabe que funciona y los valores globales correspondientes del firewall para la reversión; antes de la distribución general, compruebe la nueva importación con un usuario piloto normal, verificando el gateway/puerto, la autenticación/MFA, las rutas, el DNS y los destinos permitidos y bloqueados. Si las pruebas de aceptación fallan, restaure conjuntamente los valores anteriores y el perfil que se sabe que funciona, y repita las mismas comprobaciones.

Después de modificar Override hostname o el puerto, debe comprobarse en el cliente que el perfil recién importado utiliza realmente el nuevo nombre del gateway y el nuevo puerto.

En cambio, tras modificar Policy members, Permitted network resources o la dirección IP de un destino FQDN, normalmente basta con desconectarse y volver a conectarse. Las redes permitidas no se almacenan de forma estática en el archivo .ovpn; SFOS añade los recursos específicos del usuario al establecer el túnel. Por tanto, estos cambios no requieren descargar de nuevo el archivo .ovpn.

.pro descarga IPsec (.scx) y las configuraciones SSL VPN autorizadas para el usuario (.ovpn) desde el VPN Portal, además de cambios posteriores; no es un perfil de túnel. Se admiten clientes Windows compatibles y Sophos Connect para macOS desde 2.1, no el cliente macOS 2.0 ni anteriores. El provisioning IPsec requiere Sophos Connect 2.1 o posterior. En el cliente macOS 2.0 siguen siendo necesarios la importación directa y la actualización manual controlada.

Si cambia el gateway de provisioning o vpn_portal_port, también se debe adaptar y redistribuir el archivo .pro. El campo anterior user_portal_port solo se acepta por compatibilidad. Durante el primer provisioning con OTP u otro método MFA, el inicio de sesión puede aparecer dos veces: primero para descargar los perfiles y después para establecer el túnel.

Si el archivo .pro solo proporciona una conexión IPsec o ninguna configuración SSL VPN, deben comprobarse primero Policy members, la pertenencia al grupo, la disponibilidad de VPN Portal y la autenticación.

Para el aprovisionamiento SSO con .pro en Windows con Sophos Connect 2.4 o posterior, SFOS 22 describe Entra ID; SFOS 23 admite los proveedores de identidad OIDC compatibles con este flujo, no cualquier proveedor de identidad. En Authentication > Services, VPN Portal, IPsec VPN y SSL VPN deben utilizar el mismo servidor IdP configurado. gateway contiene únicamente el FQDN o la dirección IP del firewall del apartado Redirect URI de ese servidor, no la URI de callback completa; el puerto del portal se configura por separado en vpn_portal_port. Para SSO, macOS con Sophos Connect 2.1 o posterior sigue limitado aquí a Entra ID, sin ampliarse a OIDC general; sigue siendo necesaria la confirmación de compatibilidad antes del despliegue indicada más abajo. El siguiente artículo de aprovisionamiento explica los requisitos según el proveedor y la versión.

Provisioning de Sophos Connect con .pro y GPO describe la estructura JSON completa, los campos MFA, la selección de gateways y la distribución por GPO.

Para Google Workspace SSO, esta guía se limita a Windows con Sophos Connect 2.4 o posterior; las indicaciones de Entra para macOS no son aplicables a Google. En Entra, las páginas de resumen mencionan macOS desde 2.1, no 2.0, mientras que las de requisitos solo mencionan Windows desde 2.4. Esta contradicción tampoco está resuelta en el artículo detallado enlazado: detenga el despliegue en macOS hasta confirmar y probar por separado la compatibilidad con el build de destino, la plataforma y versión del cliente y el tipo de VPN necesario. En cada ruta aprobada, compruebe los ajustes SFOS compatibles, la configuración actual del cliente, los métodos de autenticación y la Redirect URI; pruebe MFA en el IdP. No se garantiza un flujo de navegador idéntico ni que el despliegue GPO de Windows se aplique a macOS.

Los nombres de perfil deben ser inequívocos, las entradas de conexión antiguas deben eliminarse después de cambiar de gateway o de usuario, y la distribución debe comprobarse con un usuario normal del grupo de destino. Consulte Actualizar Sophos Connect de forma segura para obtener información sobre las versiones del cliente.

SSL VPN con Sophos Connect: Windows 10/11; cliente macOS 2.0 en macOS 13+, y cliente 2.1 o posterior en macOS 14+. Linux, iOS y Android utilizan un cliente OpenVPN compatible.

En Current activities > Remote users se pueden filtrar los usuarios remotos conectados por Connection date, Username, Source IP address y Leased IP address. La columna Mode distingue tres estados:

SSL VPN (remote access): túnel de acceso remoto establecido
User portal (clientless access): inicio de sesión en el portal de un miembro de una policy SSL VPN clientless
User portal: inicio de sesión en el portal sin esa pertenencia

Por tanto, una entrada del portal no demuestra que exista un túnel SSL VPN. Disconnect finaliza la sesión seleccionada. Antes de una prueba de soporte o aceptación se documentan el usuario, las direcciones, el modo y la hora.

Probar la configuración y aislar errores

Prueba de aceptación

Una prueba completa utiliza un usuario piloto normal y un destino interno concreto:

El usuario ve exactamente la configuración SSL VPN esperada en VPN Portal.
Probar MFA con un factor correcto y otro incorrecto.
Importar .ovpn o .pro y comprobar la dirección asignada.
Con Split Tunnel, comprobar la ruta hacia LAN_Server y DNS_Internal.
Probar primero el destino interno por dirección IP y después por nombre de host.
Acceder al servicio permitido y comprobar Firewall Rule ID en Log Viewer.
Generar un acceso no permitido y confirmar el drop.
Con Full Tunnel, comprobar además el acceso público a Internet, DNS, Web Policy e IPv4-SNAT.
Tras modificar una policy o un FQDN, desconectarse, volver a conectarse y repetir la misma prueba.

Cada prueba debe registrar la hora, el usuario y el grupo, la plataforma y versión del cliente, la red de origen, el destino y el servicio. Si solo se prueba con un administrador, los errores de grupo, MFA y policy pueden pasar inadvertidos fácilmente.

Logs por fase del error

Primero debe determinarse si el error se produce al acceder al portal, durante la autenticación, al establecer el túnel o solo al acceder al destino:

VPN Portal: vpnportal.log
Autenticación normal: access_server.log
Microsoft Entra SSO en SFOS 22: oauth_sso_vpn.log; para SFOS 23, utilice las indicaciones de logs específicas de la versión en el artículo detallado de Entra o Google correspondiente.
Certificados SSL VPN específicos del usuario: peruser_cert_sslvpn.log
Servicio SSL VPN: sslvpn.log
Conexiones activas: openvpn-status*.log
Tráfico hacia el destino: log del firewall, Rule ID y, si es necesario, Packet Capture

En Packet Capture, Incoming solo demuestra que el firewall ha recibido el paquete. Si aparece Forwarded pero no hay respuesta, deben comprobarse la ruta de retorno, NAT, el sistema de destino y su firewall local.

En el tráfico TUN, los logs de SFOS pueden presentar la dirección de la interfaz TUN como origen y la dirección asignada al cliente como destino. Esto no significa que las direcciones estén invertidas. Para interpretar la entrada, deben relacionarse el usuario, la asignación, el sentido del tráfico, la Rule ID y la hora de la prueba.

La asignación de otros procesos y archivos se explica en Servicios y logs de Sophos Firewall.

Ningún usuario puede establecer un túnel: servicio y límites de inundación

Si el problema afecta a todos los usuarios, realice primero comprobaciones de solo lectura antes de cambiar políticas, límites de inundación o servicios. Anote la hora de la prueba, el protocolo y puerto configurados para SSL VPN, los ajustes de DoS actuales y si existe al menos una política SSL VPN.

Inicie sesión en la CLI, seleccione 5. Device management y después 3. Advanced shell, y compruebe el estado del servicio con el comando documentado por Sophos:
```
service -S | grep sslvpn
```
El servicio debe mostrar Running. UNREGISTERED significa que no hay ninguna política SSL VPN registrada; compruebe que exista al menos una. Si existe una política, pero el servicio sigue sin mostrar Running, correlacione sslvpn.log con la hora de la prueba e investigue la discrepancia en vez de reiniciar servicios sin un procedimiento documentado.
En Intrusion prevention > DoS & spoof protection > DoS settings, revise las opciones y los límites de inundación habilitados para UDP, TCP e ICMP/ICMPv6. Para revisar el tráfico del túnel, use el protocolo configurado para SSL VPN. SFOS descarta el tráfico SSL VPN y las solicitudes ping cuando se supera el límite correspondiente; un ping fallido por sí solo no demuestra que se haya superado. Correlacione el intento de conexión con evidencias del descarte antes de crear una excepción.
Solo si se confirma que coincide con un límite de inundación, registre la configuración existente y cree en DoS bypass rules la regla inbound temporal más restrictiva posible. El ejemplo de Sophos usa la dirección IP/máscara de origen relevante (o * solo si es inevitable), la dirección del recurso de red permitido como destino, el protocolo real TCP o UDP, puerto de origen Any y el puerto de destino SSL VPN configurado (8443 de forma predeterminada). Restrinja aún más el origen y el destino cuando la prueba lo permita; no desactive globalmente la protección contra inundaciones.
Repita las mismas pruebas cronometradas de conexión y acceso al recurso permitido. Si la regla de bypass no explica el descarte, elimínela inmediatamente. Tras el diagnóstico, elimine la regla temporal o apruebe y documente formalmente la excepción restringida. Restaure cualquier límite de inundación modificado por separado a su valor anotado y repita las pruebas de acceso permitido y bloqueado.

La solicitud llega al servidor, pero falta la respuesta

Si está demostrado que la solicitud del cliente SSL VPN llega al recurso interno permitido, pero la respuesta no llega al cliente, se comprueba el retorno en dos tramos: primero desde el recurso hasta el firewall y después desde el firewall hasta la dirección SSL VPN asignada. Un estado verde del túnel no permite aislar este error.

En el recurso interno o en su router, comprobar que la ruta de retorno al rango de asignación SSL VPN pasa por Sophos Firewall. Una ruta de retorno específica es más transparente que SNAT. Utilizar SNAT solo de forma limitada cuando no sea posible enrutar el retorno y el cambio resultante de la dirección de origen sea aceptable.
Confirmar con Packet Capture que la respuesta llega al firewall. La dirección de origen, la dirección de destino asignada, el servicio y la hora de la prueba deben corresponder al acceso original.
En Routing > SD-WAN routes, revisar la Route Precedence actual y las rutas SD-WAN amplias. SSL VPN pertenece a la categoría static. Si sdwan_policyroute aparece antes, una ruta con el recurso interno o Any como origen y Any como destino y servicio puede desviar la respuesta fuera del túnel.
Limitar preferentemente la ruta SD-WAN afectada para que el rango de asignación SSL VPN deje de coincidir como destino. Sophos menciona como alternativa una excepción de servicio para el puerto y el protocolo de SSL VPN; esta variante debe corresponder al diseño real de reglas y tráfico.
Cambiar la Route Precedence global solo después de evaluar el impacto. Afecta a más tráfico que esta conexión. Preparar el orden inicial, el acceso de gestión y el rollback tal como se explica en Route Precedence en Sophos Firewall.
Repetir el acceso y comprobar en la captura la entrada de la respuesta desde el recurso y su reenvío hacia la dirección asignada. A continuación, volver a conectar y repetir la prueba con la misma aplicación.

⚠️ Una regla amplia con Any, una regla SNAT general o un cambio global de Route Precedence pueden desplazar el problema visible e interrumpir otras rutas de VPN, WAN o gestión. Detenerse si no se ha demostrado la ruta de retorno al firewall o la ruta SD-WAN que realmente coincide.

La red doméstica y la red interna de destino se solapan

Si, por ejemplo, el cliente externo utiliza 192.168.1.0/24 y el recurso interno permitido también se encuentra en 192.168.1.0/24, el sistema operativo suele considerar que el destino es local. En ese caso, el paquete ni siquiera entra en el túnel SSL VPN. La solución permanente y limpia es cambiar la numeración de una de las dos redes.

Si esto no es posible de inmediato, Sophos documenta una alternativa DNAT estrictamente limitada. Se elige una dirección virtual de destino libre que no se solape con ninguna red local, interna, VPN, estática o SD-WAN. Con Split Tunnel, esta dirección debe llegar al cliente como Permitted network resource y después se requiere una reconexión. La regla DNAT utiliza el rango de asignación SSL VPN como Original source, Original como Translated source, la dirección virtual como Original destination y el host interno real como Translated destination. Los servicios y la regla de firewall asociada de VPN a la zona de destino se limitan al acceso realmente necesario.

El usuario accede después a la dirección virtual o a un nombre DNS específico que resuelva hacia ella. Log Viewer debe mostrar la Firewall Rule ID y la NAT Rule ID esperadas; un Packet Capture confirma la traducción y la ruta de retorno. No se debe crear un rango de sustitución completo si solo hace falta un host. Hay que detenerse si no puede demostrarse que la dirección virtual está libre o si sería necesaria una regla NAT amplia.

Patrones de error habituales

El .ovpn no aparece o está vacío en VPN Portal: Solucionar una descarga OVPN ausente o vacía distingue los errores de policy, User ID, certificado, almacenamiento, firmware y HA. Las cuentas de invitado no están permitidas. Sophos Connect solo admite nombres de usuario ASCII; el nombre de usuario y el dominio pueden tener juntos un máximo de 51 caracteres.
El inicio de sesión falla: comparar access_server.log y vpnportal.log con la hora de la prueba; para Entra en SFOS 22, utilizar también oauth_sso_vpn.log, y en SFOS 23 las indicaciones de logs OIDC específicas de la versión en el artículo detallado correspondiente. Comprobar el mismo servidor IdP para el portal y SSL VPN, las Redirect URIs y la cadena de certificados completa.
El túnel está establecido, pero faltan los destinos internos: comprobar la ruta en el endpoint, Permitted Resources con Split Tunnel, la regla de firewall, la ruta de retorno, el firewall de destino y cualquier solapamiento con la red doméstica local.
La dirección IP funciona, pero el nombre de host no: comprobar los servidores DNS, el dominio de búsqueda, la ruta de Split Tunnel, la regla de firewall para DNS, el DoH local o el DNS del endpoint y, si corresponde, Device Access para DNS.
Solo algunos usuarios están afectados: comparar la pertenencia al grupo, la asignación de policy, MFA, la IP estática, Simultaneous logins y el perfil cargado.
Solo están afectados los clientes antiguos: importar un archivo .ovpn actualizado tras cambios globales. Si solo han cambiado la policy o un FQDN, volver a conectarse primero y comprobar el routing cargado.
Full Tunnel sin Internet: comprobar la regla de VPN a WAN, IPv4-SNAT, DNS y las Web/Security Policies aplicadas.
Las transferencias grandes se bloquean: si los accesos pequeños funcionan, comprobar MTU y MSS a lo largo de la ruta real. Consulte MTU y MSS para problemas de VPN para seguir el procedimiento.
La conexión termina después de un tiempo prolongado: comparar la hora de inicio y de desconexión con Idle Timeout, Disconnect idle clients y Key Lifetime. Comprobar la IP estática y Simultaneous logins; si es necesario, asignar una dirección dinámica a un usuario piloto y analizar sslvpn.log y openvpn-status*.log en el momento de la prueba.
Ningún usuario puede establecer el túnel: además de Device Access y la apertura del puerto, buscar una regla DNAT amplia con Original destination: Any y Services: Any, o con el puerto SSL VPN, que intercepte previamente el establecimiento de la conexión.
WAF, el portal o SSL VPN entran en conflicto: comparar la IP WAN, el puerto y el protocolo de todos los servicios locales y las reglas WAF. Las combinaciones compartidas pueden provocar una exposición adicional del portal o impedir el funcionamiento de Login Security.

Durante el funcionamiento, deben revisarse periódicamente los grupos, MFA, las asignaciones de IP estáticas, la caducidad de los certificados, el rango de direcciones, Device Access, las reglas de firewall, la distribución de perfiles y los logs. Las nuevas versiones de SFOS y Sophos Connect deben probarse primero con un usuario piloto y con pruebas positivas y negativas de acceso a destinos.