Sophos Firewall SSL VPN Configurar acceso remoto

SSL VPN sigue siendo una ruta de acceso remoto importante, especialmente cuando los usuarios trabajan desde hoteles, WLAN huéspedes, redes celulares o redes restrictivas de terceros. Pero lo importante no es sólo si el túnel está construido. Lo que es crucial es si el firewall limita el acceso correctamente, si el DNS funciona, si el MFA funciona 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 lado del firewall del acceso remoto SSL VPN en Sophos Firewall. Para la instalación del cliente, 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, Sophos Connect o SSL VPN: ¿Qué solución de acceso remoto es adecuada? es la primera opción.

¿Qué artículo SSL-VPN encaja?

SSL VPN consta de configuración de firewall, portal, cliente, autenticación y posterior análisis de errores. Dependiendo de la tarea, es apropiado un enfoque diferente:

• Configure SSL VPN en el firewall: Este artículo
• Básicamente compare Sophos Connect o SSL VPN: Sophos Connect o SSL VPN: ¿Qué solución de acceso remoto es la adecuada?
• Mantener versiones y perfiles del cliente de Sophos Connect: Compruebe la versión del cliente Sophos Connect y actualícela de forma segura
• Configurar el cliente SSL-VPN en Windows: Configurar Sophos SSL VPN con Sophos Connect en Windows
• Configure SSL VPN en macOS, iOS o Android: macOS, iPhone/iPad o Android
• Utilice Microsoft Entra ID SSO o Entra-MFA: Configurar el SSO de Microsoft Entra ID para Sophos Connect y VPN Portal
• VPN está conectado pero el tráfico no funciona: Probar regla de firewall con Log Viewer, Policy Test y Packet Capture
• Las transferencias grandes se bloquean o aplicaciones individuales no cargan: Verificar MTU y MSS en problemas de VPN.

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

Imagen de destino

Una estructura SSL-VPN limpia consta de varios componentes básicos:

1. Los usuarios o grupos están autorizados en la política SSL VPN correcta.
2. La configuración global de SSL VPN define la puerta de enlace, el puerto, el certificado, Lease-Bereich, DNS y criptografía.
3. El VPN Portal solo es tan accesible como sea necesario y está protegido con MFA.
4. Las reglas del firewall permiten el tráfico desde la zona VPN solo a los destinos requeridos.
5. Se decide deliberadamente Split Tunnel o Full Tunnel.
6. Los clientes importan un perfil .ovpn actual.
7. Los registros, Packet Capture y los datos de soporte se pueden evaluar en caso de error.

Muchos problemas de SSL VPN surgen porque sólo está documentada la descarga del cliente. Sin embargo, en la práctica hay que considerar el portal, la autenticación, la política SSL-VPN, la regla de firewall, DNS y NAT juntos.

⚠️ SSL VPN es un punto de entrada de acceso público. MFA y las contraseñas seguras son importantes, pero no reemplazan los límites en Device access, grupos de usuarios limitados, perfiles actuales, registros y revisiones periódicas.

⚠️ Los cambios en la puerta de enlace, el puerto, el certificado, el DNS, el Lease-Bereich o la política no terminan automáticamente en los perfiles de clientes ya importados. Después de los cambios relevantes, el archivo .ovpn debe volver a descargarse, distribuirse y reemplazarse en los clientes.

Requisitos

Antes de la configuración conviene aclarar estos puntos:

• Sophos Firewall con versión actual SFOS.
• Accesibilidad pública del firewall o reenvío de puertos ascendentes.
• FQDN o dirección IP pública para acceso VPN.
• Certificado para VPN Portal y SSL VPN, idealmente coincidente con el FQDN.
• Usuarios o grupos para acceso remoto.
• Servidores de autenticación para VPN Portal y SSL VPN: local, Active Directory, RADIUS o Microsoft Entra ID.
• Concepto MFA/OTP para VPN Portal y acceso remoto.
• Redes internas de destino, servidores DNS y dominio de búsqueda.
• Opte por Split Tunnel o Full Tunnel.
• Reglas de firewall para el tráfico de la zona VPN.
• Proceso de actualización del cliente y redistribución del archivo .ovpn.

Si se va a utilizar Microsoft Entra ID SSO, la autenticación debe prepararse correctamente antes de descargar la configuración de VPN. El proceso se encuentra en Configuración de Microsoft Entra ID SSO para Sophos Connect y VPN Portal.

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:

• LAN_Server: 10.10.10.0/24. servidores internos
• LAN_Client: 10.10.20.0/24. Red de clientes, si es necesario
• DNS_Internal: 10.10.10.10. DNS interno o controlador de dominio
• SSLVPN_Users: Grupo de usuarios. Miembros de la política

No debería simplemente liberar áreas enteras de la red interna si solo son necesarios servidores o subredes individuales. Cuanto más estrechamente estén definidos los objetos, más sencilla será la regla del cortafuegos en el futuro.

Si se usan servidores DNS dentro del túnel, no solo deberían figurar en los ajustes globales de SSL VPN, sino existir también como objetos de destino. Especialmente con Full Tunnel o recursos estrictamente limitados, de lo contrario el túnel puede estar conectado pero la resolución de nombres queda rota.

2. Verifique la configuración global de SSL-VPN

La configuración global se aplica 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 utilizar TCP o UDP según la configuración. UDP suele ser más eficiente, TCP puede funcionar mejor en redes restrictivas. La decisión debería probarse en las redes desde las que realmente trabajan los usuarios.

En cuanto a los puertos, hay que evitar solapamientos:

• SSL VPN El puerto predeterminado suele ser 8443.
• VPN Portal usa 443 de forma predeterminada en las versiones actuales de SFOS.
• Las reglas WAF y SSL VPN no pueden superponerse en la misma IP WAN con el mismo puerto y el mismo protocolo.
• Si SSL VPN y VPN Portal usan el mismo puerto, las funciones de seguridad de inicio de sesión no pueden funcionar como se esperaba.

Si WAF, VPN Portal, User Portal y SSL VPN funcionan en la misma IP WAN, debe documentar conscientemente el puerto, el protocolo y el certificado. Para los conceptos básicos de WAF, Sophos Firewall Configure WAF y evite errores típicos es adecuado.

Certificado y anulación del nombre de host

Se debe utilizar un certificado que coincida con el FQDN público en Certificado de servidor SSL. Un error de certificado en el perfil VPN Portal o SSL VPN dará lugar a casos de soporte innecesarios más adelante. En Override hostname, especifica qué nombre de host o dirección IP utilizan los clientes en el perfil .ovpn. Esto es particularmente importante para:

• múltiples direcciones IP WAN,
• enrutador ascendente,
• NAT o reenvío de puertos frente al firewall,
• WAN-IP dinámico con DDNS,
• FQDN separados para WebAdmin, VPN Portal y SSL VPN.

Si el campo se deja vacío, varias direcciones de interfaz pueden terminar en el perfil. Esto puede funcionar, pero en entornos de producción suele ser menos claro que un FQDN limpio.

Sophos Connect no intenta simplemente los gateways del archivo .ovpn en el orden visible; los gateways DNS dinámicos y el orden de varias entradas pueden comportarse de forma distinta en la práctica. Para setups productivos, un Override Hostname inequívoco es más fácil de probar y soportar.

Después de cambiar el nombre de host de anulación, debe descargar un nuevo perfil y verificar si el cliente realmente tiene el nuevo FQDN o la nueva dirección IP pública. De lo contrario, podría terminar probando la conexión anterior aunque la configuración del firewall ya sea correcta.

Lease-Bereich

Sophos Firewall asigna direcciones de clientes SSL VPN desde el Lease-Bereich configurado. Esta área no debe colisionar con redes internas, rutas estáticas, VPN de sitio a sitio o áreas típicas de redes domésticas.

Debes evitar subredes particularmente 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

Cuando el Lease-Bereich choca con la red doméstica de un usuario, el túnel a veces se conecta exitosamente, pero los destinos internos permanecen inaccesibles. Esto entonces parece un problema de regla de firewall, pero es un problema de enrutamiento en el punto final.

Para las reglas de firewall, debe utilizar los hosts del sistema ##ALL_SSLVPN_RW y para IPv6 ##ALL_SSLVPN_RW6, no los hosts recreados manualmente con Lease-Bereich antiguos.

Para IPv4, Sophos Firewall solo acepta en los ajustes globales SSL-VPN subredes hasta /24. Redes más pequeñas como /25 no se pueden seleccionar allí. Aunque se esperen pocos usuarios, conviene planificar una red VPN limpia y sin colisiones y limitar el acceso mediante reglas de firewall, no mediante un Lease-Bereich artificialmente pequeño.

Direcciones IP estáticas SSL VPN y duración de la clave

Las direcciones IP estáticas SSL VPN pueden ser útiles en casos individuales, por ejemplo, para acceso de administrador, acceso especial estrictamente registrado o aplicaciones heredadas con aprobación basada en IP. Sin embargo, no son adecuados como estándar para todos los usuarios. Cuantas más asignaciones estáticas haya, más difíciles serán la operación, el análisis de errores y las migraciones posteriores.

Además, Sophos Firewall no soporta inicios de sesión Remote Access simultáneos para usuarios con dirección IP SSL-VPN asignada estáticamente. Esto importa en cuentas compartidas, dispositivos paralelos o pruebas en las que un usuario debe estar conectado con portátil y segundo dispositivo al mismo tiempo. Estos diseños no deberían resolverse con IPs estáticas.

Un caso especial específico está documentado en la lista de problemas conocidos: para SSL VPN con autenticación local y IP SSL VPN asignada estáticamente, la reautenticación puede fallar después de que haya expirado la vida útil de la clave. El firewall puede tratar la dirección de arrendamiento ya asignada como un conflicto. Luego, los usuarios tienen que volver a conectarse manualmente aunque el túnel estuviera funcionando anteriormente. Un valor de duración de clave típico es 18000 segundos.

Si un usuario tiene que iniciar sesión repetidamente después de varias horas, no solo debe verificar MFA, la versión del cliente y la regla del firewall. Además, estos puntos pertenecen al análisis:

• ¿Se utiliza autenticación local para SSL VPN?
• ¿Tiene el usuario una dirección IP estática SSL VPN?
• ¿El problema ocurre aproximadamente después de que haya expirado la vida útil de la clave?
• ¿El mismo usuario trabaja de forma más estable con la asignación dinámica de IP?
• ¿Es realmente necesaria una IP estática o es suficiente una regla sobre el grupo de usuarios, el host del sistema SSL-VPN y el registro?

Sophos cita dos contramedidas pragmáticas: planificar la vida útil de la clave para que cubra la jornada laboral normal o utilizar la asignación dinámica de IP. En muchos entornos, la asignación dinámica es más limpia porque las reglas de firewall ya deberían estar controladas en 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, los servidores DNS y, opcionalmente, un nombre de dominio se configuran en la configuración global SSL-VPN. En entornos de Active Directory, suele ser un servidor DNS interno o un controlador de dominio.

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

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

• ¿Se puede acceder al objetivo a través de la dirección IP?
• ¿El servidor DNS interno está permitido por la regla del firewall?
• ¿Recibe el cliente el dominio de búsqueda correcto?
• ¿El cliente realmente utiliza el perfil .ovpn actual?
• ¿Interviene la configuración DNS o DoH local del endpoint?

Si debe alcanzarse directamente un servidor DNS interno, el usuario VPN también necesita acceso a ese servidor DNS. Es decir: el servidor DNS debe estar en los recursos permitidos o ser permitido por una regla adecuada desde la zona VPN. Con Full Tunnel, DNS no debe tratarse como efecto colateral de la regla de Internet, sino probarse conscientemente.

Para Split Tunnel, el DNS debe planificarse con especial cuidado. Si solo se enrutan las redes de destino internas a través del túnel, debe quedar claro si los nombres internos se resuelven a través del servidor DNS interno y si los nombres públicos se resuelven localmente o a través del firewall. De lo contrario, surgen errores en los que funciona el acceso IP, pero los nombres de host internos solo se resuelven en clientes individuales.

3. Crear política SSL VPN

La política se crea en:

Remote access VPN > SSL VPN

Sophos ofrece para ello el asistente SSL-VPN o la configuración manual. El asistente puede crear policy, VPN Portal, servidor de autenticación, regla de firewall y Device Access en un solo flujo. Es útil en setups nuevos. En entornos existentes, Configure manually suele ser mejor porque posición de regla, objetos de destino, logging y acceso al portal pueden revisarse conscientemente.

Proceso para configuración manual:

1. Seleccione Add.
2. Utilice Configure manually.
3. Asigne un nombre, por ejemplo SSLVPN-Remote-Users.
4. Seleccione los usuarios o grupos autorizados en Miembros de la política.
5. Configure Split Tunnel o Full Tunnel.
6. Para Split Tunnel, seleccione Permitted network resources; con Full Tunnel preparar los objetos de destino sobre todo para las reglas de firewall.
7. Opcionalmente configure Disconnect idle clients.
8. Guarde y luego verifique con un usuario de prueba.

Importante: Si los usuarios o grupos están inscritos en una política SSL-VPN más nueva que ya está incluida en una política SSL-VPN anterior, Sophos Firewall elimina esta asociación de la política anterior. Por lo tanto, debe evitar superposiciones de políticas y definir claramente qué política se aplica a cada grupo de usuarios.

Las Permitted network resources limitan en Split Tunnel los destinos internos que los usuarios remotos deben alcanzar. Con Use as default gateway es diferente: Sophos Firewall no fuerza los Permitted Resources como límite de acceso. Todo el tráfico pasa por el firewall, y el límite real debe hacerse con reglas de firewall, zonas, objetos de destino, services y logging.

Para Full Tunnel se deben modelar igualmente los destinos internos como objetos limpios, pero no confiar en que la SSL-VPN-Policy por sí sola los limite. Las interfaces no son un buen sustituto, porque una interfaz no describe automáticamente qué subredes están permitidas desde el punto de vista operativo.

Si se usan objetos FQDN como recursos permitidos en Split Tunnel, hay que planificar la operación conscientemente. Los logs de SSL-VPN muestran las IP resueltas, y los cambios FQDN dinámicos no entran automáticamente en túneles ya existentes. Los usuarios afectados deben desconectar y reconectar para que nuevas direcciones de destino sean efectivas.

Después de los cambios de política, se debe registrar un usuario normal del grupo objetivo en VPN Portal. Debería estar visible exactamente la configuración SSL-VPN esperada, no varios perfiles antiguos o ninguna configuración. Esta prueba del portal revela errores de grupo más rápidamente que una prueba de administrador pura con derechos especiales.

4. Elija Split Tunnel o Full Tunnel

Split Tunnel

Con Split Tunnel, 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.

Split Tunnel suele encajar en:

• Acceso a algunas aplicaciones internas,
• menor carga de firewall,
• mejor rendimiento del usuario,
• ubicaciones remotas más pequeñas y usuarios móviles.

Entonces, la seguridad depende más del punto final, el entorno de la red local y los recursos internos compartidos.

Full Tunnel

Con Full Tunnel, todo el tráfico de usuarios remotos se enruta a través del firewall. En Sophos Firewall esto corresponde a la opción Usar como puerta de enlace predeterminada.

Full Tunnel es más adecuado si:

• El tráfico de Internet debería controlarse de forma centralizada.
• Protección web, DNS Protection o registro deben aplicarse a los usuarios de VPN,
• Los usuarios trabajan desde redes inseguras,
• El cumplimiento requiere una evaluación central.

Para Full Tunnel, la política SSL VPN por sí sola no es suficiente. También necesita reglas de firewall y NAT/SNAT para el tráfico de Internet desde la zona VPN. También debes probar de antemano el rendimiento, el ancho de banda, el filtrado web y el registro. Full Tunnel no debe activarse sólo porque los objetivos individuales de Split-Tunnel sean difíciles de mantener. Cuando todo el tráfico de Internet pasa a través del firewall, la capacidad, el filtrado web, el DNS, el registro, la protección de datos y los gastos generales de soporte se convierten en parte del diseño.

También en Full Tunnel, las redes internas de destino y los servidores DNS deben modelarse limpiamente como destinos de firewall. De lo contrario, el camino de default gateway funciona, pero aplicaciones internas o resolución de nombres dependen de una regla de Internet demasiado amplia.

5. Crear reglas de firewall para la zona VPN

Establecer un túnel no significa que se permita el tráfico. Para acceder a los recursos internos necesita una regla de firewall adecuada:

Rules and policies > Firewall rules

Regla recomendada para Split Tunnel:

• Nombre de la regla: VPN_SSLVPN_to_Internal_Servers
• Zona de origen: VPN
• Source networks and devices: ##ALL_SSLVPN_RW
• Destination zones: zonas objetivo internas, por ejemplo LAN o DMZ
• Destination networks: sólo servidores o subredes permitidos
• Services: sólo servicios necesarios
• Registrar el tráfico del firewall: activar

Para Full Tunnel también necesitas una regla desde VPN hasta WAN o Any, según el diseño. Las redes de origen deben seguir siendo los hosts del sistema SSL VPN. A continuación se debe comprobar si existe una regla SNAT adecuada.

Si hay conexión pero no funciona el acceso, primero debes verificar el Log Viewer. Probar la regla de firewall con Log Viewer, Policy Test y Packet Capture es adecuada para la metodología.

Las reglas para SSL VPN deben estar en un grupo con un nombre claro, por ejemplo VPN Remote Access. Una regla amplia como VPN_to_LAN_Any es conveniente, pero dificulta el análisis de errores posterior y, a menudo, permite más acceso del que es técnicamente necesario. Es mejor tener reglas separadas por área objetivo o clase de servicio con registro activo.

6. Asegure VPN Portal y Device Access

Los usuarios suelen cargar Sophos Connect y el archivo .ovpn desde VPN Portal:

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

Al menos comprueba:

• Puerto y certificado VPN Portal.
• Métodos de autenticación VPN Portal.
• MFA para VPN Portal y Acceso Remoto.
• Device Access para VPN Portal solo en zonas requeridas.
• Device Access para SSL VPN en la zona WAN solo si se requiere externamente.
• No hay User Portal abierto permanentemente en WAN cuando no está en uso.

Para reforzar los servicios de firewall locales, Device Access y Local Service ACL se adaptan a Sophos Firewall. Para los conceptos básicos de MFA se adapta a MFA para Sophos Firewall WebAdmin, VPN Portal y habilitar acceso remoto.

El VPN Portal solo parece útil 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 política, el usuario no verá las descargas de configuración requeridas.

El VPN Portal controla el inicio de sesión para descarga y acceso a perfiles; SSL VPN authentication methods controla la autenticación real del túnel. Ambos ámbitos pueden usar el mismo servidor, pero no quedan automáticamente correctos entre sí. Con RADIUS, además, la MFA basada en challenge para el VPN Portal no está soportada; estos diseños deben probarse antes del rollout con un usuario real.

Si es necesario permitir VPN Portal o SSL VPN en la zona WAN, esto debe documentarse deliberadamente. En muchos entornos, no basta con abrir el servicio en todo el mundo y confiar en MFA. Siempre que sea posible, se deben examinar las redes de fuente fija, las restricciones de los países, las fuentes de amenazas, la verificación de registros o un diseño de acceso remoto ascendente.

Es importante separar WebAdmin y VPN Portal. WebAdmin es la interfaz de administración del firewall. El VPN Portal es el acceso de usuario para descargas y perfiles VPN. Ambos servicios no deben agruparse porque tienen diferentes riesgos, puertos, permisos y audiencias.

7. Distribuir perfil de cliente

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

Importante:

• Después de cambios en la puerta de enlace, puerto, certificado, DNS, Lease-Bereich, política o autenticación, se debe volver a cargar el perfil.
• Una actualización de Sophos Connect no reemplaza un perfil .ovpn antiguo.
• Los nombres de los perfiles deben ser únicos.
• Los perfiles antiguos deben eliminarse al cambiar de ubicación, puerta de enlace o usuario.
• Windows, macOS, iOS, Android y Linux a veces utilizan rutas de cliente diferentes.
• Los archivos de provisioning de Sophos Connect (.pro) pueden importar automáticamente configuraciones IPsec y SSL-VPN, pero pertenecen al modelo operativo de Sophos Connect y no sustituyen una SSL-VPN-Policy limpia.

Para Sophos Connect hay que revisar activamente los límites de plataforma: los clientes actuales soportan Windows 10 y 11, macOS 13 o posterior, y Windows ARM desde Sophos Connect 2.5. Microsoft Entra ID SSO en Sophos Connect Client es un escenario Windows con Sophos Connect 2.4 o posterior. Plataformas móviles como iOS y Android no usan Sophos Connect para SSL VPN, sino apps compatibles con OpenVPN u otros caminos de cliente.

Cambios de perfil típicos en funcionamiento:

• Nuevo FQDN o nueva IP pública: Vuelva a descargar .ovpn y reemplace el perfil anterior
• Puerto o protocolo cambiado: Vuelva a importar el perfil y elimine la entrada de conexión anterior
• Certificado renovado o modificado: Redistribuir el perfil y comprobar activamente las advertencias del certificado
• Servidor DNS o nombre de dominio cambiado: Importar nuevo perfil y probar la resolución del nombre
• Lease-Bereich cambiado: Vuelva a importar el perfil y verifique la ruta/dirección del cliente
• Grupo de usuarios o política modificada: Descarga del portal de prueba con usuario objetivo normal

Para actualizaciones de clientes y mantenimiento de versiones, Compruebe la versión de Sophos Connect Client y actualícela de forma segura.

Con Sophos Connect, un archivo de provisioning carga la configuración .ovpn solo para usuarios asignados a una SSL-VPN-Policy. Si un usuario con archivo .pro recibe solo IPsec o ninguna conexión SSL-VPN, no significa automáticamente que el archivo de provisioning esté roto. Primero revisar Policy members, disponibilidad del VPN Portal, authentication methods y grupo de usuario.

Prueba después de la configuración

Con un usuario de prueba no sólo debería comprobar si Sophos Connect muestra Connected.

Lista de pruebas:

• El usuario ve la descarga de Sophos Connect y la configuración SSL VPN en el VPN Portal.
• Se puede importar el archivo .ovpn.
• Se sondeó MFA como se esperaba.
• El cliente recibe una dirección de SSL-VPN-Lease-Bereich.
• La ruta a las redes internas permitidas aparece en el punto final.
• Con Full Tunnel está claro que los accesos internos se limitan por reglas de firewall, no solo por Permitted Resources.
• Con recursos FQDN funciona una prueba de reconnect después de un cambio DNS.
• Se resuelven los nombres DNS internos.
• Funciona el acceso a servidores permitidos.
• Las redes no autorizadas permanecen bloqueadas.
• Log Viewer muestra la regla de firewall correcta.
• Una prueba negativa deliberada será rechazada y registrada.
• Packet Capture muestra el tráfico a través de una interfaz tun si es necesario.
• El acceso a Internet y SNAT también funcionan con Full Tunnel.

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

Una buena prueba de aceptación siempre incluye el acceso bloqueado. Esta es la única manera de ver si las reglas del firewall son realmente limitantes o si una regla demasiado amplia más abajo en el conjunto de reglas aún permite el acceso.

Prueba de aceptación por escenario

Antes de una implementación amplia, al menos estos casos de prueba deben estar claramente documentados:

• Nuevo usuario: Registro en VPN Portal e importación de perfil. El usuario solo ve la configuración SSL-VPN coincidente y puede importar el perfil
• MFA activo: Inicie sesión con OTP correcta e incorrecta. El factor correcto permite el acceso, el factor incorrecto se rechaza y se registra
• Split Tunnel: Acceso a destino interno permitido y no permitido. Los destinos permitidos funcionan, otras redes permanecen bloqueadas
• Full Tunnel: Acceso a Internet mediante VPN. La regla de firewall, SNAT, DNS y la política web/de seguridad funcionan según lo planeado
• DNS: Acceso por nombre y por dirección IP. Los errores de DNS se pueden separar de los problemas de enrutamiento o reglas
• Cambio de perfil: Importar nuevo perfil .ovpn. El FQDN, el puerto, el DNS o el certificado modificados son visibles en el perfil del cliente
• Caso de error: Verifique Log Viewer y Packet Capture. Se puede rastrear la regla de firewall coincidente real y el flujo de paquetes Para entornos de producción, cada prueba debe contener una hora, un usuario, una plataforma de cliente y un objetivo específico. Declaraciones como “VPN funciona” o “VPN no funciona” son demasiado imprecisas para casos de soporte posteriores.

Recopilar registros y pruebas

Si tiene problemas con SSL-VPN, primero debe aclarar si el error está en el inicio de sesión, en la configuración del túnel o en el acceso a destinos internos. Esta separación ahorra tiempo porque, de lo contrario, la autenticación, el perfil del cliente, el enrutamiento y las reglas de firewall se verifican juntos.

Para un caso de prueba reproducible, se debe tener en cuenta esta información:

• Nombre de usuario y grupo: muestra qué política y autenticación SSL-VPN deben aplicarse
• Plataforma cliente y versión de Sophos Connect: separa los errores del cliente de la configuración del firewall
• Hora de la prueba: hace que Log Viewer, sslvpn.log y los registros de autenticación sean comparables
• Red de origen del usuario: ayuda con hotel-WLAN, celular, CGNAT, firewalls restrictivos o problemas de puertos
• Sistema y servicio de destino: evita declaraciones demasiado amplias como “VPN no funciona”
• Resultado por dirección IP y por nombre DNS: separa los problemas de enrutamiento y DNS

Luego deberás realizar la prueba en este orden:

1. Verificar autenticación: Verifique en Log Viewer y, si es necesario, en los registros de autenticación si el usuario, MFA, el grupo y el servidor de autenticación son exitosos. Para Microsoft Entra ID SSO, oauth_sso_vpn.log también es relevante.
2. Verifique el estado del túnel: Verifique la conexión SSL VPN, la dirección de arrendamiento y el estado de OpenVPN. sslvpn.log y openvpn-status*.log ayudan en el lado del firewall.
3. Verifique la regla del firewall: Busque tráfico de la zona VPN en la Log Viewer y verifique qué regla coincide realmente. La regla debe tener Registrar tráfico del firewall activo.
4. Verifique el flujo de paquetes: Si Log Viewer no es suficiente, filtre por origen, destino y servicio con Packet Capture. Lo importante es si los paquetes son solo Incoming o también se convierten en Forwarded.
5. Verifique la página de destino: Si el tráfico sale del firewall pero no regresa ninguna respuesta, la ruta de retorno, el firewall del servidor, el firewall del host local o un conflicto de red son más probables que la política SSL VPN.

Solución de problemas de Sophos Firewall: Services y registros es adecuado para asignar los archivos de registro más importantes. Para el análisis de reglas con Log Viewer, Policy Test y Packet Capture, se adapta Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.

Solución de problemas

El usuario no ve la configuración SSL VPN en VPN Portal

Generalmente falta la asignación de política. Compruebe si el usuario o su grupo está incluido en la política SSL VPN en Miembros de la política. Además, se debe verificar la autenticación y la accesibilidad a los portales MFA y VPN.

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

El túnel se conecta, pero no se puede acceder a los sistemas internos

Primero verifique si existe una ruta a la red de destino interna en el punto final. Luego busque en Log Viewer el tráfico de la zona VPN. Si no hay tráfico visible, el cliente no llega al firewall como se esperaba o el perfil no está actualizado.

Si el tráfico es visible pero se aplica la regla incorrecta, es necesario corregir el orden de la regla o la definición del servicio/objetivo. Si no hay ninguna respuesta, es probable que haya un enrutamiento, un firewall de destino, un firewall del servidor local o un conflicto de red.

Después de un cambio, solo algunos de los clientes funcionan

Si los nuevos usuarios trabajan pero los antiguos no, la distribución de perfiles suele ser el problema. Se comprueba si los clientes afectados realmente importaron el perfil .ovpn actual y si se eliminaron las entradas de conexión antiguas.

Especialmente después de cambios en FQDN, puerto, certificado, DNS, Lease-Bereich, política o autenticación, no solo debe guardar el firewall, sino también probar activamente la descarga de un perfil con un usuario normal. Luego puede verificar en el punto final si la puerta de enlace, el DNS y las rutas corresponden al diseño actual.

DNS no funciona

Usted comprueba si funciona el acceso a través de la dirección IP. Si es así, probablemente el error esté en el DNS. Luego verifique el servidor DNS en la configuración global SSL VPN, el nombre de dominio, Device Access para DNS de la zona VPN y el comportamiento de DNS del punto final.

Si el servidor DNS interno no está incluido como recurso permitido o no es alcanzable mediante una regla de firewall desde la zona VPN, un perfil .ovpn correcto tampoco ayuda. Por eso DNS debe probarse siempre con un servidor DNS concreto, un nombre interno concreto y un filtro de Log Viewer sobre el servicio DNS.

El acceso solo funciona para algunos usuarios

Entonces, la pertenencia a un grupo, la asignación de políticas, las direcciones IP estáticas SSL VPN, el estado de MFA o los perfiles obsoletos son más probables que un error de firewall global. También debe comprobar si hay asignaciones de políticas duplicadas.

Si un usuario usa varios dispositivos en paralelo o se utiliza una cuenta compartida, revisar con especial cuidado las direcciones IP estáticas SSL-VPN. Sophos no soporta inicios de sesión Remote Access simultáneos para el mismo usuario con IP SSL-VPN asignada estáticamente.

El usuario necesita volver a conectarse después de varias horas

Si SSL VPN funciona inicialmente, pero después de varias horas es necesario un nuevo inicio de sesión o una reconstrucción manual, primero debe verificar el patrón de tiempo, la autenticación y el modelo de arrendamiento. Esto es particularmente relevante para la autenticación local con una IP SSL VPN asignada estáticamente.

Proceso práctico:

1. Anote la hora en que se estableció y canceló la conexión.
2. Compare el tiempo con la vida útil de la clave configurada.
3. Compruebe si el usuario tiene una dirección IP estática SSL VPN.
4. Pruebe la asignación de IP dinámica para un usuario piloto si es operativamente posible.
5. Verifique sslvpn.log, openvpn-status*.log y Log Viewer para autenticación, dirección de arrendamiento y volver a iniciar sesión.
6. Si se elige una vida útil de clave más larga, documente el cambio y no lo considere un reemplazo de MFA o un control de sesión limpia.

Si las IP estáticas solo se utilizan para hacer que las reglas del firewall parezcan más simples, se debe reelaborar el diseño. En la mayoría de los casos, los grupos, los objetivos claramente nombrados, los servicios específicos y el registro son una mejor base que las direcciones IP de usuarios individuales.

Full Tunnel no tiene acceso a internet

Con Usar como puerta de enlace predeterminada, se requiere una regla de firewall para el tráfico desde la zona VPN hacia Internet y una regla SNAT adecuada. Además, se deben planificar políticas web, DNS y de seguridad para que no bloqueen inesperadamente a los usuarios de VPN.

Se establece la conexión, pero se bloquean transferencias grandes

Si el inicio de sesión, los DNS y los accesos pequeños funcionan, pero se bloquean RDP, las transferencias de archivos, las aplicaciones web o las descargas grandes, debe verificar MTU y MSS. El patrón de error a menudo coincide con fragmentación, PPPoE, conexiones tunelizadas o una ruta asimétrica, no solo con el propio SSL VPN.

Para un análisis sistemático, Sophos Firewall Compruebe MTU y MSS para detectar problemas de VPN encaja.

WAF o portal choca con SSL VPN

Si WAF, VPN Portal, User Portal y SSL VPN se ejecutan en la misma IP WAN, el puerto y el protocolo deben estar claramente separados. Las combinaciones compartidas de WAN-IP, puerto y TCP son particularmente críticas. Si las gotas no son claras, verifique Log Viewer y Packet Capture.

El perfil está desactualizado después del cambio

Después de cualquier cambio en la política SSL-VPN, puerta de enlace, DNS, certificado, puerto o autenticación, el archivo .ovpn debe volver a descargarse e importarse. Muchos problemas aparentes de los clientes son perfiles obsoletos.

Si Sophos Connect se usa con un archivo de provisioning .pro, comprobar además si el cliente actualizó realmente el perfil o si sigue usando una entrada de conexión antigua. En dispositivos Windows compartidos con Entra-ID-SSO, después de cambios de usuario debe forzarse un nuevo login SSO para que no siga activo el contexto del usuario anterior.

Lista de verificación operativa

Antes del lanzamiento productivo

• FQDN y certificado verificados para VPN Portal y SSL VPN.
• SSL-VPN-Lease-Bereich no entra en conflicto con las redes domésticas internas o típicas.
• El Lease-Bereich IPv4 está planificado como /24 o red seleccionable más grande, no como diseño /25 más pequeño.
• La política SSL-VPN contiene los usuarios o grupos correctos.
• Se decide deliberadamente Split Tunnel o Full Tunnel.
• Los recursos de red permitidos se definen estrictamente en Split Tunnel.
• Con Full Tunnel, las reglas de firewall limitan destinos internos y services.
• El servidor DNS y el nombre de dominio están configurados correctamente.
• Los servidores DNS internos son recurso permitido o alcanzables mediante una regla adecuada.
• Existe una regla de firewall desde VPN hacia objetivos internos y se registra.
• Full Tunnel tiene reglas de internet y SNAT.
• Device Access para SSL VPN y VPN Portal se configura deliberadamente.
• MFA está probado para acceso remoto.
• El usuario de prueba puede descargar, importar perfiles y alcanzar objetivos internos.

Para operaciones en curso

• MFA para VPN Portal y forzar acceso remoto.
• Consultar periódicamente los grupos VPN.
• Mantenga estrictas las reglas de firewall para VPN y registre.
• Verifique Lease-Bereich antes de cambios de red.
• Utilice únicamente direcciones IP estáticas SSL VPN específicamente y verifíquelas periódicamente.
• Documentar DNS y buscar dominio.
• Renovar los certificados de portal y SSL VPN antes de su vencimiento.
• Seguimiento de las versiones de Sophos Connect.
• Programar la redistribución del perfil después de los cambios.
• Evalúe los registros a largo plazo utilizando Syslog o Sophos Central si la trazabilidad es importante.

Solución de problemas de Sophos Firewall: Services y registros es adecuado para archivos de registro y servicios.

Compruebe los casos especiales con regularidad

• Las direcciones IP estáticas SSL VPN están justificadas y documentadas.
• Las direcciones IP estáticas SSL-VPN no se requieren para usuarios que necesitan inicios Remote Access paralelos.
• Key Lifetime se ajusta al modelo operativo y ha sido probado con Reconnect.
• El perfil antiguo .ovpn se redistribuirá después de los cambios.
• Los recursos FQDN se prueban con comportamiento de reconnect.
• VPN Portal, User Portal, 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 verifican por separado.

Preguntas frecuentes