Configurar una VPN SSL Site-to-Site en Sophos Firewall

Una VPN SSL Site-to-Site conecta las redes internas de dos Sophos Firewall mediante un túnel cifrado. A diferencia de IPsec, ambos lados tienen un rol fijo: el firewall cliente siempre inicia la conexión y el firewall servidor la acepta.

Esta opción resulta especialmente útil cuando una sucursal tiene una dirección IP pública dinámica o cuando IPsec encuentra dificultades en una red situada por delante. La sede central con dirección estática o FQDN estable actúa como servidor y la sucursal como cliente. Para redes en crecimiento, routing dinámico, redundancia o un peer de terceros, IPsec route-based suele ser más flexible; en una conexión pequeña entre dos Sophos Firewall, SSL Site-to-Site puede ser más sencillo.

Esta guía utiliza un ejemplo concreto:

Sede central, servidor: vpn.example.com, red local 10.10.0.0/24
Sucursal, cliente: IP pública dinámica, red local 10.20.0.0/24
Conexión: HQ-to-Branch
Puerto SSL VPN: 8443

vpn.example.com, los nombres de los objetos y ambas redes son marcadores de posición y deben sustituirse por los valores del entorno real. 8443 es el puerto predeterminado; solo se mantiene si la asignación de puertos y el diseño de seguridad lo permiten.

El procedimiento resumido es el siguiente: definir roles y redes, comprobar los ajustes globales de SSL VPN, permitir SSL VPN en la zona WAN del servidor, crear la conexión del servidor, exportar el archivo .apc, importarlo en el firewall cliente y, por último, comprobar rutas, reglas y tráfico real de aplicaciones.

⚠️ Los ajustes globales de SSL VPN también se utilizan para Remote Access SSL VPN. Por tanto, no se deben cambiar el puerto, el protocolo, el certificado, el rango de direcciones ni los ajustes criptográficos solo para este túnel. Primero hay que evaluar el efecto sobre las conexiones y los perfiles de usuario existentes.

Planificar roles, redes y acceso público

El firewall servidor debería ser el appliance más estable y, si los modelos son diferentes, el más potente. Si solo un lado dispone de una dirección IP pública estática, conviene que ese lado asuma el rol de servidor. El cliente puede estar detrás de NAT o utilizar una conexión con dirección dinámica, siempre que pueda alcanzar el servidor.

Antes de configurar, deben estar definidos los siguientes puntos:

dirección IP pública o FQDN del firewall servidor;
protocolo y puerto de SSL VPN;
red local de la sede central y red local de la sucursal;
rangos de direcciones únicos y sin solapamientos;
servicios necesarios y direcciones de conexión permitidas;
ruta de retorno en ambos lados;
acceso administrativo alternativo para el cambio;
versiones actuales de SFOS en ambos firewalls.

Si las redes se solapan, esta configuración estándar no es suficiente. En ese caso se necesita un diseño consciente de traducción y routing; en la práctica, IPsec con NAT planificado suele ser más adecuado.

Comprobar la compatibilidad antes del cambio

Los pasos de configuración se han comparado con los textos de ayuda conservados de SFOS 22 y 23, sin probarlos en un firewall. Ambas versiones de la ayuda mantienen la advertencia de migración para SFOS 20.0 MR1: SFOS 20.0 MR1 y las versiones posteriores no establecen conexiones SSL Site-to-Site con SFOS 18.5 o anterior ni con UTM 9. Esta advertencia no es una matriz completa de compatibilidad para todas las builds posteriores. Antes de actualizar, comprobar la combinación concreta; si la conexión está afectada, llevar ambos Sophos Firewall a versiones compatibles y con soporte o planificar IPsec o un túnel RED. UTM 9 no se puede actualizar simplemente aplicando una actualización de SFOS.

Comprobar los ajustes globales de SSL VPN

Los ajustes compartidos se encuentran en el futuro firewall servidor en:

Remote access VPN > SSL VPN > SSL VPN global settings

Para el ejemplo, se comprueban especialmente los siguientes valores:

Protocol: UDP suele ser la opción inicial más eficiente; TCP puede ayudar en redes restrictivas.
SSL server certificate: debe ser válido. Los certificados externos se importan con su clave privada en Certificates > Certificates; si hay una cadena externa, también se cargan las CA intermedia y raíz. Si se utiliza un FQDN público, el certificado debería coincidir con ese nombre.
Override hostname: vpn.example.com si los clientes deben utilizar exactamente este FQDN.
Port: 8443, salvo que se haya planificado deliberadamente otro diseño de puertos.
Assign IPv4 addresses: no debe solaparse con ninguna de las dos redes de las sedes ni con otros pools VPN.
Cryptographic settings: no modificar los valores existentes sin realizar pruebas de compatibilidad y funcionamiento.

Si el firewall servidor está detrás de un router situado por delante, el router debe reenviar al firewall el puerto y el protocolo elegidos. En ese caso, el FQDN apunta a la dirección pública del router. WAF y SSL VPN no deben utilizar la misma combinación de IP WAN, puerto y protocolo.

Si más adelante cambian Port, Protocol, SSL server certificate u Override hostname, hay que volver a descargar la configuración del servidor e importarla de nuevo en el firewall cliente. La exportación .apc existente no contiene los valores nuevos.

SSL VPN Remote Access en Sophos Firewall explica todas las dependencias de los ajustes globales. Los cambios deben planificarse teniendo en cuenta los perfiles de usuario existentes, los rangos de direcciones, DNS y los servicios accesibles públicamente.

Permitir SSL VPN para la zona WAN del servidor

En el firewall servidor se permite el servicio SSL VPN local para la zona de entrada:

Administration > Device access

Si el firewall cliente tiene una dirección pública dinámica o que no se puede limitar de forma útil, se activa SSL VPN para WAN en VPN services. Esto solo permite establecer el túnel hacia el firewall; no sustituye una regla de firewall para el tráfico de aplicaciones entre las sedes.

Este permiso solo es necesario en el firewall servidor. El firewall cliente establece el túnel de salida, por lo que no se debe activar preventivamente SSL VPN para WAN en Device Access en ese lado.

Si las redes públicas de origen del lado cliente son estables y conocidas, SSL VPN permanece desactivado en la matriz WAN. En su lugar, se crea una Local Service ACL Exception específica con acción Accept, Source zone WAN, las Source Networks/Hosts conocidas, la dirección WAN del servidor como Destination host y SSL VPN como Service. Una excepción Accept no limita un permiso ya activo en la matriz WAN. Configurar Device Access de forma segura en Sophos Firewall explica la planificación.

Crear la conexión de servidor en la sede central

Primero se crean las dos redes como objetos IP host en el firewall servidor:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

A continuación se crea la conexión de servidor:

Abrir Site-to-site VPN > SSL VPN.
En la sección Server, seleccionar Add.
Introducir HQ-to-Branch como nombre.
En Local networks, seleccionar HQ-LAN.
En Remote networks, seleccionar Branch-LAN.
Activar Use static virtual IP address solo cuando exista una necesidad justificada y elegir una dirección libre fuera de los rangos SSL VPN estáticos y dinámicos globales que no entre en conflicto con ninguna otra dirección IP privada.
Guardar con Save.

Desde la perspectiva del firewall servidor, Local networks son las redes de la sede central. Remote networks se encuentran detrás del firewall cliente. Esta perspectiva es importante: si se intercambian los objetos, el túnel puede aparecer en verde aunque las rutas y las reglas no coincidan con la conexión prevista.

Sin Use static virtual IP address, el firewall asigna automáticamente al cliente una dirección del rango de concesiones de SSL VPN global settings. Para una asignación fija, introducir la dirección elegida en Static peer IP; es la dirección virtual del túnel del cliente, no la LAN de la sucursal.

Los textos de ayuda indican un máximo de 1024 hosts para cada uno de los campos Local networks y Remote networks. No explican aquí cómo se cuentan los objetos de red frente a las direcciones IP individuales. Esto no permite deducir un límite general de tamaño de subred ni justificar la división de las mismas redes como solución. Si la configuración se acerca a este límite, comprobar la selección de objetos y el guardado en la build concreta y aclarar el método de cómputo antes del cambio en producción.

Exportar la configuración del servidor de forma segura

En la lista de servidores, se selecciona Download para HQ-to-Branch. La exportación utiliza el formato .apc y contiene los datos de conexión para el firewall cliente.

Para transferirla de forma segura, se activa Encrypt configuration file, se introduce y confirma una contraseña temporal robusta y después se pulsa Download. El archivo y la contraseña se envían por canales separados. El archivo .apc no debe incluirse en un ticket público, un chat sin protección ni un directorio de descargas permanente.

Importar la configuración en el firewall cliente

La configuración se importa en el firewall de la sucursal desde la misma ruta de menú:

Abrir Site-to-site VPN > SSL VPN.
En la sección Client, seleccionar Add.
Introducir Branch-to-HQ como nombre.
Pulsar Choose file y seleccionar el archivo .apc exportado.
Si la exportación está cifrada, introducir la contraseña.
Activar Use HTTP proxy server solo si la sucursal accede realmente al servidor mediante un proxy HTTP explícito. Introducir entonces el servidor proxy aprobado y su puerto de escucha real. Activar Proxy requires authentication solo si ese proxy exige autenticación; utilizar el nombre de usuario de proxy previsto y su contraseña correspondiente. No asumir un puerto ni modificar los ajustes globales de proxy como solución alternativa.
Configurar Override peer hostname solo si la dirección del servidor incluida en la exportación no se puede enrutar o resolver desde la red cliente. En este ejemplo, el campo queda vacío porque vpn.example.com ya se exporta mediante el ajuste global.
Guardar con Save y activar la conexión.

La contraseña de importación del archivo .apc cifrado descifra el archivo; no es la contraseña del proxy. Override peer hostname identifica el servidor remoto, no el proxy. Mantener ambas contraseñas confidenciales y fuera de capturas de pantalla, logs y tickets. Después de guardar, volver a abrir la entrada de cliente y comparar el servidor proxy, el puerto, la opción de autenticación y el peer con los valores aprobados, sin revelar secretos; después comprobar el túnel y el tráfico de aplicaciones como se describe más abajo.

Para la automatización mediante XML API, los ejemplos Add/Edit conservados de SFOS 22 y 23 muestran ProxyServer, ProxyPort y ProxyAuthentication solo cuando HttpProxyServer = Enable, y Username y Password solo con la autenticación de proxy activada. FilePassword corresponde a ServerConfigurationFile; PeerHost/HostName constituye una rama independiente. La tabla marca el servidor proxy y el puerto como obligatorios aunque el ejemplo los muestra de forma condicional, e indica un valor predeterminado OFF para la autenticación de proxy, pero los valores permitidos Disable/Enable. No deducir de ello un serializador ni una solicitud válida: si no está clara la inclusión de campos o la representación de valores, no ejecutar la automatización, utilizar la vía de interfaz admitida y aclarar el esquema de la build concreta con Sophos Support.

El estado cambia a verde cuando el firewall cliente alcanza el servidor y establece el túnel. Un estado verde solo confirma el propio túnel, no el acceso a servidores, DNS o aplicaciones.

Comprobar rutas y reglas de firewall

Las redes seleccionadas en Local networks y Remote networks se utilizan para el routing del túnel. Pertenecen a la clase de routing static y deben encajar con el resto de la configuración de routing. De lo contrario, una ruta estática, SD-WAN o VPN más específica puede producir un recorrido distinto del esperado. Comprender y ajustar la prioridad de routing en Sophos Firewall explica el orden.

Las reglas de firewall para el tráfico de aplicaciones se crean de forma consciente en ambos firewalls o se comprueban reglas existentes adecuadas. En este ejemplo, donde la sucursal inicia conexiones hacia la sede central, se necesita como mínimo lo siguiente:

en el firewall de la sucursal, una regla restrictiva de LAN a VPN para Branch-LAN hacia los destinos necesarios en HQ-LAN;
en el firewall servidor, una regla correspondiente de VPN a LAN para Branch-LAN hacia esos destinos;
únicamente los servicios necesarios, por ejemplo DNS, RDP y HTTPS;
Log firewall traffic durante las pruebas de aceptación;
ninguna regla SNAT o MASQ que modifique el tráfico entre sedes sin una razón técnica válida.

Estas dos reglas cubren la nueva conexión iniciada por la sucursal y su tráfico de retorno stateful; para ese flujo no hacen falta otras dos reglas simétricas. No se deben copiar las zonas de una guía de IPsec. En Log Viewer o Packet Capture, el flujo de prueba debe ir de LAN al túnel SSL VPN en el firewall de la sucursal y del túnel SSL VPN a LAN en el firewall servidor. Si la zona, Out interface o Rule ID observada es distinta, primero se corrigen el routing y la coincidencia de reglas en lugar de ampliar la regla a Any.

Si la sede central también debe iniciar nuevas conexiones hacia la sucursal, las direcciones inversas se permiten por separado. Una regla Any amplia no es un diseño de seguridad terminado. Probar una regla de firewall explica cómo se combinan la posición de la regla, Rule ID y Packet Capture.

Planificar el failover y el rollback

Un túnel SSL Site-to-Site no forma parte de un grupo de failover de IPsec. El archivo .apc proporciona al cliente la conexión de servidor exportada. Un FQDN o varias rutas WAN no aportan por sí solos una redundancia sin interrupciones: la sesión existente se corta al cambiar de WAN y el cliente debe volver a alcanzar el servidor configurado por la nueva ruta. Para un failover automático entre varias conexiones definidas, se debe utilizar IPsec route-based.

Para una prueba sencilla de failover WAN, el FQDN activo del servidor debe seguir resolviéndose y siendo accesible por la ruta de respaldo; el NAT y los reenvíos de puertos situados por delante deben ofrecer allí el mismo protocolo y puerto SSL VPN. Después se comprueba que el cliente vuelve a conectarse y que el tráfico de aplicaciones permitido y bloqueado sigue tratándose según el diseño. Un túnel verde tampoco basta aquí como criterio de aceptación.

Antes del cambio se registran los valores globales anteriores de SSL VPN, los permisos de Device Access, las entradas de servidor y cliente, las reglas y el último archivo .apc funcional. Para hacer rollback, primero se desactivan las reglas y conexiones nuevas, se restauran los valores globales y los ajustes anteriores de Device Access y se importa el archivo .apc anterior en el cliente. Los objetos nuevos solo se eliminan cuando vuelvan a funcionar el túnel, la prueba positiva y la prueba negativa.

Antes de una eliminación autorizada en Site-to-site VPN > SSL VPN, seleccionar el nombre exacto de la conexión guardada, el firewall y el rol Client o Server, comprobar los peers y reglas de producción dependientes y conservar la exportación funcional y la vía de recuperación. Las páginas XML Delete conservadas de SFOS 22 y 23 marcan Name como opcional, pero no contienen un ejemplo de solicitud Delete. Esto no autoriza una eliminación sin objetivo o de amplio alcance ni permite intercambiar las operaciones de cliente y servidor. Si la identidad o el esquema no están claros, no ejecutar una eliminación XML: mantener la vía de interfaz admitida y obtener una aclaración específica de la build. Tras la eliminación, revisar la respuesta específica de la operación y el estado real de la entrada exacta de destino; volver a comprobar las demás conexiones de producción y su tráfico permitido y bloqueado.

Validar el túnel y el tráfico de aplicaciones

La prueba comienza con un cliente concreto y un destino concreto. En el ejemplo, un dispositivo de 10.20.0.0/24 accede a un servidor permitido en 10.10.0.0/24.

Comprobar en ambos firewalls que el estado aparece en verde y que los contadores de bytes aumentan.
Probar primero el destino por dirección IP y después por hostname.
Abrir un servicio realmente permitido, como HTTPS o RDP.
En Log Viewer, comprobar la Firewall Rule ID esperada y que las direcciones de origen y destino no han cambiado.
Probar un servicio o destino no permitido y confirmar el drop.
Probar por separado la dirección inversa si debe estar permitida.
Tras un reinicio o cambio de WAN, comprobar que el firewall cliente vuelve a establecer el túnel.

Un ping correcto no es suficiente. No demuestra ni DNS ni el servicio de aplicación necesario. Para un destino interno, la regla de firewall, la ruta de retorno y el firewall del endpoint deben permitir la prueba; Device Access solo es relevante cuando se hace ping a una dirección de la propia Sophos Firewall.

Leer los logs cuando se produce un error

Los logs de SSL VPN se abren directamente en Site-to-site VPN > SSL VPN > Logs. Para una comprobación más profunda, se establece una conexión SSH, se selecciona 5. Device Management > 3. Advanced Shell y se lee el log actual del servicio:

tail -n 200 /log/sslvpn.log

El comando no modifica la configuración. Se documentan juntos la hora, el nombre de la conexión y el lado servidor/cliente. Según el número de procesos, pueden existir otros archivos de estado OpenVPN como openvpn-status0.log, openvpn-status1.log y archivos adicionales; logs de servicio de Sophos Firewall explica la asignación.

Acotar los errores habituales

El túnel permanece en rojo: Comprobar el FQDN público, DNS, el reenvío de puertos, el protocolo, el certificado y SSL VPN en Device Access para la zona WAN del servidor. Después, leer sslvpn.log para la misma hora.
El túnel deja de establecerse después de un cambio global: Volver a exportar la configuración del servidor e importarla en el cliente. En especial, el puerto, el protocolo, el certificado y Override hostname dependen de la exportación.
El túnel está en verde, pero no fluye tráfico: Comprobar el routing del túnel, la prioridad de routing, las reglas de ambos firewalls, Rule ID, la ruta de retorno, NAT y el firewall del endpoint. Después, seguir un único flujo mediante Packet Capture.
Solo fallan los hostnames: Probar el acceso por IP, comprobar los servidores DNS y el dominio de búsqueda, y asegurarse de que el servidor DNS sea accesible y esté permitido a través del túnel.
Un objeto FQDN host sigue apuntando a la dirección antigua: Desde SFOS 20.0, los hosts y grupos FQDN pueden utilizarse como Local networks y Remote networks. Después de un cambio DNS, comparar primero la dirección resuelta en el firewall con la IP esperada y comprobar los objetos seleccionados, la ruta y un flujo de tráfico de aplicaciones. La evidencia disponible aquí no confirma que desconectar y volver a conectar un túnel SSL Site-to-Site actualice estas direcciones; no interrumpir un túnel operativo solo para forzar una actualización DNS. Si la ruta sigue obsoleta, registrar la build, la resolución, la ruta y los logs para continuar la investigación. No confundir el FQDN de un objeto de destino con el FQDN del servidor: si este último no se resuelve, puede impedir el establecimiento del túnel.
El cliente solo puede alcanzar el servidor mediante un proxy: Utilizar Use HTTP proxy server con los valores de proxy aprobados; no introducir datos de proxy aleatorios como solución genérica.
Fallo tras una migración, con un peer en SFOS 18.5 o anterior o UTM 9: Antes de cambiar el puerto o el certificado, comprobar la combinación de versiones según la advertencia anterior de SFOS 20.0 MR1. Una conexión afectada necesita peers compatibles o una alternativa planificada con IPsec o RED.

Si el túnel sigue sin estar claro después de una prueba controlada, se recopilan la versión y la build de SFOS de ambos firewalls, la hora con zona horaria, el nombre de la conexión, sslvpn.log, las Rule IDs y un Packet Capture breve. Solo después deben modificarse de nuevo las reglas, las redes o los ajustes globales de SSL VPN.