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 reversión. 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.

Limitación de la API XML para SFOS 22/23: La documentación de la API heredada sobre Configure SSLVPN Tunnel Access indica para DisconnectDeadPeerAfter un valor predeterminado de 300 segundos, un rango de 60 a 1800 y el valor 180 en el ejemplo, sin asociarlos a un protocolo concreto. Esto no confirma un valor predeterminado de funcionamiento para TCP/UDP ni un nuevo valor predeterminado de la GUI. Por tanto, no sustituya los valores TCP/UDP descritos anteriormente basándose en esta tabla de la API; compruebe el temporizador realmente guardado en Remote access VPN > SSL VPN > SSL VPN global settings en el build instalado.

Tampoco están aclarados los requisitos condicionales del esquema de leases: LeaseMode permite IPv4, aunque IPv6Lease e IPv6Prefix figuran como campos obligatorios y aparecen vacíos en el ejemplo; la tabla indica un rango de 64 a 112 para el prefijo. Esto no permite concluir que se puedan enviar campos IPv6 vacíos ni que falte compatibilidad con dual-stack. EndIP y CompressSSLVPNTraffic solo aparecen en el ejemplo y no constituyen un contrato de escritura validado ni una recomendación de compresión. Antes de implementar una automatización que dependa de ello, Sophos Support o la documentación aprobada para el build de destino deben aclarar los campos obligatorios condicionales y los valores de escritura; hasta entonces, no ejecute ningún cambio XML derivado de esta información. Para los cambios admitidos, conserve previamente los valores globales reales de los temporizadores, leases y DNS, así como la configuración de los pares SSL Site-to-Site afectados; después, compruebe la respuesta, los valores guardados y el lease de un usuario piloto que haya vuelto a conectarse. Si falla la aceptación, restaure exactamente los valores iniciales anotados y las configuraciones de los pares correspondientes, y repita las mismas pruebas de acceso.

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.

Limitación de la API XML para la policy: Los ejemplos de Add/Edit para SFOS 22/23 separan dentro de SSLVPNPolicy las ramas TunnelPolicy y ClientlessPolicy, cada una con su propio Name y PolicyMembers/Member. El acceso por túnel a recursos de red y la publicación sin cliente son funciones distintas, con nombres de policy y asignaciones de miembros independientes. WebAccessibleResources contiene BookmarkGroups y Bookmarks, no recursos IP del túnel. No trate un cambio como una modificación conjunta de ambas subpolicies; no interprete los permisos de marcadores como recursos del túnel.

La tabla también indica el campo obligatorio Web Access con los valores 1 y 6, sin un campo correspondiente en el ejemplo ni una asociación confirmada con los modos de la GUI. Para UseAsDefaultGateway figura SplitTunnel como valor predeterminado y para DisconnectIdleClients, UseGlobalSettings, aunque ambos solo indican Off y On como valores permitidos. No deduzca de ello una correspondencia numérica de modos, un valor predeterminado que pueda enviarse, el efecto de omitir campos ni la serialización de miembros. Mantenga pendiente el cambio de la API que dependa de ello hasta aclararlo para el build de destino; la configuración mediante la GUI descrita anteriormente sigue siendo la vía segura. Full Tunnel sigue requiriendo reglas de firewall restrictivas, y el valor de inactividad de la policy solo puede acortar 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.

Retirar una policy SSL VPN de forma segura

Una policy que ya no se necesita se elimina de forma selectiva; desconectar una sesión no la sustituye. Antes de eliminarla, determine qué acceso debe dejar de estar disponible y qué permisos siguen siendo necesarios.

Seleccione el Name exacto guardado y la rama de policy prevista: TunnelPolicy para acceso por túnel o ClientlessPolicy para acceso sin cliente. No se base únicamente en un nombre visible parecido.
Revise Policy members, la pertenencia real a los grupos y los recursos de red asignados o los marcadores y grupos de marcadores. Confirme que la retirada está aprobada y que ningún acceso todavía necesario depende de esta policy. Si las asignaciones no están claras, deténgase y aclare primero las dependencias; una reasignación puede retirar miembros de una policy anterior.
Conserve de forma protegida y recuperable el nombre, la rama, los miembros y todos los ajustes asociados. En Remote access VPN > SSL VPN, elimine solo la policy seleccionada mediante el procedimiento de eliminación compatible con el build de destino instalado. Si ese procedimiento no está claramente confirmado, consulte la documentación aprobada o Sophos Support antes del cambio.
Si el acceso debe cesar inmediatamente, revise por separado las sesiones activas en Current activities > Remote users, comprobando usuario, direcciones y Mode, y finalice de forma selectiva las sesiones afectadas con Disconnect. Desconectar no sustituye la revocación de permisos; no deduzca que eliminar la policy termina automáticamente los túneles.
Vuelva a comprobar las policies guardadas y las asignaciones de miembros. Con un usuario normal afectado, verifique la configuración esperada en VPN Portal y la autorización en un nuevo intento de conexión. El acceso concedido antes por la policy retirada debe cesar; el acceso todavía aprobado mediante otras policies debe mantenerse. Compruebe el tráfico realmente permitido y bloqueado junto con los logs del firewall y, para acceso sin cliente, los permisos de marcadores esperados. Aclare resultados inesperados antes de eliminar otras policies; utilice los ajustes conservados para una reversión selectiva solo con aprobación.

Límite documental: Las páginas Delete de la API XML heredada para SFOS 22/23 indican Name como parámetro obligatorio, pero no confirman un contrato XML completo de eliminación, efectos en cascada ni la semántica de los resultados o las sesiones. No deduzca de ellas un payload Delete, códigos de estado, textos de mensajes ni una revocación inmediata del acceso.

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.

Completar la configuración y preparar el diagnóstico

En un entorno nuevo, utilice Hosts and services > IP host > Add para introducir un nombre y una red o dirección de host, y pulse Save. Cree SSLVPN_Users en Authentication > Groups > Add con los valores adecuados de Surfing quota y Access time, y guarde. En Authentication > Users > Add, indique el nombre de usuario, el nombre visible y este grupo, y guarde. El acceso a internet ilimitado y los horarios sin restricciones son valores de ejemplo, no requisitos de seguridad. Para usuarios existentes del directorio, compruebe su asignación de grupo en lugar de crear cuentas locales innecesarias.

Además de los valores globales descritos anteriormente, compruebe:

Lease mode: IPv4 only asigna solo IPv4; IPv4 and IPv6 both asigna ambas familias de direcciones. El pool IPv6, las rutas y las reglas deben ser coherentes. Use static IP addresses muestra el rango estático dividido automáticamente; asigne direcciones individuales en Authentication > Users.
IPv4 WINS: Introduzca servidores WINS primario y secundario solo si el entorno necesita este servicio de nombres. WINS no sustituye a DNS.
Encryption algorithm, Authentication algorithm y Key size: Elija deliberadamente el cifrado, la autenticación de mensajes y la longitud de clave según los requisitos de seguridad aprobados. Key lifetime se expresa en segundos. No debilite la criptografía para diagnosticar una conexión.
Enable debug mode: Proporciona logs SSL VPN más detallados. Actívelo solo para una investigación concreta, proteja los logs y restaure después el estado anterior.

Guarde los cambios globales con Apply. Para una cadena de certificados firmada externamente, importe el certificado de servidor con su clave privada, la CA intermedia y la CA raíz. Los cambios en Default CA al usar ApplianceCertificate o un certificado firmado localmente también requieren una nueva importación manual de .ovpn. No utilice caracteres UTF-8 en los campos de certificado y CA; los caracteres especiales en nombres de usuario también pueden afectar al portal, los nombres de archivo y los clientes de terceros.

Con una sola IP WAN pública estática, Override hostname puede quedar vacío. Con varias direcciones, indique el FQDN deseado o una dirección de interfaz concreta, o compruebe cada entrada exportada. Detrás de NAT ascendente, indique el extremo público del router y compruebe su reenvío de puertos; para una dirección dinámica, configure primero Network > DDNS y utilice el FQDN DDNS. Inspeccione las entradas reales de gateway en .ovpn y pruebe la resolución de nombres por separado.

En el asistente, revise los valores globales, seleccione Next y configure VPN name, usuarios/grupos y Authentication servers. Las opciones son Same as VPN (IPsec, L2TP, PPTP), Same as firewall o Set authentication method for SSL VPN. Seleccione por separado el modo de túnel y las zonas; para Split Tunnel, confirme los recursos con Apply selected items al final de la lista. Seleccione Finish solo después de revisar los ajustes y compruebe las reglas generadas. El asistente no sustituye la comprobación de SNAT ni la configuración independiente del IdP.

⚠️ La introducción de la guía Full Tunnel afirma que solo son accesibles los recursos seleccionados en la policy; la ayuda del campo indica expresamente que Permitted network resources no se aplica con Use as default gateway. Una guía de diagnóstico anterior también sigue recomendando seleccionar recursos en este modo. Esta afirmación contradictoria no garantiza el control de acceso: utilice reglas de firewall explícitas como control para Full Tunnel y pruebe destinos permitidos y bloqueados. Las reglas amplias de ejemplo con Any no son obligatorias; restrinja por separado el acceso interno y a internet.

Para configurar el cliente manualmente, abra VPN en VPN Portal, seleccione Download for Windows o Download for macOS si es necesario e instale el cliente. Download configuration for Windows, macOS, Linux proporciona .ovpn; impórtelo con Import connection e inicie sesión con las credenciales del portal o el SSO preparado. El administrador también puede obtener el instalador mediante Remote access VPN > SSL VPN > Download client. El cliente SSL VPN antiguo ha llegado al fin de su vida útil y ya no se ofrece en el portal.

Si solo fallan ciertos endpoints, compruebe primero internet y los permisos del sistema operativo, firewall del endpoint y antivirus. Durante un intento de conexión, utilice el filtro BPF port <SSL VPN port number> en Diagnostics > Packet capture; Details en Sophos Connect muestra los parámetros de conexión. La ausencia de paquetes no demuestra un bloqueo del ISP. Descarte primero otras causas; cambie a una combinación permitida de puerto/protocolo solo después de comprobar conflictos con WAF/portal y preparar la distribución de perfiles y el rollback. El problema documentado de compresión Android/OpenVPN afecta a SFOS 20.0 GA y versiones anteriores, no a SFOS 22/23 de forma general.

Con el túnel establecido, compruebe en la tabla de rutas del endpoint la red de destino, la interfaz TUN y la dirección asignada. Si falta la ruta, reconecte primero y compruebe el log del cliente y los permisos del endpoint; reimportar solo ayuda con la configuración actual adecuada. En Log viewer > Firewall, filtre por In interface, Is, tun y compruebe el ID de Firewall rule. Para reglas específicas de usuario, compruebe también Match known users y User or groups. Para distinguir problemas de VPN de problemas de red interna, pruebe la conectividad desde el firewall al destino en Diagnostics > Tools; retire después cualquier permiso temporal de ping. Ante reconexiones, compruebe también cambios en direcciones asignadas, DNS/WINS y dominio, y no utilice interfaces WAN como Permitted network resources. Los cambios de policy no terminan automáticamente los túneles existentes: los usuarios deben desconectar y reconectar por separado.

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. Si el servicio muestra UNREGISTERED, compruebe que exista al menos una política SSL VPN. 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. Para esta excepción de diagnóstico, use 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.