Configurar VPN IPsec Site-to-Site Sophos Firewall

Una VPN IPsec Site-to-Site conecta dos sedes, o una Sophos Firewall con un firewall de terceros, mediante un túnel cifrado. En la práctica, un túnel de este tipo rara vez falla por una sola opción en la interfaz. Con más frecuencia, las causas son redes poco claras, perfiles IPsec diferentes, reglas de firewall ausentes, casos especiales de NAT o una ruta de retorno olvidada en uno de los lados.

Este artículo explica cómo crear correctamente un túnel IPsec Site-to-Site en Sophos Firewall. El foco está en planificación, implementación y prueba de aceptación. Si un túnel existente ya aparece en verde pero no pasa tráfico, Sophos Firewall IPsec VPN Troubleshooting es el mejor artículo complementario.

Cuándo encaja este artículo

Este artículo encaja con conexiones clásicas entre sedes, por ejemplo:

• Sede principal con sucursal
• Sophos Firewall con Sophos Firewall
• Sophos Firewall con firewall de terceros
• Sophos Firewall con cloud gateway si no se usa un asistente cloud específico
• Migración de antiguos túneles policy-based simples a una configuración actual documentada

No se refiere a Remote Access para usuarios individuales. Para eso encajan los artículos Configurar Sophos Connect en Sophos Firewall, Sophos Connect o SSL VPN: ¿qué solución Remote Access encaja? y Migrar IPsec Remote Access legacy antes de SFOS 22 MR1.

IPsec policy-based o route-based

Antes de la configuración hay que decidir si el túnel se construirá como policy-based o route-based. En versiones SFOS actuales, estos términos están separados con más claridad que en guías antiguas, que a veces todavía hablan de Site-to-Site o Tunnel Interface.

Para conexiones pequeñas y estables, policy-based IPsec suele ser lo más rápido de entender. Para redes de sedes más grandes o dinámicas, route-based IPsec suele ser más limpio porque separa mejor routing y negociación VPN. Si intervienen varias redes, SD-WAN, BGP, OSPF o redes cloud, debería revisarse primero route-based IPsec.

Requisitos

Antes de configurar, esta información debería estar documentada:

⚠️ Una VPN Site-to-Site no debería implementarse sin una ruta de retorno documentada. Si el firewall local envía tráfico al túnel pero el extremo remoto no conoce la ruta de vuelta o espera NAT de otra forma, el túnel suele parecer sano aunque las aplicaciones no funcionen.

Planificar antes de configurar

Mantener redes inequívocas

Las redes locales y remotas no deben solaparse involuntariamente. Son especialmente problemáticas redes estándar comunes como 192.168.0.0/24, 192.168.1.0/24 o redes de sucursales reutilizadas. Si las redes se solapan, hace falta un diseño NAT deliberado. Usar simplemente el mismo rango de direcciones en ambos lados y traducirlo después “de alguna manera” genera túneles difíciles de mantener.

Para nuevas sedes, por tanto, merece la pena un concepto limpio de direccionamiento IP. Si VLANs o zonas aún no están modeladas correctamente, ayuda configurar zonas e interfaces de Sophos Firewall.

Alinear el perfil IPsec

Ambos lados deben usar parámetros compatibles en Phase 1 y Phase 2. Esto incluye cifrado, autenticación, DH group, PFS y lifetime. En conexiones con firewalls de terceros, a menudo lo más sencillo es fijar primero por escrito un perfil común y después configurar ambos lados.

Si un túnel no levanta, NO_PROPOSAL_CHOSEN, errores de ID o errores de autenticación son indicios típicos. El análisis estructurado está en Sophos Firewall IPsec VPN Troubleshooting.

No olvidar las reglas de firewall

Un túnel IPsec no concede por sí solo acceso productivo. El tráfico a través del túnel sigue necesitando reglas de firewall adecuadas. En conexiones policy-based suelen ser reglas entre LAN y VPN o entre zonas propias. En diseños route-based depende de a qué zona esté asignada la interfaz XFRM o el camino relevante.

Durante la introducción debería activarse Log firewall traffic en las reglas afectadas. De lo contrario faltará más tarde justo la información sobre qué regla permitió o bloqueó una prueba. El flujo general de comprobación está en probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

Revisar conscientemente las reglas creadas automáticamente

Al crear una conexión IPsec Site-to-Site, la opción Create firewall rule puede ayudar a crear un primer conjunto de reglas. Pero no sustituye una revisión de seguridad. Sophos Firewall crea estas reglas en la parte superior de la lista de reglas de firewall. En versiones SFOS actuales se crean reglas separadas para tráfico entrante y saliente con los prefijos Incoming y Outgoing.

Para la operación es importante:

⚠️ Las reglas de firewall creadas automáticamente son un punto de partida, no un diseño de seguridad terminado. Especialmente en túneles entre sedes hacia redes de servidores, después de la primera prueba conviene reducir servicios, fuentes y destinos.

En IPsec route-based con subredes Any-to-Any hay que trabajar con especial cuidado. Para estos diseños route-based no se pueden crear reglas de firewall automáticas. Con versiones dual IP, las reglas IPv4 e IPv6 deben planificarse por separado. En estos escenarios, reglas de firewall, interfaz XFRM, rutas y pruebas deberían construirse manualmente y de forma deliberada.

Configurar IPsec policy-based

Policy-based IPsec es la variante clásica para conexiones Site-to-Site simples. Las redes locales y remotas se definen directamente en la conexión IPsec.

1. Revisar o crear el perfil IPsec

Menu path:

Profiles > IPsec profiles

Primero comprobar si un perfil existente encaja con el extremo remoto. Si se necesita un perfil propio, debería tener un nombre claro, por ejemplo IPsec_IKEv2_AES256_G14. El nombre debe seguir siendo comprensible más adelante cuando existan varios túneles y extremos remotos.

Como mínimo hay que documentar:

• Versión IKE
• Phase 1 Encryption y Authentication
• DH Group
• Phase 2 Encryption y Authentication
• PFS
• Key lifetime

En firewalls de terceros, el extremo remoto debería confirmar los mismos valores por escrito. Una captura de pantalla por sí sola a menudo no basta, porque algunos campos reciben nombres diferentes según el fabricante.

2. Añadir la conexión IPsec

Menu path:

Site-to-site VPN > IPsec

Crear una nueva conexión IPsec y elegir Policy-based como Connection type. Después definir los datos básicos:

• Nombre del túnel, por ejemplo branch-zurich
• Local gateway o Listening interface
• Remote Gateway como dirección IP o FQDN
• Authentication type: Preshared Key o certificado
• Local ID y Remote ID si son necesarios
• IPsec profile
• Local subnet
• Remote subnet

Para Preshared Keys debería usarse una clave fuerte y única, y documentarla de forma segura. Una clave estándar antigua compartida entre varias sedes es un riesgo operativo innecesario.

3. Activar el túnel

Al guardar puede marcarse Activate on save. En entornos productivos debería hacerse en una ventana de mantenimiento definida, cuando el extremo remoto sea alcanzable y ambos lados puedan revisar logs.

Después de guardar, la lista muestra dos estados relevantes:

• si la conexión está activa
• si el túnel está realmente established

Una entrada activa no es automáticamente un túnel establecido. Con varias redes locales o remotas puede haber además varias Security Associations.

Configurar IPsec route-based

Route-based IPsec separa más claramente negociación VPN y routing. Sophos Firewall crea una interfaz XFRM. Después, rutas estáticas, SD-WAN Routes o routing dinámico deciden qué tráfico pasa por el túnel.

1. Crear la conexión como route-based

Menu path:

Site-to-site VPN > IPsec

En la conexión, elegir Route-based (Tunnel interface). Los parámetros de gateway, autenticación, IDs y perfil IPsec deben seguir coincidiendo con el extremo remoto. Además, hay que entender qué interfaz XFRM se crea después y cómo se enruta.

Sophos muestra la interfaz XFRM generada debajo de la interfaz física utilizada en:

Network > Interfaces

Según el diseño, la interfaz XFRM necesita una dirección IP. Especialmente con diseños Any-to-Any, versión dual IP o escenarios de routing más complejos, el direccionamiento de la interfaz debería planificarse limpiamente.

Si se usa Any-to-Any, el Tunnel Selector ya no decide por sí solo qué tráfico pasa por el túnel. Las rutas y reglas de firewall pasan a ser el control central. Es flexible, pero también propenso a errores: una regla demasiado amplia puede permitir más tráfico del previsto, y una ruta ausente puede mostrar el túnel en verde aunque no fluya tráfico de usuario.

2. Configurar routing

En una VPN route-based, la conexión IPsec por sí sola no basta. Hace falta una ruta hacia la red remota:

• ruta estática hacia la interfaz XFRM
• SD-WAN Route con gateway o perfil adecuado
• ruta dinámica mediante BGP u OSPF si el diseño está preparado para ello

En setups simples, una ruta estática suele ser suficiente. Si se usan varias líneas WAN, comprobaciones SLA o rutas de failover, una SD-WAN Route tiene más sentido. El contexto general sobre SD-WAN, Reply Packets y tráfico generado por el sistema está en comprobar el routing SD-WAN de Sophos Firewall para Reply Packets y System Traffic.

3. Tener en cuenta XFRM y MTU

Las VPN route-based son más propensas a malentendidos sobre routing, MTU y MSS. Si las pruebas pequeñas funcionan pero las transferencias grandes se quedan bloqueadas, no se debería cambiar inmediatamente el perfil IPsec. Primero hay que comprobar MTU, MSS, fragmentación y el camino real. El procedimiento adecuado está en comprobar MTU y MSS en Sophos Firewall para problemas VPN.

Crear reglas de firewall

Tras la configuración IPsec hacen falta reglas para el tráfico productivo. Sin reglas adecuadas, el túnel puede aparecer en verde, pero las aplicaciones no funcionarán.

Menu path:

Rules and policies > Firewall rules

Reglas típicas:

Buenas prácticas:

• Nombre de regla con túnel o sede, por ejemplo LAN_to_Branch_Zurich.
• Definir Source y Destination lo más estrictamente posible.
• Definir Services de forma concreta.
• Activar logging durante introducción y troubleshooting.
• Revisar la posición de la regla.
• Definir funciones de protección conscientemente en lugar de heredarlas por casualidad.

Si el tráfico de Internet de una sucursal debe pasar por la central, además hace falta un concepto NAT y de seguridad deliberado. Es un diseño distinto a una conexión simple entre sedes para redes internas.

Planificar NAT conscientemente

NAT no está prohibido con IPsec, pero debe estar claramente justificado. Casos típicos son redes solapadas, requisitos cloud o terceros que solo aceptan determinadas direcciones de origen.

Menu path:

Rules and policies > NAT rules

Antes de una regla NAT deberían responderse estas preguntas:

• ¿El extremo remoto espera direcciones IP originales o direcciones traducidas?
• ¿Existen redes solapadas?
• ¿NAT se resuelve en la conexión IPsec o mediante reglas NAT separadas?
• ¿Está documentado el sentido de retorno?
• ¿Log Viewer muestra después de NAT la Source y Destination esperadas?

Para casos especiales policy-based con NAT puede ser relevante una ruta IPsec en Sophos Firewall manual. Pero no es un paso estándar para cada túnel.

Device Access y acceso WAN

Para solicitudes IPsec entrantes, el firewall debe poder aceptar tráfico IPsec en la zona WAN adecuada. Esto no se resuelve con una regla normal LAN-to-WAN, sino mediante los servicios locales del firewall.

Menu path:

Administration > Device access

Allí IPsec debe estar permitido para la zona necesaria. Al mismo tiempo conviene revisar si otros servicios locales como WebAdmin, SSH, User Portal o VPN Portal están accesibles de forma demasiado amplia. Para endurecer estos servicios locales, proteger el acceso a Sophos Firewall: configurar correctamente Device Access es el artículo central.

Probar el túnel

Una buena prueba de aceptación no revisa solo el estado verde. Revisa el flujo real de datos.

1. Comprobar estado

En la interfaz WebAdmin:

Site-to-site VPN > IPsec

Comprobar:

• La conexión está activa.
• El estado del túnel es established.
• Con varias redes, todas las Child SAs esperadas están establecidas.
• No se ven reconnects ni errores recurrentes.

2. Comprobar Log Viewer

Menu path:

Log viewer

Generar tráfico de prueba con Source, Destination y Service claros. Después revisar en Log Viewer qué regla de firewall coincide y si NAT, Webfilter, IPS u otros módulos influyen en el tráfico.

3. Usar Packet Capture

Si Log Viewer no basta, debería usarse Packet Capture con un filtro estrecho:

Diagnostics > Tools > Packet capture

Ejemplo de filtro:

host 172.16.10.25 and host 10.20.30.15

En troubleshooting VPN es importante comprobar ambas direcciones. Paquetes salientes sin respuesta suelen indicar un problema de ruta de retorno, NAT o del extremo remoto.

4. Usar CLI solo de forma dirigida

Para análisis más profundo puede usarse Advanced Shell por SSH:

ipsec statusall

Entre otros, son interesantes:

• IKE SA established
• Child SA installed
• redes locales y remotas
• contadores de bytes en ambas direcciones
• mensajes recurrentes de rekey o disconnect

Si SSH aún no está preparado, ayuda conectarse a Sophos Firewall por SSH.

Errores típicos

Checklist

Antes del cambio:

• Las redes locales y remotas son inequívocas.
• Se decidió conscientemente entre policy-based y route-based.
• El perfil IPsec está alineado con el extremo remoto.
• Preshared Key o certificados están documentados de forma segura.
• Las reglas firewall están planificadas, incluida dirección, posición, logging y servicios.
• Con Create firewall rule está claro qué reglas creadas automáticamente deben retocarse.
• Para route-based Any-to-Any están planificadas reglas firewall y rutas manuales.
• NAT está excluido o documentado deliberadamente.
• Device Access para IPsec ha sido revisado.
• Ventana de mantenimiento, extremo remoto y fallback son conocidos.

Después del cambio:

• El estado del túnel es established.
• Log Viewer muestra la regla firewall esperada.
• Packet Capture muestra ida y vuelta.
• Se probaron accesos internos DNS y de aplicaciones.
• Los contadores de bytes aumentan en ambas direcciones.
• NAT y ruta de retorno están alineados con el extremo remoto.
• El cambio está actualizado en la documentación de red.

Preguntas frecuentes