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, estos túneles rara vez fallan por una única opción de la interfaz. Las causas más habituales 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.

Procedimiento resumido: Elegir el tipo de túnel, coordinar el perfil y los IDs, crear la conexión, enrutar la interfaz XFRM en route-based Any-to-Any, configurar las reglas de firewall y NAT y validar el túnel con tráfico real, logs y Packet Capture.

Este procedimiento sirve para conexiones Sophos con Sophos o con terceros entre una sede central, una sucursal o un cloud gateway. Microsoft Azure y AWS requieren detalles adicionales del proveedor: Conectar Sophos Firewall con Azure VPN Gateway y Conectar Sophos Firewall con AWS Site-to-Site VPN. Para el Remote Access de usuarios individuales, se aplica en cambio la comparativa entre Sophos Connect y SSL VPN. Si un túnel existente ya aparece en verde pero no pasa tráfico, consulte Sophos Firewall IPsec VPN Troubleshooting.

Si la conexión se establece exclusivamente entre dos Sophos Firewall y la sucursal debe establecer el túnel como cliente hacia una sede central accesible mediante una dirección estática, SSL Site-to-Site VPN es una alternativa más sencilla. Para peers de terceros, redundancia, routing dinámico o redes en crecimiento, IPsec route-based sigue siendo la opción más flexible.

Para varios firewalls administrados por Sophos Fusion (antes Sophos Central), un grupo de conexiones SD-WAN puede generar automáticamente los túneles basados en rutas, las interfaces XFRM, las rutas y las reglas opcionales. Esto no sustituye la planificación de la topología ni la validación local del tráfico.

Elegir entre policy-based y route-based

Antes de configurar hay que decidir si el túnel será policy-based o route-based. Fuera de la interfaz de Sophos, route-based también suele denominarse tunnel-based. Ambos términos describen un túnel con su propia interfaz XFRM. En cambio, el término “root-based”, que aparece ocasionalmente, no es un modo de VPN.

Sophos recomienda VPN route-based para diseños nuevos. Any-to-Any es especialmente flexible para redes en crecimiento porque los cambios de ruta no interrumpen el túnel. En cambio, modificar las subredes o los Traffic Selectors interrumpe las conexiones existentes. Ambos extremos del túnel deben usar el mismo tipo: no se admite policy-based en un extremo y route-based en el otro.

Para utilizar OSPF o BGP a través del túnel, el diseño más comprensible es route-based Any-to-Any con interfaces XFRM direccionadas. Antes de actualizar una configuración policy-based antigua, hay que comprobar si las redes VPN se anuncian mediante redistribute kernel; SFOS 22: rutas IPsec y redistribute kernel explica el cambio entre versiones y el marco para una migración segura.

Qué confirma realmente un túnel en verde

Un estado como Established confirma que los peers han negociado IKE y al menos una Child SA. No confirma que se seleccione una ruta, que coincida la regla de firewall, que NAT sea correcto, que el peer conozca la ruta de retorno ni que responda el host de destino. Por tanto, un túnel puede aparecer en verde sin transportar tráfico útil entre sedes.

Sophos Firewall utiliza ESP en modo túnel. ESP protege la integridad de los datos, autentica el origen de los datos transportados y ofrece protección antirrepetición frente a paquetes reinyectados.

La ruta de datos puede entenderse con el siguiente modelo:

Policy-based
Origen -> Regla de firewall -> Selector Local/Remote -> Child SA -> Peer -> Ruta de retorno y regla -> Destino

Route-based Any-to-Any
Origen -> Ruta o SD-WAN Route -> Regla de firewall -> XFRM -> Child SA -> Peer -> Ruta de retorno y regla -> Destino

Se trata de un modelo de diagnóstico, no de una representación completa del orden de procesamiento interno de SFOS. Aun así, la distinción es esencial para la validación: con policy-based, el par de redes de la conexión IPsec determina qué tráfico pertenece al túnel. Con route-based Any-to-Any, esa selección la toma el routing o SD-WAN.

Requisitos y datos de planificación

Antes de configurar deben documentarse al menos estos datos:

• Extremo local: interfaz WAN de Sophos Firewall y dirección por la que el peer accede a esta interfaz.
• Remote Gateway: IP pública o DNS hostname del peer.
• Gateway type: normalmente Respond only en la central e Initiate the connection en la sucursal.
• IP version: IPv4, IPv6 o Dual. Dual solo está disponible para interfaces de túnel route-based con Any-to-Any como subred local y remota. Con Dual deben planificarse por separado las reglas de firewall IPv4 e IPv6.
• Redes locales: por ejemplo 172.16.10.0/24 y 172.16.20.0/24.
• Redes remotas: por ejemplo 10.20.30.0/24.
• Tipo de VPN: policy-based o route-based. También existe el Connection type Host-to-host, pero no es el objetivo de esta guía para sedes.
• Listening interface: interfaz WAN del firewall local. No puede utilizarse una bridge interface.
• Versión IKE: preferiblemente IKEv2 si el peer la admite.
• Authentication type: Preshared key, Digital certificate o RSA key.
• Local ID y Remote ID: especialmente importantes con FQDN, peers dinámicos, NAT-T o un wildcard gateway.
• Perfil IPsec: Encryption, Authentication, DH Group, PFS y Key life.
• Reglas de firewall: Sources, Destinations y Services permitidos.
• NAT: sin NAT o SNAT/DNAT por redes solapadas o requisitos del proveedor.
• Operación: responsable, ventana de mantenimiento, plan de pruebas, monitoring y ruta de fallback.

Ejemplo coherente para ambos firewalls

Los siguientes valores permiten seguir con claridad los pasos posteriores. Deben sustituirse por las direcciones WAN, redes y nombres propios:

Primero se crean ambas redes LAN como objetos en Hosts and services > IP host. En la sede central, 10.10.10.0/24 es el Local subnet y 10.20.20.0/24 el Remote subnet; en la sucursal se invierten. Lo mismo se aplica a los IDs: el Local ID de un lado debe ser el Remote ID esperado por el otro. La red de transferencia 10.255.0.0/30 solo se utiliza con route-based Any-to-Any y no debe solaparse con ninguna red de producción, VPN o management.

Para los IDs del ejemplo, configurar Local ID type = DNS y Remote ID type = DNS en ambos firewalls. En la sede central, introducir Local ID vpn-hq.example.invalid y Remote ID vpn-branch.example.invalid; en la sucursal, exactamente a la inversa. Estos valores identifican a los peers; no se utilizan para la resolución DNS de sus direcciones de gateway. Si se utiliza otro tipo de ID, el tipo y el formato también deben coincidir de forma cruzada.

Para cada objeto de red IPv4, seleccionar Add, IP version = IPv4, Type = Network, la dirección de red y la máscara de subred /24, y guardar. Los nombres HQ_LAN para 10.10.10.0/24 y Branch_LAN para 10.20.20.0/24 son adecuados; ambos objetos se necesitan en los dos firewalls. En cambio, un objeto de host sirve para una dirección individual de pruebas o monitoring.

Utilizar la sucursal como iniciador distribuye los reintentos entre las sucursales y resulta adecuado cuando cambia la IP WAN de la sucursal. Si un iniciador debe acceder a un peer con IP WAN dinámica, el campo Gateway address de ese peer debe contener un nombre de host DNS que realmente resuelva a su dirección pública actual. Configurar y comprobar Dynamic DNS en Sophos Firewall describe el registro y la prueba de resolución. Un ID de tipo DNS, por sí solo, no es una dirección de gateway accesible. Configurar DDNS únicamente en la central no permite localizar la dirección dinámica de la sucursal.

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

Redes, perfil, IDs y certificados

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

Por eso, para nuevas sedes merece la pena un plan de direccionamiento IP limpio. Si las VLANs o zonas todavía no están modeladas con claridad, consulte Configurar zonas e interfaces de Sophos Firewall.

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, lo más sencillo suele ser documentar primero un perfil común y configurar después ambos lados.

Con IKEv2, Sophos puede usar Preshared Keys únicos para cada combinación de Local ID y Remote ID. IKEv1 es más limitado porque solo se aplica un PSK por combinación de gateways. En entornos con varios túneles al mismo peer, conviene usar IKEv2 con IDs claramente definidos.

⚠️ Con IKEv1, el firewall utiliza el PSK de la conexión configurada más recientemente para la misma combinación de gateway local y remoto. Esto se aplica a las configuraciones IPsec site-to-site y de acceso remoto. Configurar posteriormente una conexión para esa combinación de gateways con un PSK diferente puede provocar un fallo de autenticación de las conexiones existentes durante una negociación posterior. Antes de añadir una conexión de este tipo o cambiar un PSK, revisar todas las configuraciones IKEv1 afectadas y coordinar el PSK con sus respectivos peers antes de la siguiente negociación.

NAT Traversal está siempre activo en Sophos Firewall. Si un lado está detrás de un router o NAT del proveedor, los IDs cobran más importancia porque la dirección pública del gateway no identifica al peer de forma inequívoca. El Local ID de un lado debe coincidir con el Remote ID que espera el otro. Los IDs de tipo DNS, IP o correo electrónico no tienen que resolverse públicamente, pero el formato y el valor deben coincidir de forma cruzada.

Sophos Firewall no ofrece un interruptor NAT-T independiente: Los dispositivos detectan NAT automáticamente. Sin NAT, las negociaciones IKE utilizan UDP 500 y el tráfico de datos usa ESP mediante IP protocol 50. Cuando el firewall detecta un dispositivo NAT, encapsula en UDP 4500 las negociaciones IKE y de fase 2 posteriores, así como los paquetes ESP.

Si hay un dispositivo NAT en la ruta IPsec y el peer es un firewall de otro fabricante, NAT-T también debe estar activado en ese firewall. La configuración se comprueba con la documentación de ese peer; Sophos Firewall no necesita un interruptor adicional.

Los peers detectan un dispositivo NAT durante el intercambio IKE de fase 1 y acuerdan entonces utilizar NAT-T. ESP es un protocolo de capa 3 sin información de puertos de capa 4, mientras que PAT también puede traducir puertos. Por ello, la encapsulación UDP a través del puerto 4500 proporciona una envoltura UDP identificable en la ruta NAT; el peer elimina esta envoltura y procesa el paquete IPsec original.

Si Sophos Firewall está detrás de un router, este necesita una regla DNAT o un reenvío de puertos desde la dirección pública al Listening interface privado del firewall. En el ejemplo coherente, la dirección WAN del router de la central puede ser 198.51.100.10, mientras que la WAN del firewall utiliza 172.31.255.2. En ese caso, la central selecciona su WAN privada como Listening interface; la sucursal sigue conectándose a 198.51.100.10, no a 172.31.255.2. El router traduce el destino desde su dirección pública a 172.31.255.2. Los selectores LAN siguen siendo Local 10.10.10.0/24 y Remote 10.20.20.0/24 en la central, y exactamente a la inversa en la sucursal.

Para NAT-T deben permitirse UDP 500 y UDP 4500. Las instrucciones de SFOS 22 y SFOS 23 para un firewall situado detrás de un router también indican IP protocol 50, no el puerto TCP/UDP 50. Cuando se negocia NAT-T, ESP se transporta dentro de UDP 4500; ESP nativo utiliza el protocolo 50. Por tanto, la lista de requisitos del router y la explicación de NAT-T no deben interpretarse como rutas de paquetes idénticas. Antes del cambio, documentar las funciones del router y los reenvíos existentes, y comprobar mediante logs de IKE y Packet Capture qué ruta se utiliza realmente. No eliminar una autorización ESP existente sin comprobarla; limitar las autorizaciones adicionales a las direcciones de los peers previstos. Si no se produce la negociación, restaurar la configuración documentada del router. Esta configuración es independiente de SNAT/DNAT para redes LAN solapadas o tráfico de datos traducido.

Con Digital certificate, los formatos y roles de los certificados de ambos lados deben coincidir exactamente. Sophos no admite certificados ECDSA para conexiones IPsec; se requieren certificados RSA. Local certificate corresponde al firewall local, Remote certificate al peer y Remote CA certificate es la base de confianza para el certificado de ese peer. No utilizar una CA pública como Remote CA certificate: de lo contrario, un atacante con un certificado válido de esa CA podría obtener acceso no autorizado. Con el tipo de ID DER.ASN1 DN (X.509) se utiliza el Distinguished Name del certificado correspondiente; como Remote ID debe introducirse el DN del certificado del peer.

RSA key es un Authentication type independiente, no la selección de un certificado RSA. El firewall genera automáticamente el par de claves y muestra únicamente la clave pública en Local RSA key. Copiarla en Remote RSA key del peer e introducir la clave pública de este en el campo Remote RSA key local. Ambos lados deben utilizar el mismo formato PKCS1 o DNS. Las claves privadas no se transfieren entre los firewalls.

Cambiar la CA local Default de Sophos Firewall es un cambio del trust anchor, no una modificación estética del certificado. Los peers con un Default.pem importado y los certificados firmados localmente deben migrarse de forma controlada. Renovar de forma controlada la Default CA de Sophos Firewall explica el inventario, la ventana de mantenimiento, las pruebas y la recuperación.

Si se selecciona Digital certificate, no basta con elegirlo en el formulario. Antes deben prepararse la confianza de la CA, los certificados locales y del peer y los Certificate IDs. El procedimiento completo se describe en Configurar IPsec Site-to-Site con certificados. Si la CA revoca certificados antes de que expiren, la lista de revocación actual también debe formar parte del plan operativo. Un procedimiento independiente explica la importación de la CRL, la comprobación de nextUpdate y la prueba negativa controlada en Sophos Firewall.

Si un túnel no se establece, NO_PROPOSAL_CHOSEN, los errores de ID o los errores de autenticación son indicios habituales. La sección Probar el túnel y solucionar errores empieza con la delimitación adecuada.

Configurar IPsec policy-based

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

1. Comprobar o crear el perfil IPsec

Ruta de menú:

Profiles > IPsec profiles

Primero hay que comprobar si un perfil existente coincide con el peer. Si se necesita un perfil propio, debe tener un nombre claro, por ejemplo Branch-Zurich-IKEv2. El nombre debe seguir siendo comprensible cuando existan varios túneles y peers.

Como mínimo hay que documentar:

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

En firewalls de terceros, el peer debe confirmar por escrito los mismos valores. Una captura de pantalla no suele ser suficiente porque algunos campos tienen nombres diferentes según el fabricante.

La interacción entre Phase 1, Phase 2, PFS, Lifetimes, Rekeying y DPD se explica en Entender y configurar de forma segura los perfiles IPsec de Sophos Firewall. Antes de activar, hay que comprobar Dead peer detection: Sophos especifica Hold o Disconnect para el peer que responde y Re-initiate para el iniciador. Un IPsec failover group modifica este comportamiento y no se rige por la misma lógica DPD.

2. Añadir la conexión IPsec

Ruta de menú:

Site-to-site VPN > IPsec

Crear una nueva conexión IPsec y elegir Policy-based como Connection type. A continuación, configurar los datos básicos:

• Nombre del túnel, por ejemplo branch-zurich
• IP version, normalmente IPv4
• Gateway type, por ejemplo Respond only en la central o Initiate the connection en la sucursal
• Listening interface como interfaz WAN local
• Gateway address del peer como dirección IP o DNS hostname
• Authentication type: Preshared key, Digital certificate o RSA key
• Local ID y Remote ID si son necesarios
• IPsec profile
• Local subnet
• Remote subnet

Para este ejemplo policy-based se seleccionan redes específicas en ambos lados. La documentación de SFOS 22 y SFOS 23 no utiliza una formulación uniforme respecto a Any: la descripción general de Policy-based indica que no puede seleccionarse Any para las subredes locales y remotas; las instrucciones Add an IPsec connection permiten Any como máximo en uno de los lados. No deducir de ello que pueda configurarse policy-based Any-to-Any. Si se necesita Any en un solo lado, antes de implementarlo comprobar la opción en el build instalado, los selectores del peer y el routing previsto en una configuración de pruebas aislada. Si aparecen SAs o asignaciones de tráfico inesperadas, desactivar la nueva conexión y restaurar los selectores específicos documentados. Cuando hay varias redes locales y remotas específicas, se crea una Phase 2 SA por combinación: dos redes locales y dos remotas generan cuatro SAs. Todas las conexiones policy-based comparten una interfaz IPsec; por tanto, una captura realizada únicamente en esa interfaz no identifica el túnel.

Con Respond only, la dirección wildcard * puede ser útil si varias sucursales o peers dinámicos se conectan a la central. En ese caso debe establecerse al menos un Local ID o Remote ID; normalmente conviene usar ambos para una asignación inequívoca. El Local ID de un lado corresponde al Remote ID que espera el otro. Initiate the connection no admite una dirección wildcard, por lo que el peer debe definirse como dirección IP o DNS hostname.

Debe utilizarse un Preshared Key robusto y único, y documentarlo de forma segura. Reutilizar una antigua clave predeterminada en varias sedes es un riesgo operativo innecesario.

Con Authentication type = Preshared key, introducir el PSK acordado y repetirlo en el campo de confirmación. En el peer, introducir exactamente el mismo PSK y confirmarlo también; la configuración especular de los IDs no modifica la clave compartida. Intercambiar el PSK únicamente a través del canal seguro previsto, sin incluirlo en capturas de pantalla ni en tickets públicos.

A continuación, se crea la conexión de forma especular en el peer. En el ejemplo, la sede central espera a 203.0.113.20 con Respond only; sus redes Local/Remote son 10.10.10.0/24 y 10.20.20.0/24. La sucursal usa Initiate the connection, la Gateway address 198.51.100.10 e invierte redes e IDs Local/Remote. Perfil, autenticación y PSK deben ser compatibles. La conexión solo se activa después de guardar ambas entradas y comprobar las reglas.

Los ajustes avanzados de User authentication mode solo corresponden a perfiles IKEv1 con lógica XAuth, como diseños cliente-servidor muy antiguos. En conexiones Site-to-Site normales con IKEv2, no deben interpretarse como un paso de autenticación adicional. Tampoco deben planificarse ajustes obsoletos de idle connection como un diseño operativo moderno.

3. Activar el túnel

Al guardar puede seleccionarse Activate on save. En entornos productivos debe hacerse dentro de una ventana de mantenimiento definida, cuando el peer esté accesible y ambos lados puedan revisar los logs.

Sin Activate on save, la conexión guardada se activa mediante su botón Status en Site-to-site VPN > IPsec. Esto debe distinguirse de Gateway type = Disable: la conexión permanece inactiva hasta que el usuario la inicia. Respond only espera solicitudes; Initiate the connection inicia la negociación también después de reiniciar el servicio VPN o el firewall. Tras un simple Disconnect, un iniciador puede volver a conectarse; por tanto, para retirar la configuración también hay que desactivar la conexión.

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 equivale automáticamente a un túnel establecido. Con varias redes locales o remotas también puede haber varias Security Associations.

API XML: separar configuración y acciones de control

Para automatizar este procedimiento, no basta con traducir los campos de la GUI a una solicitud XML. La referencia API de SFOS 22 y SFOS 23 muestra los ajustes en VPNIPSecConnection/Configuration y, por separado, las ramas de control Active, DeActive, Connection y DisConnection, cada una con Name. Según el comentario del ejemplo, estas cuatro ramas solo funcionan después de crear la conexión. El ejemplo de configuración incluye además Status con Active/Deactive; la fila de ActivateOnSave indica y/n. Guardar, activar, el comportamiento tras un reinicio y un túnel realmente establecido no son ajustes intercambiables ni demuestran que una solicitud API sea ejecutable.

Esta representación antigua también contiene contradicciones entre el ejemplo y las filas de parámetros:

• En el ejemplo, AliasLocalWANPort sigue a un comentario relativo a un puerto WAN alias, pero la tabla lo define como ARRAY obligatorio. Name y RemoteHost también figuran como ARRAY; esto no determina una serialización segura de varios valores ni su asociación por pares.
• El ejemplo de UserAuthenticationMode muestra AsServer/AsClient, mientras que la fila indica EnableAsServer/EnableAsClient. En DisconnectOnIdleInterval, el valor predeterminado 0 queda fuera del intervalo indicado 120..21600; 600 es solo el valor del ejemplo. No unificar estas diferencias silenciosamente ni adoptar estos valores como predeterminados de IKEv2.
• El campo antiguo AllowNATTraversal con Enable/Disable no demuestra que exista un interruptor NAT-T actual. La fila de RemoteHost prohíbe * con RSAKey; es una restricción de esa referencia, no una regla general de funcionamiento de la GUI confirmada aquí.

Mientras no se haya aclarado la representación API del build instalado, utilizar el procedimiento WebAdmin anterior y resolver las dudas antes de automatizarlo. Esta nota no es una plantilla XML completa; la detección automática de NAT-T y las indicaciones sobre IKEv2, RSA e IDs siguen siendo las mismas para el procedimiento GUI descrito.

Configurar IPsec route-based

IPsec route-based separa la negociación VPN de la selección de ruta. Con Any-to-Any, SFOS proporciona una interfaz XFRM propia y direccionable. Las instrucciones de SFOS 22 y SFOS 23 también describen la creación de una interfaz XFRM con Traffic Selectors específicos; a diferencia de Any-to-Any, no debe asignársele una dirección IP ni una ruta manual. Antes de una migración, documentar la versión de SFOS instalada, la asignación de la interfaz y la ruta que se haya creado realmente.

1. Crear la conexión como route-based

Ruta de menú:

Site-to-site VPN > IPsec

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

2. Implementar Any-to-Any o Traffic Selectors

Para Any-to-Any, Sophos muestra la interfaz XFRM generada bajo la interfaz física utilizada en:

Network > Interfaces

Una interfaz XFRM generada siempre permanece asignada a la zona VPN. Las dos variantes se configuran de manera distinta.

Any-to-Any con IPv4, IPv6 o Dual

Cuando Local subnet y Remote subnet están configuradas como Any, SFOS crea automáticamente la interfaz XFRM para la conexión IPsec route-based. No hay que añadir una interfaz XFRM por separado. En Network > Interfaces, se despliega la interfaz física seleccionada como Listening interface y se abre la interfaz XFRM generada. En el ejemplo, la sede central recibe 10.255.0.1/30 y la sucursal 10.255.0.2/30. Con Dual también se necesitan reglas IPv4 e IPv6 separadas.

El Name editable es el nombre mostrado. No debe confundirse con los valores que asigna SFOS: Hardware es el nombre del registro, IPsec connection es la conexión route-based asociada y Network zone siempre es VPN. Solo se configuran los campos de dirección de la versión IP seleccionada en la conexión IPsec:

• IPv4/netmask: introducir la dirección IPv4 de transferencia planificada y seleccionar su subred.
• IPv6/prefix: introducir la dirección IPv6 de transferencia planificada y el prefijo.
• Con Dual, configurar ambas familias. Si la conexión solo usa IPv4 o solo IPv6, SFOS no aplica los valores introducidos para la otra versión.

En Advanced settings > Interface settings, conservar el MTU predeterminado o introducir el valor probado expresamente. SFOS calcula el valor predeterminado restando la sobrecarga IPsec máxima al MTU de la interfaz física. Activar Override MSS e introducir un valor solo si la red requiere uno distinto del predeterminado del firewall; no presuponer un valor numérico no documentado.

Antes de modificar los campos, registrar el nombre, las direcciones, el MTU, el estado y valor de Override MSS, y las rutas o gateways dependientes. Tras guardar, volver a abrir la interfaz y verificar que Hardware, IPsec connection y la zona VPN siguen asignados sin cambios. Ejecutar después Route lookup en ambos peers y probar tráfico real en ambos sentidos, incluida una transferencia grande si cambió MTU o MSS. Para volver atrás, restaurar los valores registrados y las rutas o gateways anteriores. Si es una conexión nueva, desactivarla y eliminar solo sus rutas y reglas dependientes; no intentar borrar ni recrear por separado la interfaz XFRM generada.

Después se crea en ambos lados la ruta hacia la LAN remota mediante Routing > Static routes > IPv4 unicast route > Add:

• Sede central: Destination 10.20.20.0/24, Interface la interfaz XFRM local.
• Sucursal: Destination 10.10.10.0/24, Interface la interfaz XFRM local.

Como alternativa puede utilizarse una SD-WAN Route o routing dinámico mediante BGP u OSPF. Con una SD-WAN Route hay que decidir expresamente si se permite otra ruta de fallback. Si el tráfico no debe desviarse cuando falle el túnel, se activa Route only through specified gateways y se prueba este fallo por separado.

Las rutas y las reglas de firewall determinan qué tráfico entra en el túnel. Una ruta estática sencilla puede apuntar directamente a la interfaz XFRM. Para varias líneas, comprobaciones SLA o determinados diseños de failover, se crea además un Custom Gateway con la dirección IP XFRM del peer y se utiliza en una SD-WAN Route.

Para la alternativa SD-WAN, seleccionar IPv4 y Add en Routing > SD-WAN routes. En la central, configurar Source networks = HQ_LAN, Destination networks = Branch_LAN y seleccionar Primary and backup gateways en Link selection settings. En Primary gateway > Add, seleccionar 10.255.0.2 como Gateway IP y la interfaz XFRM local con 10.255.0.1/30 como Interface. En la sucursal, invertir Source/Destination, utilizar Gateway IP 10.255.0.1 y la interfaz XFRM local con 10.255.0.2/30. Para Health check, seleccionar en Monitoring condition un host interno del peer que realmente responda, por ejemplo 10.20.20.15 en la sucursal o 10.10.10.25 en la central. La propia sonda debe estar permitida y utilizar el túnel previsto. Para una selección basada en SLA, seleccionar un perfil SD-WAN con los gateways del túnel. La ruta estática y la ruta SD-WAN son alternativas en este caso; no crear ambas como rutas competidoras sin comprobarlas. Documentar las reglas y la Route Precedence existentes antes del cambio y, al revertirlo, restaurar la selección anterior de ruta y gateway.

Los túneles Any-to-Any pueden controlar varios XFRM Gateways directamente mediante SD-WAN y comprobaciones SLA; no necesitan un VPN Failover Group adicional. En cambio, los túneles Policy-based y los túneles Route-based con Traffic Selectors utilizan un IPsec Failover Group para conexiones redundantes. El procedimiento enlazado explica el orden, el Health Check, Automatic failback y la prueba de fallo controlada. El grupo desactiva DPD en las conexiones asignadas y establece Key negotiation tries en 3.

Después de guardar, deben comprobarse cuatro puntos:

1. La interfaz XFRM aparece en Network > Interfaces y tiene la IP de transferencia prevista.
2. La ruta remota apunta a la interfaz XFRM o al gateway XFRM correspondiente.
3. Diagnostics > Tools > Route lookup devuelve la interfaz o el gateway XFRM esperado para un host real de la LAN remota. La misma prueba se realiza en el peer.
4. Las reglas solo permiten las direcciones y los servicios previstos.

Traffic Selectors

Para subredes específicas, las instrucciones de SFOS 22 y SFOS 23 consultadas describen una interfaz XFRM por configuración IPsec. En Network > Interfaces, desplegar la Listening interface mediante el indicador azul. No asignar una dirección IP ni una ruta manual a la interfaz generada: la ruta estática se crea automáticamente cuando el túnel está established. En la central, seleccionar Local HQ_LAN y Remote Branch_LAN; en la sucursal, Local Branch_LAN y Remote HQ_LAN. Gateway, perfil, autenticación e IDs se configuran de forma especular, igual que en las otras variantes. En route-based no se admite Any en un solo lado y un selector específico en el otro. Si la interfaz documentada no aparece en el build instalado, aclarar primero la configuración, la versión y los logs; no intentar forzar una interfaz XFRM de sustitución ni un direccionamiento Any-to-Any.

Esta variante es adecuada para redes pequeñas y claramente definidas; Sophos la recomienda frente a policy-based, también para conexiones compatibles con terceros. Utilizar la interfaz XFRM en Diagnostics > Packet capture para identificar el tráfico saliente; comprobar además la ruta automática, cada Child SA esperada, los logs y el tráfico en ambos sentidos. WAF sobre IPsec route-based con Traffic Selectors no es compatible; para ello puede utilizarse una configuración route-based Any-to-Any adecuada. Si la migración falla, desactivar la nueva conexión y únicamente sus reglas nuevas, y volver a activar la conexión anterior documentada.

Un túnel Any-to-Any no puede cambiarse directamente a Traffic Selectors específicos. Hay que clonar o volver a crear la conexión y realizar después una migración controlada.

3. Tener en cuenta XFRM y MTU

Las VPN route-based son más propensas a malentendidos relacionados con routing, MTU y MSS. Si las pruebas pequeñas funcionan pero las transferencias grandes se bloquean, no debe modificarse inmediatamente el perfil IPsec. Primero hay que comprobar MTU, MSS, fragmentación y la ruta real. El procedimiento adecuado se describe en Comprobar MTU y MSS en Sophos Firewall para problemas VPN.

Reglas de firewall, NAT y Device Access

Reglas de firewall y reglas automáticas

Después de configurar 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.

Ruta de menú:

Rules and policies > Firewall rules

Reglas habituales:

• Red local hacia red remota: por ejemplo LAN a VPN.
• Red remota hacia red local de servidores: por ejemplo VPN a Server.
• Management o monitoring: permitir solo sistemas de administración o monitoring definidos.
• DNS, AD, RDP, HTTPS: permitir solo los servicios necesarios, no Any de forma general.

Las interfaces XFRM siempre pertenecen a la zona VPN. Si se usan ambas direcciones, hacen falta reglas inbound y outbound adecuadas. Las reglas separadas con logging muestran con mayor claridad durante la aceptación qué servicios puede alcanzar cada lado. La estructura general se describe en Crear y comprobar de forma segura reglas de Sophos Firewall.

Los paquetes IPsec entrantes primero se desencapsulan y se descifran. Después, la regla de firewall correspondiente aplica sus políticas de seguridad al tráfico de datos antes de reenviarlo al destino. Para el tráfico saliente, la regla de firewall correspondiente se aplica antes de la encapsulación y el cifrado.

La opción Create firewall rule crea reglas separadas con los prefijos Incoming y Outgoing en la parte superior de la lista. Después:

• Comprobar la posición de las reglas.
• Restringir Source y Destination.
• Reducir Any a los Services necesarios.
• Activar Log firewall traffic para la puesta en marcha y el análisis de errores.
• Seleccionar conscientemente IPS, Web, Application Control y otras Security Features.
• Asignar un nombre claro a la regla, por ejemplo LAN_to_Branch_Zurich.

Las reglas generadas se encuentran en el grupo Automatic VPN rules. En el ejemplo, la central permite tráfico saliente con Source zone LAN, Source network HQ_LAN, Destination zone VPN y Destination network Branch_LAN; para el tráfico entrante se invierten las zonas y las redes. En la sucursal se aplica la misma configuración especular, con Branch_LAN como red local. Limitar Services a los puertos de aplicación autorizados y activar Log firewall traffic. En lugar de crear reglas nuevas por cada túnel, pueden añadirse las redes Source/Destination correctas a reglas existentes adecuadas. Antes, comprobar el efecto sobre todas las demás conexiones cubiertas por esa regla. SFOS evalúa las reglas de arriba abajo y se detiene en la primera coincidencia; por tanto, una regla nueva al principio de la lista puede anular restricciones anteriores.

⚠️ 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, hay que reducir los servicios, Sources y Destinations después de la primera prueba.

Sophos no puede crear reglas automáticamente para route-based Any-to-Any. Con Dual, las reglas IPv4 e IPv6 se crean por separado. Si el tráfico de Internet de una sucursal debe pasar por la central, también se necesita un diseño NAT y de seguridad independiente.

Planificar NAT según el tipo de túnel

NAT no está prohibido con IPsec, pero debe tener un motivo claro. Los casos habituales son redes solapadas, requisitos cloud o direcciones de origen exigidas por terceros. NAT no sustituye una ruta ni modifica la decisión de routing: independientemente de la traducción, SFOS debe poder seleccionar una ruta VPN, estática, SD-WAN o dinámica adecuada.

Ruta de menú:

Rules and policies > NAT rules

Antes de crear una regla NAT deben responderse estas preguntas:

• ¿El peer espera direcciones IP originales o direcciones traducidas?
• ¿Hay redes solapadas?
• ¿NAT se configura en la conexión IPsec o mediante reglas NAT separadas?
• ¿Está documentada la dirección de retorno?
• ¿Log Viewer muestra la Source y Destination esperadas después de NAT?

La lógica NAT varía según el tipo de VPN:

• En IPsec policy-based y VPN route-based con Traffic Selectors, NAT para redes solapadas puede configurarse directamente en la conexión IPsec.
• En route-based Any-to-Any, se utilizan reglas SNAT y DNAT en Rules and policies > NAT rules.
• Con redes solapadas, ambos lados deben entender el mismo plan de traducción. Un NAT unilateral sin planificación de la ruta de retorno suele producir túneles verdes sin tráfico utilizable.

Para NAT dentro de la conexión IPsec, activar Network Address Translation (NAT). Translated subnet muestra la red local traducida seleccionada en la conexión; en Original subnet se selecciona la red local solapada real. Para las redes sin traducción, mantener Not translated. Antes de guardar, comparar en una tabla la red original, la red traducida, el selector Remote del peer y la dirección de destino DNS. No deducir la dirección de la traducción únicamente a partir de los nombres de los campos; el procedimiento NAT enlazado contiene el ejemplo completo. Para Any-to-Any, no utilizar estos campos como sustituto de reglas SNAT/DNAT separadas.

⚠️ En IPsec route-based con Traffic Selectors, usar el NAT de la conexión IPsec y no asignar una dirección IP ni una ruta manual a una interfaz XFRM si el build instalado la muestra. IPsec con NAT para redes solapadas muestra la configuración especular completa de direcciones, DNS y NAT.

Si el tráfico de una VPN route-based con Traffic Selectors coincide con una regla SNAT con Translated source = MASQ, el firewall descarta los paquetes porque estas interfaces XFRM no tienen direcciones IP asignadas. Esto puede explicar un túnel en verde sin tráfico utilizable. Para el flujo de prueba afectado, comprobar la regla NAT que coincide y su posición, y corregir únicamente la regla en conflicto; no desactivar MASQ de forma general para otras conexiones. Después, volver a comprobar el mismo flujo en ambos sentidos con Log Viewer y Packet Capture.

Si el tráfico útil de IPsec policy-based se traduce mediante una regla SNAT separada, su Outbound interface debe ser Any. Una regla limitada a puertos WAN concretos —normalmente la regla SNAT predeterminada— no se aplica a este tráfico VPN. Con Any, el firewall utiliza el valor de Translated source configurado en la regla SNAT correspondiente. Este comportamiento también se aplica cuando Override source translation (SNAT) está activado para interfaces de salida específicas.

Desde SFOS 22, IPsec policy-based crea la ruta VPN en el backend. Una ipsec_route manual no es un paso estándar, pero puede ser relevante para determinados escenarios de tráfico reenviado. Para las solicitudes de autenticación generadas por el sistema, los textos de ayuda de Sophos para SFOS 22 y SFOS 23 se contradicen: la descripción general de routing y NAT indica que este tráfico no necesita el comando; en cambio, las instrucciones de autenticación describen una excepción policy-based cuando la Route Precedence seleccionada no envía el tráfico al túnel. De ello no se deduce que haya que añadir una ruta para todo el tráfico del sistema ni modificar de forma general la Route Precedence global.

Antes de realizar un cambio, la dirección de origen, sys-traffic-nat, los Traffic Selectors y la ruta de retorno deben ser coherentes con el flujo de paquetes realmente observado. La guía existente sobre rutas IPsec y el procedimiento para las solicitudes de autenticación generadas por el sistema explican las comprobaciones específicas con una solicitud real y Packet Capture, así como el rollback por separado de NAT y de la ruta. Si el comportamiento en el build instalado sigue sin estar claro, debe aclararse con Sophos Support antes de realizar un cambio en producción. Consulte también Comprender las reglas NAT de Sophos Firewall.

Device Access para IPsec entrante

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

Ruta de menú:

Administration > Device access

IPsec debe estar permitido para WAN si el firewall acepta solicitudes entrantes, por ejemplo con Respond only. Esto no sustituye las reglas para el tráfico útil a través del túnel. Al mismo tiempo, hay que comprobar si WebAdmin, SSH, User Portal o VPN Portal están accesibles de forma demasiado amplia. Para endurecer estos servicios locales, consulte Proteger el acceso a Sophos Firewall: configurar correctamente Device Access.

Si un peer debe hacer ping al propio firewall a través del túnel, permitir la zona VPN en Ping/Ping6 y seleccionar Apply. Esto no es un paso global necesario para hacer ping a un host LAN: en ese caso cuentan las reglas de tránsito adecuadas y el firewall del host. Habilitar únicamente el servicio local necesario para la prueba, documentar su configuración original y restaurarla después de la prueba si no se necesita de forma permanente. Además, un ping desde la shell del firewall utiliza una dirección de origen distinta de la de un cliente LAN; no considerar ambas pruebas como verificaciones equivalentes de la regla del cliente.

Probar el túnel y solucionar errores

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

Definir una matriz de aceptación

Antes de la primera prueba debe definirse una pequeña matriz de aceptación. Así queda claro qué conexión debe funcionar y cuál debe permanecer bloqueada de forma intencionada.

Casos de prueba útiles:

• Red de clientes local hacia red de servidores remota: prueba habitual 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: probar solo si estos servicios deben pasar realmente por el túnel. Definir con precisión Source, servidor de destino y puerto.
• Monitoring o backup: comprobar si los sistemas previstos acceden desde la dirección correcta y no requieren por error reglas Any.
• Prueba bloqueada: un puerto o una red no autorizados expresamente deben bloquearse. De lo contrario, 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 la fragmentación.

Para cada caso de prueba deben anotarse Source IP, Destination IP, Service, regla de firewall esperada, regla NAT esperada y dirección esperada. Después de cada prueba se comparan Log Viewer, Packet Capture y los contadores de bytes. Si solo se prueba ping, el túnel aún no está aceptado.

1. Comprobar el estado

En la interfaz WebAdmin:

Site-to-site VPN > IPsec

Comprobar:

• La conexión está activa.
• El estado del túnel es established.
• Si hay varias redes, todas las Child SAs esperadas están establecidas.

En Current activities > IPsec connections solo se muestran las conexiones realmente establecidas. Los filtros son Connection name, Local server name, Local subnet, Username, Remote server/host y Remote subnet; Refresh actualiza la vista. Disconnect interrumpe una SA existente de forma controlada, por ejemplo cuando ambos lados están preparados para un cambio de configuración; no sustituye la desactivación ni el rollback de la conexión.

El número esperado se define antes de la prueba: route-based Any-to-Any crea una conexión Phase 2 por interfaz XFRM; Dual crea una para IPv4 y otra para IPv6. Policy-based y route-based con Traffic Selectors crean una conexión por cada combinación de Local y Remote subnet.

Antes del primer tráfico útil Any-to-Any, se comprueba el host de destino real en Diagnostics > Tools > Route lookup. En cada firewall, el resultado debe apuntar a la interfaz o al gateway XFRM previsto.

2. Comprobar Log Viewer

Ruta de menú:

Log viewer

Generar tráfico de prueba con Source, Destination y Service claros. Después, comprobar en Log Viewer qué regla de firewall coincide y si NAT, Webfilter, IPS u otros módulos influyen en el tráfico. El procedimiento se describe en Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture. Los rekeys, disconnects y errores de conexión recurrentes se comprueban en los logs de IPsec, no se deducen del estado actual de las SAs.

3. Packet Capture y Advanced Shell

Si Log Viewer no basta, debe utilizarse Packet Capture con un filtro restringido:

Diagnostics > Packet capture

Ejemplo de filtro:

host 172.16.10.25 and host 10.20.30.15

En el troubleshooting de VPN es importante comprobar ambas direcciones. Los paquetes salientes sin respuesta suelen indicar un problema de ruta de retorno, NAT o del peer.

Para el ejemplo coherente, probar desde el cliente LAN 10.10.10.25 un host de la sucursal que realmente exista, 10.20.20.15, no la dirección de red 10.20.20.0. En Windows, ping 10.20.20.15 -t inicia una prueba continua; finalizarla con Ctrl+C. En Diagnostics > Packet capture > Configure, configurar BPF string como host 10.10.10.25 and host 10.20.20.15 and proto ICMP, guardar y activar la captura. Con route-based, comprobar la salida por la interfaz XFRM correspondiente y los paquetes de retorno. En Log viewer, buscar la dirección real del cliente; abrir la regla que coincide mediante el ID de la regla de firewall y Filter firewall rule. Después, probar también un puerto de aplicación previsto y la dirección contraria. Desactivar de nuevo la captura y retirar los filtros y autorizaciones temporales; una captura continua no sustituye el monitoring operativo. Si hay un router delante del firewall, comprobar además en los logs de ambos peers que se haya detectado NAT y negociado NAT-T.

Advanced Shell

Para un troubleshooting más profundo mediante SSH, abrir 5. Device Management > 3. Advanced Shell y comprobar el estado actual de las SAs:

ipsec statusall

Entre otros, son relevantes:

• IKE SA established
• Child SA installed
• Traffic Selectors locales y remotos
• contadores de bytes en ambas direcciones

Si SSH todavía no está preparado, consulte Conectarse a Sophos Firewall mediante SSH.

Logs IPsec actuales

La vista actual de logs de SFOS 22 separa las funciones:

• strongswan.log: servicio IPsec y conexiones.
• charon.log: servicio IPsec y NAT en conexiones IPsec.
• ipsec_monitor.log: monitoring del servicio IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log: activación, desactivación y conexión mediante WebAdmin.
• xfrmi.log: interfaces XFRM en IPsec route-based.
• dgd.log: solo de forma adicional con failover VPN, SD-WAN, DGD o Link Load Balancing; no como log IPsec general.

Para un diagnóstico completo de logs y XFRM, consulte Sophos Firewall IPsec VPN Troubleshooting.

Errores habituales

• El túnel no se establece: probablemente no coinciden la versión IKE, el perfil, el PSK, el certificado, el Local ID o el Remote ID. Comprobar strongswan.log, el perfil IPsec y el peer.
• Phase 1 está activa, Phase 2 no: probablemente no coinciden las redes locales o remotas, o la Phase 2 proposal. Comprobar Traffic Selectors, subredes y PFS.
• El túnel está verde, pero no hay acceso: probablemente falta una regla de firewall, NAT, routing o la ruta de retorno. Comprobar Log Viewer, Packet Capture y routing.
• Solo funciona una dirección: el peer no conoce la ruta de retorno o NAT es incorrecto. Comprobar el peer, las reglas NAT y los contadores de bytes.
• Los pings pequeños funcionan, pero las aplicaciones se bloquean: probablemente intervienen MTU/MSS, fragmentación o una Security Feature. Comprobar MTU/MSS y Packet Capture.
• Route-based Any-to-Any no funciona: probablemente no coinciden la IP XFRM, el gateway, la ruta o la regla de firewall. Comprobar Network > Interfaces, routing y las reglas de zona VPN.
• Route-based con Traffic Selectors no funciona: comprobar la interfaz XFRM documentada bajo la Listening interface, la ruta automática, cada Child SA esperada, los Selectors, las reglas de zona VPN y una posible regla MASQ. Utilizar la interfaz XFRM para Packet Capture, pero no asignarle una dirección IP ni una ruta manual. Si falta, aclarar el build y la configuración en lugar de crear una interfaz de sustitución.
• Varios túneles se afectan entre sí: probablemente hay redes solapadas o configuraciones de Selectors similares. Comprobar los objetos de túnel, el failover group y las rutas.

Rollback tras una aceptación fallida

Un túnel nuevo se revierte de forma controlada, sin eliminar objetos por tanteo:

1. En Current activities > IPsec connections, desconectar la SA con Disconnect y desactivar la nueva conexión IPsec.
2. Desactivar solo las rutas estáticas o SD-WAN, reglas NAT y reglas de firewall creadas para este cambio, incluidas las reglas VPN automáticas. No eliminar por separado una interfaz XFRM generada si el build la muestra; la desactivación de la conexión gestiona esa interfaz.
3. En una migración, volver a asignar el perfil previo a la conexión anterior y, a continuación, reactivar la conexión y la ruta anterior.
4. Volver a probar el flujo original y el tráfico local de Internet o entre sedes con Log Viewer y Packet Capture.
5. Eliminar los objetos nuevos únicamente cuando Object Usage no muestre más dependencias y se haya demostrado que la ruta anterior vuelve a funcionar.

Eliminar una conexión guardada concreta

Eliminar una conexión IPsec guardada no equivale a Disconnect, desactivarla o eliminar un grupo de failover. Antes de una eliminación autorizada por separado, documentar el Name existente exacto, Object Usage, las pertenencias a grupos y un acceso de administración independiente del túnel. No eliminar una conexión mientras pertenezca a un grupo de failover; el procedimiento de failover enlazado explica cómo retirar la asignación de forma controlada.

La referencia de eliminación de la API XML de SFOS 22 y SFOS 23 define Name como ARRAY obligatorio de tipo STRING: primer carácter A-Za-z, siguientes A-Za-z0-9_, máximo 100 caracteres y varios valores permitidos. Sin embargo, no contiene un ejemplo de solicitud. No deducir un serializador de varios nombres ni un nombre de destino del ejemplo GUI branch-zurich; no modificar un nombre guardado para que parezca ajustarse a esos requisitos.

La referencia asocia el estado de operación XML 200 a Message.IPSecDeleteSuccess, 201 a Message.IPSecConnInUse y 500 a Message.IPSecDeleteFail. Los textos se insertan mediante JavaScript y no se han resuelto aquí: no son códigos de estado HTTP ni textos de respuesta mostrados que se hayan confirmado. No contabilizar 201 como eliminación correcta solo porque empieza por 2; en Edit, el mismo número corresponde a Message.IPSecUpdated. Después de una eliminación autorizada, volver a consultar exactamente ese destino y comprobar las rutas de producción restantes. Si el resultado no está claro, investigar el estado del destino y sus dependencias antes de reintentar, sin repetir a ciegas.

Checklist

Antes del cambio:

• Las redes locales y remotas son inequívocas.
• Se ha elegido conscientemente entre policy-based y route-based.
• El perfil IPsec está coordinado con el peer.
• El Preshared Key, los certificados o las claves RSA están documentados de forma segura.
• Las reglas de firewall están planificadas, incluida la dirección, posición, logging y servicios.
• Con Create firewall rule, está claro qué reglas creadas automáticamente deben revisarse.
• En route-based Any-to-Any están planificados la IP XFRM, el gateway, las reglas de firewall manuales y las rutas.
• En route-based con Traffic Selectors se ha documentado la visibilidad real de la interfaz XFRM; independientemente de lo que muestre la interfaz, no se prevén direcciones IP XFRM ni rutas manuales.
• NAT está excluido o documentado de forma deliberada.
• Se ha comprobado Device Access para IPsec entrante.
• Se conocen la ventana de mantenimiento, el peer y la ruta de fallback.

Después del cambio:

• El estado del túnel es established.
• La matriz de aceptación, con al menos una prueba por cada dirección necesaria, se ha ejecutado y superado.
• Log Viewer muestra la regla de firewall esperada.
• Packet Capture muestra el tráfico de ida y vuelta.
• Se han probado los accesos internos a DNS y aplicaciones.
• Los contadores de bytes aumentan en ambas direcciones.
• NAT y la ruta de retorno están coordinados con el peer.
• El cambio está documentado en la documentación de red.

Preguntas frecuentes