Configurar Sophos Connect en Sophos Firewall

Sophos Connect es el cliente estándar para Remote Access con Sophos Firewall en muchos entornos. Sin embargo, la calidad real de la solución no se decide solo en Windows o macOS, sino en la firewall: autorización de usuarios, pool IP, DNS, autenticación, MFA, reglas firewall y distribución posterior de perfiles deben encajar.

Este artículo describe la planificación y configuración del lado de la firewall para Sophos Connect, sobre todo para IPsec Remote Access y la distribución de perfiles. Para SSL VPN, la Remote Access policy propiamente dicha se describe en Configurar Sophos Firewall SSL VPN Remote Access. Para la decisión básica entre IPsec, SSL VPN, clientes móviles y ZTNA, conviene empezar por Sophos Connect o SSL VPN: ¿qué solución Remote Access encaja?.

¿Qué artículo encaja?

Según la tarea, tiene sentido empezar por otro artículo:

Esta separación es importante porque Sophos Connect toca varias cosas: configuración IPsec, configuración SSL VPN, VPN Portal, provisioning, autenticación, versión del cliente y reglas firewall.

Requisitos

• Sophos Firewall con una versión SFOS compatible
• acceso de administrador a la interfaz WebAdmin
• usuarios o grupos definidos para Remote Access
• rango libre de direcciones IP para clientes VPN
• servidores DNS internos si deben resolverse nombres internos
• concepto MFA para Remote Access
• redes y servicios de destino aclarados, que deben ser accesibles por VPN
• procedimiento claro para distribución de perfiles, cambios de perfil y actualizaciones de cliente

Si la firewall se va a actualizar a SFOS 22.0 MR1 o posterior, primero hay que comprobar si aún existe Legacy Remote Access IPsec. Esta configuración antigua puede bloquear la actualización. El proceso se describe en Migrar Legacy Remote Access IPsec antes de SFOS 22 MR1.

En versiones SFOS actuales, la configuración de IPsec Remote Access está en Remote access VPN > IPsec. En interfaces antiguas o guías anteriores todavía se encuentran rutas como VPN > Sophos Connect Client. Por eso, en capturas existentes y entornos de cliente antiguos la denominación puede variar.

Planificar antes de configurar

Antes de activar la función, conviene documentar brevemente cómo se operará Remote Access más adelante. Esto evita errores típicos como pools IP solapados, reglas firewall demasiado amplias o perfiles que no se redistribuyen tras un cambio.

Preguntas importantes de planificación:

Para fundamentos de MFA, ver Configurar Sophos Firewall MFA. Si Remote Access se ejecutará más adelante mediante Microsoft Entra ID SSO, RADIUS o AD, también debe probarse la cadena de autenticación por separado.

Tipos de perfil y distribución

Antes de configurar, debe estar claro qué archivo terminará en qué cliente. Esto evita muchos casos de soporte.

Para nuevos despliegues Sophos Connect IPsec, .scx suele ser el mejor estándar porque contiene los ajustes avanzados de la firewall. .tgb solo debería usarse de forma consciente si un cliente de terceros o un proceso antiguo lo requiere.

El provisioning puede simplificar la distribución, pero aumenta la dependencia del VPN Portal. Si los usuarios deben utilizar el archivo de provisioning desde Internet, el VPN Portal debe ser accesible desde la zona necesaria. Esto debe endurecerse conscientemente en Administration > Device access y Local Service ACL, porque un portal accesible desde WAN crea superficie de ataque adicional. Para el endurecimiento, ver Device Access y Local Service ACL en Sophos Firewall.

Activar Sophos Connect

En la interfaz WebAdmin, abrir Remote access VPN > IPsec. En interfaces antiguas, la ruta todavía puede ser VPN > Sophos Connect Client. La representación exacta puede variar ligeramente según la versión SFOS, pero las decisiones básicas siguen siendo similares.

1. Activar Connect Client

Activar IPsec Remote Access. Después configurar el resto de ajustes y no desplegar de inmediato en producción.

2. Elegir la interfaz externa

Como interface se elige normalmente la interfaz WAN por la que las conexiones Remote Access llegan a la firewall. Con varios enlaces WAN, hay que decidir conscientemente qué enlace es estable para VPN, está documentado y es accesible desde Internet.

Comprobar:

• IP pública o DynDNS/FQDN correcto disponible
• redirecciones de puertos y routers anteriores coherentes
• comportamiento de WAN failover conocido
• Device Access y ACLs de servicio locales permiten solo servicios necesarios
• VPN Portal accesible solo donde realmente se necesita para descarga o provisioning

Remote Access es un punto de entrada accesible públicamente. Por tanto, la mera función no basta; acceso, MFA y logging deben planificarse también.

Para endurecer los servicios firewall accesibles, ver Device Access y Local Service ACL en Sophos Firewall.

3. Elegir autenticación

Para IPsec Remote Access hay distintos modelos de autenticación disponibles según la versión SFOS y la configuración. Preshared Key y certificado suelen ser opciones relevantes.

Clasificación práctica:

• Preshared Key se configura rápido, pero debe ser fuerte, estar protegida y rotarse ante sospecha.
• Certificado es más limpio para entornos controlados, pero requiere gestión de certificados y procesos claros.
• MFA no sustituye ni a PSK ni a certificado, sino que protege adicionalmente el inicio de sesión del usuario.

Si la Preshared Key se distribuyó en varios perfiles, cambiarla es más costoso operativamente. Por eso la clave no debe tratarse como un valor desechable.

En certificados, también debe comprobarse si tipo de certificado, vigencia, claves privadas y cliente de destino encajan. Para IPsec Remote Access son especialmente relevantes los certificados RSA. Los cambios de certificado siempre son también un tema de perfil y rollout.

4. Comprobar Local ID y Remote ID

Local ID y Remote ID son opcionales, pero pueden ser importantes con varios túneles o pares especiales. Si se configuran, deben encajar con el perfil usado y la configuración del cliente.

Valores típicos:

• nombre DNS
• dirección IP
• email
• certificado

En setups sencillos estos campos suelen quedar vacíos. Si más tarde aparecen errores como no IKE config found o problemas de proposal/ID, esta área debe incluirse en la revisión. Para un análisis más profundo, Troubleshooting de Sophos Firewall IPsec VPN es el artículo de continuación adecuado.

5. Asignar usuarios y grupos

Seleccionar solo los usuarios o grupos que realmente necesitan Remote Access. En entornos productivos, un grupo VPN dedicado suele ser mejor que un grupo estándar amplio.

Comprobar:

• El grupo contiene solo usuarios autorizados.
• Los usuarios que han salido se eliminan.
• MFA está activo y probado para estos usuarios.
• Helpdesk sabe cómo bloquear, desbloquear o reprovisionar usuarios.

Los guest users no pertenecen a Remote Access. Para entornos productivos, un grupo VPN dedicado es mejor que un grupo estándar amplio del servicio de directorio.

Configurar datos del cliente

6. Asignar nombres

El nombre de la conexión debe ser comprensible para usuarios y soporte. Nombres como homeoffice, remote-access-ipsec o el nombre de una sede son más útiles que abreviaturas internas.

Si se distribuyen varios perfiles, la nomenclatura debe mantenerse coherente. Esto reduce confusiones en Sophos Connect Client.

7. Definir pool IP

La firewall asigna a los clientes VPN una dirección del pool definido. Este rango no debe solaparse con redes internas, otros pools VPN, redes Site-to-Site o rangos domésticos habituales.

Buenas prácticas:

• rango de direcciones separado solo para Remote Access
• tamaño suficiente para usuarios simultáneos
• sin solapamiento con 192.168.0.0/24, 192.168.1.0/24 o rangos domésticos frecuentes si se puede evitar
• documentación clara en IPAM o documentación de red

Si el pool se cambia más adelante, perfiles y pruebas deben revisarse de nuevo.

Para IPsec Remote Access, el pool debe planificarse al menos claramente como subred propia. Además, no debe solaparse con otros pools Remote Access como SSL VPN, L2TP o PPTP.

8. Introducir servidores DNS

Si los usuarios deben acceder a sistemas internos por nombre, deben distribuirse servidores DNS adecuados y, si procede, dominios de búsqueda. En muchos entornos se trata de un Domain Controller interno o un servidor DNS dedicado.

Resolvers externos como Cloudflare, Google, Quad9 u OpenDNS no resuelven zonas internas. Estos resolvers solo tienen sentido si no se necesitan nombres internos por el túnel VPN o si DNS se resuelve conscientemente de otra forma.

Ejemplos de resolvers externos:

• Cloudflare: 1.1.1.1 y 1.0.0.1
• Google: 8.8.8.8 y 8.8.4.4
• Quad9: 9.9.9.9 y 149.112.112.112
• OpenDNS: 208.67.222.222 y 208.67.220.220

Para Remote Access productivo, suele ser más importante que los FQDN internos funcionen de forma fiable. Si DNS no se planifica limpiamente, el túnel parece “conectado” para los usuarios aunque las aplicaciones no sean utilizables.

Comprobar ajustes avanzados

9. Definir Session Timeout

Un Session Timeout evita que conexiones VPN no utilizadas permanezcan abiertas indefinidamente. Valores demasiado agresivos pueden generar casos de soporte, porque los usuarios deben reconectar tras interrupciones breves.

Tiene sentido un valor acorde al modelo de trabajo:

• timeouts cortos para accesos administrativos esporádicos
• timeouts más largos para sesiones de trabajo estables
• comunicación clara si los usuarios deben reconectar tras inactividad

Si se usa OTP/MFA, también debe probarse el efecto en los reconnects.

Si la firewall desconecta un cliente idle, Sophos Connect Client puede restablecer la conexión en segundo plano. Si eso no funciona, el usuario debe desconectar conscientemente la conexión en el cliente y volver a conectarla. Este comportamiento debe conocerse en el proceso de helpdesk.

10. Configurar conscientemente Advanced settings

Los ajustes avanzados determinan cómo se comporta el cliente en el día a día. En IPsec Remote Access se incluyen en el archivo .scx, no en el archivo .tgb.

Puntos importantes:

Con Full Tunnel mediante Use as default gateway se necesita además una regla firewall de VPN a WAN y un diseño consciente de NAT/Security Policy. Con Split Tunnel, los recursos internos permitidos deben documentarse limpiamente.

Si Prompt users for 2FA token está activo, el uso suele ser más claro para los usuarios. Al mismo tiempo, hay que comprobar si las herramientas o automatizaciones utilizadas funcionan con este ajuste.

11. Guardar y exportar configuración

Después de guardar se exporta la configuración de conexión. Según el cliente y la versión SFOS, pueden ser relevantes archivos .scx, .tgb o de provisioning. El archivo no debe almacenarse de forma abierta ni entregarse a personas no autorizadas.

Tras cambios en grupo de usuarios, pool, DNS, perfil, gateway, puerto, certificado o Advanced Settings, los clientes afectados deben recibir la configuración actualizada. Los perfiles antiguos son una causa frecuente de problemas VPN difíciles de entender.

Si se usa provisioning, también hay que comprobar si el cliente recarga los cambios automáticamente o si los usuarios deben actualizar la policy en Sophos Connect Client o iniciar sesión de nuevo. Cambios en puerto SSL VPN, gateway, certificado de servidor o protocolo son casos típicos en los que puede ser necesario un nuevo login o un paso de actualización consciente.

Configurar reglas firewall

Sophos Connect solo establece el túnel. El acceso a sistemas internos sigue controlándose mediante reglas firewall. Sin reglas adecuadas, la conexión puede estar en verde, pero no funcionar ningún acceso productivo.

Para el acceso de clientes VPN a sistemas internos se suele crear una regla de VPN a LAN o a una zona de destino específica.

• Source Zone: VPN
• Destination Zone: LAN

Mejor que una autorización amplia a toda la LAN suele ser una regla a las redes o servicios realmente necesarios. El logging debe activarse durante la fase de introducción para que los errores sean visibles en Log Viewer.

Si el cliente trabaja como Full Tunnel y el tráfico de Internet también debe pasar por la firewall, se necesita además una regla de VPN a WAN y un diseño consciente de NAT/Security Policy.

• Source Zone: VPN
• Destination Zone: WAN

Para buscar errores en reglas, Probar reglas firewall con Log Viewer, Policy Test y Packet Capture resulta útil.

Las reglas firewall no solo deben “funcionar”, sino ser comprobables. Para la fase de introducción es útil el logging en las reglas Remote Access. Después puede decidirse qué reglas se registran de forma permanente y qué eventos se envían adicionalmente a Sophos Central o Syslog.

Probar después del rollout

Un estado verde de Sophos Connect no basta como prueba de aceptación. Como mínimo, estos puntos deben comprobarse con un usuario de prueba:

• El cliente importa la configuración sin errores.
• El inicio de sesión funciona con contraseña y MFA.
• El cliente recibe una dirección del pool VPN esperado.
• Los nombres DNS internos se resuelven correctamente.
• Los sistemas internos centrales son accesibles.
• Log Viewer muestra la regla firewall esperada.
• Split Tunnel o Full Tunnel se comportan como está previsto.
• El reconnect tras un cambio de red funciona.
• No se reutilizaron perfiles antiguos.
• Con Full Tunnel, el acceso a Internet a través de la firewall funciona como está previsto.
• Con Split Tunnel, los destinos no permitidos siguen bloqueados.
• Log Viewer muestra hits en las reglas esperadas.
• Con provisioning, los cambios de perfil se actualizan de forma trazable.

Después pueden utilizarse las guías de instalación para Windows y macOS.

Checklist de operación

Tras el rollout técnico, la operación no debe quedar abierta:

• Grupo VPN responsable documentado.
• El proceso de baja elimina usuarios de grupos Remote Access.
• El proceso de reset MFA es conocido.
• Versión de perfil o fecha de cambio documentada.
• Helpdesk sabe qué perfiles son actuales.
• Log Viewer y logs de servicio relevantes son conocidos.
• Cambios en pool IP, DNS, gateway, certificado y Advanced Settings disparan una revisión de perfil.
• Antes de upgrades SFOS se comprueban Legacy Remote Access IPsec y perfiles de cliente.

Troubleshooting

La conexión se establece, pero no fluye tráfico

La causa a menudo no está en el túnel, sino en reglas firewall, NAT, routing, DNS o el camino de retorno. Primero comprobar en Log Viewer si el tráfico desde la zona VPN alcanza la regla esperada. Después acotar con Packet Capture o Policy Test.

El usuario no puede iniciar sesión

Comprobar grupo de usuarios, servidor de autenticación, MFA, usuario bloqueado y estado de contraseña. Si intervienen AD, RADIUS o Microsoft Entra ID SSO, la autenticación debe probarse separada del VPN.

El cliente usa una configuración antigua

Tras cambios en pool IP, DNS, grupo de usuarios, perfil, gateway, certificado o Advanced Settings, la configuración debe redistribuirse o reimportarse. Archivos antiguos .tgb, .scx, .ovpn o de provisioning no deben seguir circulando en paralelo.

El provisioning no funciona

Primero comprobar si el VPN Portal es accesible desde la zona necesaria y si Device Access se configuró conscientemente. Después comprobar valor gateway, puerto del portal, certificado, login de usuario, MFA y, con Entra SSO, la asignación en Authentication > Services.

SSO funciona solo parcialmente

Con Microsoft Entra ID SSO, VPN Portal, IPsec y SSL VPN deben corresponder al servidor Entra ID correcto según el workflow. Con provisioning, el valor gateway debe coincidir con la Redirect URI de la configuración Entra. Si solo se ven afectados usuarios concretos, comprobar además UPN, dirección de email, mapping de grupos y grupos de usuarios importados.

La conexión está activa, pero las transferencias grandes se bloquean

Si login, DNS y accesos pequeños funcionan, pero transferencias de archivos grandes o ciertas aplicaciones se bloquean, debe revisarse MTU/MSS. El patrón suele encajar con fragmentación, PPPoE, conexiones tunelizadas o una ruta asimétrica. El procedimiento está en Comprobar MTU y MSS en Sophos Firewall para problemas VPN.

IPsec se corta en redes externas

IPsec puede bloquearse en hoteles, Wi-Fi de invitados, redes móviles o redes corporativas con filtros estrictos. En esos casos debe comprobarse si SSL VPN Remote Access, ZTNA u otro diseño de Remote Access encaja mejor.

Full Tunnel no tiene acceso a Internet

Si Use as default gateway está activo, el tráfico de VPN a WAN debe permitirse y tratarse con NAT adecuado. Además, Web Protection, Application Control, DNS y logging deben planificarse conscientemente igual que en otras redes cliente.

FAQ