Ir al contenido
Avanet

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

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

Desde SFOS 20.0 MR1, Sophos utiliza un componente OpenVPN más reciente. Los túneles SSL Site-to-Site de SFOS 20.0 MR1 o posterior no se conectan con SFOS 18.5 o anterior ni con UTM 9. En una combinación de este tipo, deben actualizarse ambos Sophos Firewall o utilizarse IPsec o un túnel RED.

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 y haberse importado con su clave privada y la cadena de certificados completa. 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.

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:

  1. Abrir Site-to-site VPN > SSL VPN.
  2. En la sección Server, seleccionar Add.
  3. Introducir HQ-to-Branch como nombre.
  4. En Local networks, seleccionar HQ-LAN.
  5. En Remote networks, seleccionar Branch-LAN.
  6. 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.
  7. 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.

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 y se define una contraseña temporal robusta. 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ú:

  1. Abrir Site-to-site VPN > SSL VPN.
  2. En la sección Client, seleccionar Add.
  3. Introducir Branch-to-HQ como nombre.
  4. En Configuration file, seleccionar el archivo .apc exportado.
  5. Si la exportación está cifrada, introducir la contraseña.
  6. Activar Use HTTP proxy server solo si la sucursal accede realmente al servidor mediante un proxy HTTP explícito.
  7. 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.
  8. Guardar con Save y activar la conexión.

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.

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.

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.

  1. Comprobar en ambos firewalls que el estado aparece en verde y que los contadores de bytes aumentan.
  2. Probar primero el destino por dirección IP y después por hostname.
  3. Abrir un servicio realmente permitido, como HTTPS o RDP.
  4. En Log Viewer, comprobar la Firewall Rule ID esperada y que las direcciones de origen y destino no han cambiado.
  5. Probar un servicio o destino no permitido y confirmar el drop.
  6. Probar por separado la dirección inversa si debe estar permitida.
  7. 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: Los FQDN hosts y grupos se admiten como redes locales y remotas. Después de un cambio DNS, desconectar y volver a conectar el túnel de forma controlada y comprobar la ruta y el tráfico de aplicaciones hacia la nueva IP resuelta. Un fallo de resolución es, en primer lugar, un problema de tráfico o routing, no automáticamente un problema al establecer el 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.
  • Un lado ejecuta SFOS 18.5 o UTM 9: No continuar buscando el problema en el puerto o el certificado. Esta combinación es incompatible con un peer actual; actualizar ambos lados o utilizar 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.