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

Para Microsoft Azure o AWS hay además artículos propios con las particularidades de cada proveedor: Conectar Sophos Firewall con Azure VPN Gateway y Conectar Sophos Firewall con AWS Site-to-Site VPN.

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.

• IPsec policy-based: adecuado para conexiones simples entre sedes con redes locales y remotas claras. Se controla principalmente mediante subredes locales y remotas en la conexión IPsec y mediante reglas de firewall. Sophos crea túneles Phase 2 individuales para las combinaciones de subredes locales y remotas.
• IPsec route-based con traffic selectors: también usa subredes locales y remotas, pero crea su propia interfaz XFRM para la conexión. Esto facilita la depuración y separa mejor el túnel de otras conexiones IPsec.
• IPsec route-based Any-to-Any: la variante más flexible para redes en crecimiento, SD-WAN, routing dinámico y diseños dual-stack. Las rutas y las reglas de firewall deciden entonces qué paquetes entran en el túnel, ya no las subredes de la conexión IPsec.

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:

• Local gateway: IP WAN o FQDN de la Sophos Firewall local.
• Remote gateway: IP pública o FQDN del extremo remoto.
• Redes locales: 172.16.10.0/24, 172.16.20.0/24.
• Redes remotas: 10.20.30.0/24.
• Tipo de VPN: policy-based o route-based. El connection type Host-to-host también existe, pero no es el foco de esta guía para sedes.
• Listening interface: interfaz WAN del firewall local. No se puede usar una bridge interface para esto.
• Versión IKE: IKEv2 si el extremo remoto lo admite.
• Autenticación: Preshared Key o certificado.
• Perfil IPsec: Encryption, authentication, DH group, PFS, key lifetime.
• Reglas de firewall: fuentes, destinos y servicios permitidos.
• NAT: sin NAT, SNAT/DNAT por redes solapadas o requisito del proveedor.
• Operación: owner, ventana de mantenimiento, plan de pruebas, monitoring, ruta de fallback.
• Gateway type: initiate connection o respond only, según qué lado abra el túnel.
• IP version: IPv4, IPv6 o Dual si ambos lados lo admiten explícitamente.
• Local ID y Remote ID: necesarios si la autenticación no debe depender solo de la dirección IP pública.

⚠️ 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 la interfaz XFRM pertenece a la zona VPN; después, rutas y reglas de firewall deciden qué tráfico puede pasar realmente por el túnel.

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:

• Posición de regla: Mover las reglas creadas automáticamente al lugar correcto después de guardar.
• Dirección: Revisar por separado la regla entrante y saliente, no solo el nombre del túnel.
• Fuentes y destinos: Ajustar redes locales y remotas de forma más estricta si el asistente las crea demasiado amplias.
• Servicios: Usar Any solo para la primera prueba y después reducirlo a los servicios necesarios.
• Logging: Activar durante introducción y análisis de errores.
• Security Features: Definir IPS, Web, Application Control o NDR conscientemente, no heredarlos por casualidad.

⚠️ 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

NAT Traversal está siempre activo en Sophos Firewall. Si un lado está detrás de un router o NAT del proveedor, Local ID y Remote ID cobran aún más importancia, porque la dirección pública del gateway por sí sola ya no basta para identificar correctamente el peer. Los IDs DNS, IP o de correo electrónico no tienen que resolverse públicamente; solo deben coincidir en ambos lados y usar un formato válido.

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.

Los ajustes avanzados de User authentication mode pertenecen solo a perfiles IKEv1 con lógica XAuth, por ejemplo diseños cliente-servidor muy antiguos. Para conexiones site-to-site normales con IKEv2 no debe interpretarse como un paso adicional de autenticación. Los ajustes idle connection obsoletos tampoco deberían planificarse como diseño operativo moderno.

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
• IP version, normalmente IPv4.
• Gateway type, normalmente initiate connection en el lado con gateway remoto definido.

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 debe planificarse limpiamente. La interfaz XFRM permanece asignada a la zona VPN; esta asignación de zona no es un campo de diseño libre como en interfaces físicas normales.

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
• Si ambas subredes están en Any, el routing decide qué tráfico entra en el túnel.
• Si se usan traffic selectors específicos, deben coincidir exactamente con el peer.

1. La interfaz XFRM existe y está en la zona correcta.
2. La ruta hacia la red remota apunta a la interfaz XFRM.
3. Las reglas firewall permiten el tráfico necesario entre las zonas correctas.

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:

• Red local a red remota: LAN a VPN o zona de destino.
• Red remota a red local de servidores: VPN o zona XFRM a Server.
• Management o Monitoring: solo sistemas admin o de monitoring definidos.
• DNS, AD, RDP, HTTPS: solo servicios necesarios, no Any de forma general.

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.

• En redes solapadas, NAT a menudo no es opcional, sino parte del diseño del túnel.
• En route-based Any-to-Any, el routing y las reglas firewall deciden con más peso qué tráfico entra en el túnel.
• En IPsec policy-based y VPN route-based con traffic selectors, NAT cambia las direcciones antes de compararlas con los selectors.

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.

Definir matriz de aceptación

Antes de la primera prueba conviene definir una pequeña matriz de aceptación. Así queda claro qué conexión debe funcionar realmente y qué conexión debe quedar bloqueada de forma intencionada.

Casos de prueba útiles:

• Red de clientes local hacia red de servidores remota: prueba típica de aplicación, por ejemplo HTTPS, RDP, SMB, SQL o ICMP solo como prueba básica.
• Red de clientes remota hacia red de servidores local: comprobar la dirección contraria si la conexión se usa de forma bidireccional.
• DNS o AD a través del túnel: probarlo solo si estos servicios deben pasar realmente por el túnel. Definir origen, servidor destino y puerto con precisión.
• Monitorización o backup: comprobar si los sistemas previstos acceden desde la dirección correcta y no necesitan accidentalmente reglas Any.
• Prueba no permitida: un puerto o una red no autorizados de forma intencionada deben bloquearse. Si no, la base de reglas es demasiado amplia.
• Transferencia grande: en transferencias de archivos, RDP, VoIP o problemas de aplicación, observar también MTU/MSS y fragmentación.

Para cada caso de prueba conviene anotar IP de origen, IP de destino, servicio, regla firewall esperada, regla NAT esperada y dirección esperada. Después de cada prueba se comparan Log Viewer, Packet Capture y contadores de bytes. Si solo se prueba ping, el túnel aún no está aceptado.

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

• El túnel no levanta: versión IKE, perfil, PSK, certificado, Local ID o Remote ID no coincide. strongswan.log, perfil IPsec, extremo remoto.
• Phase 1 está activa, Phase 2 no: redes locales/remotas o Phase 2 proposal no coinciden. Traffic Selectors, subredes, PFS.
• El túnel está verde, pero no hay acceso: falta regla de firewall, NAT, routing o ruta de retorno. Log Viewer, Packet Capture, routing.
• Solo funciona una dirección: el extremo remoto no conoce la ruta de retorno o NAT es incorrecto. extremo remoto, reglas NAT, contadores de bytes.
• Pings pequeños funcionan, aplicaciones se bloquean: MTU/MSS, fragmentación o Security Feature. comprobar MTU/MSS, Packet Capture.
• Túnel route-based poco claro: interfaz XFRM, ruta o SD-WAN Route no encaja. Network > Interfaces, routing, SD-WAN.
• Varios túneles se influyen: redes solapadas o configuración de Selector similar. objetos de túnel, failover group, rutas.

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.
• Matriz de aceptación con al menos una prueba por cada dirección requerida definida.

Preguntas frecuentes