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 crear el túnel como cliente hacia una sede central con acceso público estable, 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 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. Las versiones actuales de SFOS separan estos términos con más claridad que las guías antiguas, que a veces todavía hablan de Site-to-Site o Tunnel Interface.

• IPsec policy-based: es adecuado para conexiones sencillas entre sedes con redes locales y remotas claramente definidas. Se controla principalmente mediante las subredes locales y remotas de la conexión IPsec y las reglas de firewall. Sophos crea túneles Phase 2 separados para las combinaciones de subredes locales y remotas.
• IPsec route-based con Traffic Selectors: también usa subredes locales y remotas, pero crea una interfaz XFRM propia. Sophos crea la ruta automáticamente; no deben asignarse una dirección IP ni rutas propias a la interfaz XFRM. Esta variante no admite WAF.
• IPsec route-based Any-to-Any: es la opción más flexible para redes en crecimiento, SD-WAN, routing dinámico y diseños dual-stack. Las rutas y las reglas de firewall, y no las subredes de la conexión IPsec, deciden qué paquetes entran en el túnel.

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.

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.

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

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.

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. Una CA pública no debe utilizarse de forma general como Remote CA Certificate, ya que se confiaría demasiado en certificados ajenos. RSA key es un Authentication type independiente: ambos firewalls intercambian sus claves públicas y deben usar el mismo formato PKCS1 o DNS.

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 la CA revoca certificados antes de que expiren, la lista de revocación actual también debe formar parte del plan operativo. El procedimiento independiente describe la importación de CRL, nextUpdate y una 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 IPsec_IKEv2_AES256_G14. 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.

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

En IPsec policy-based, como máximo uno de los lados de los Traffic Selectors puede estar configurado como Any. Si hay varias redes locales y remotas específicas, Sophos crea una Phase 2 SA para cada combinación.

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.

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.

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.

Configurar IPsec route-based

IPsec route-based separa la negociación VPN y la ruta de datos mediante una interfaz XFRM propia. El hecho de direccionar y enrutar manualmente esta interfaz depende de la variante elegida.

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

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

Network > Interfaces

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

Any-to-Any y Dual

Si ambas subredes están configuradas como Any o se usa Dual, la interfaz XFRM recibe una dirección IP de transferencia. A continuación requiere una ruta estática, SD-WAN Route o una ruta dinámica mediante BGP u OSPF. Con Dual se necesitan reglas de firewall IPv4 e IPv6 separadas.

Las rutas y las reglas de firewall deciden 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 de la contraparte y se utiliza en una SD-WAN Route.

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 tres puntos:

1. La interfaz XFRM aparece en Network > Interfaces y tiene asignada la dirección IP de transferencia prevista.
2. La ruta hacia la red remota apunta directamente a la interfaz XFRM o, en un diseño con Gateway/SD-WAN, al XFRM Gateway correspondiente.
3. Las reglas de firewall solo permiten las direcciones y los servicios previstos.

Traffic Selectors

Con Local y Remote subnets específicos, Sophos también crea una interfaz XFRM, pero no deben asignarse a esta interfaz una dirección IP ni rutas propias. La ruta estática se crea automáticamente en cuanto el túnel está established. No se admite Any solo en un lado y un selector específico en el otro.

Esta variante es adecuada para redes pequeñas y claramente definidas, y simplifica el diagnóstico XFRM. Sin embargo, no se admite WAF a través de IPsec route-based con Traffic Selectors.

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.

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 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 terceros que solo aceptan determinadas direcciones de origen.

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.

⚠️ En IPsec route-based con Traffic Selectors, la interfaz XFRM no tiene dirección IP. Si este tráfico coincide con una regla MASQ SNAT, el firewall descarta los paquetes. Para redes solapadas, debe utilizarse el ajuste NAT de la conexión IPsec y comprobar que ninguna regla MASQ SNAT coincida con este tráfico.

Desde SFOS 22, IPsec policy-based crea la ruta VPN en el backend. Una ipsec_route manual solo es relevante para determinados tipos de tráfico traducido y reenviado y no es un paso estándar; el tráfico generado por el sistema no la necesita. Más información básica sobre NAT en 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.

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.

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.

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: no configurar una IP ni una ruta manual en la interfaz XFRM. Comprobar la ruta automática, los Selectors, las reglas de zona VPN y una posible regla MASQ.
• 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.

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 no están previstas una IP ni rutas manuales en la interfaz XFRM.
• 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.
• Se ha definido una matriz de aceptación con al menos una prueba por cada dirección necesaria.
• 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