Configurar perfiles IPsec Sophos Firewall con seguridad

Un perfil IPsec determina con qué seguridad y bajo qué condiciones se negocia un túnel IPsec. Define la versión IKE, el cifrado, la integridad, el grupo DH, PFS, las duraciones de las claves, la renovación de claves y Dead Peer Detection. Si estos valores no coinciden con los de la contraparte, el túnel no se establece o falla durante una renovación posterior.

Recomendación rápida para nuevas conexiones Site-to-Site: utilizar IKEv2, ofrecer solo las combinaciones robustas que sean realmente necesarias, activar PFS y la renovación de claves y configurar DPD según la función del firewall. Si ambos extremos lo admiten, AES256GCM16 con el grupo 19 (ecp256) para DH y PFS es el punto de partida moderno que propone Avanet. No es un valor predeterminado de Sophos ni una recomendación general del fabricante; prevalecen los requisitos de la contraparte.

Este artículo explica el perfil. La conexión propiamente dicha, con Gateway, IDs, redes, reglas, NAT y Routing, se describe en Configurar una VPN IPsec Site-to-Site en Sophos Firewall. Si un túnel existente no se establece o no transporta tráfico, consulte Solución de problemas de VPN IPsec en Sophos Firewall.

Qué controla un perfil IPsec

El perfil reúne los parámetros de seguridad comunes a Phase 1 y Phase 2 y puede asignarse a varias conexiones. Antes de modificarlo, hay que comprobar qué conexiones lo utilizan. En vez de cambiar directamente un perfil de sistema o producción compartido, se clona y la copia se prueba primero solo con la conexión prevista.

El perfil no incluye:

dirección pública o FQDN de la contraparte
Preshared Key, certificado o RSA Key
Local ID y Remote ID
redes locales y remotas o Traffic Selectors
reglas de firewall, NAT y Routing
dirección XFRM, SD-WAN Route o ruta de Failover

Estos valores se configuran en la conexión IPsec o en las reglas de red asociadas. Por tanto, un estado verde de Phase 1 no demuestra que Phase 2 coincida ni que el tráfico útil se enrute y permita correctamente.

Authentication no es lo mismo que Authentication type

En un perfil IPsec, Authentication designa el algoritmo de integridad, como SHA2 256. En la conexión IPsec, Authentication type determina si las contrapartes se identifican mediante Preshared Key, certificado o RSA Key.

Estos dos campos realizan tareas diferentes. Por tanto, un SHA2 256 correcto no corrige un PSK incorrecto y un certificado válido no compensa una Proposal de Phase 1 incompatible.

Phase 1 y Phase 2 explicadas

Phase 1 establece la IKE Security Association protegida. A través de este canal de control, las contrapartes se autentican y negocian las demás claves y parámetros. Como mínimo, deben ser compatibles la versión IKE, el cifrado, la integridad y el DH Group.

Phase 2 crea las Child o IPsec Security Associations para el tráfico útil. Aquí se aplican el cifrado de Phase 2, la integridad, PFS y los Traffic Selectors. Por ello, un túnel puede completar Phase 1 correctamente y, sin embargo, no crear ninguna Child SA debido a un valor PFS incorrecto o a una combinación de Phase 2 diferente.

Con IKEv2, la primera Child SA puede establecerse junto con la IKE SA. Según la contraparte, un problema de PFS o de renovación puede no aparecer hasta que la Child SA se renueve mediante CREATE_CHILD_SA. Avanet recomienda observar al menos una renovación de Phase 2 durante las pruebas de aceptación.

Coordinar los parámetros con la contraparte

Antes de configurar, ambos administradores acuerdan y documentan los valores por escrito. Una captura de pantalla suele ser insuficiente porque los fabricantes utilizan nombres diferentes para una misma función.

Como mínimo, deben documentarse estos datos:

función: Initiator, Responder o establecimiento desde ambos lados
versión IKE y, con IKEv1, Main o Aggressive Mode
Phase 1 Encryption, Authentication y DH Group
Phase 1 Key Life, Re-key Margin y aleatorización
Phase 2 Encryption, Authentication, PFS y Key Life
Rekeying basado en tiempo y qué lado lo inicia
intervalo DPD y acción cuando la contraparte no está disponible
límites conocidos del proveedor y Proposals permitidas

El nombre del perfil no tiene que ser idéntico en ambos dispositivos; lo importante es que al menos una combinación completa sea compatible en ambos lados. Las propuestas innecesarias dificultan la coordinación y pueden aumentar sin necesidad el tamaño de los paquetes IKE. El efecto concreto del problema conocido NC-136352 en SFOS se explica más adelante, junto a los campos de Phase 1.

Elegir una configuración inicial segura

Los siguientes ejemplos son puntos de partida de Avanet para nuevas conexiones Site-to-Site. No sustituyen los requisitos de Azure, AWS, un operador o un firewall de terceros. Muestran deliberadamente solo la selección de propuestas y funciones, no un perfil completo: las duraciones, Re-key Margin, el intervalo DPD y su acción dependen de la contraparte y del papel de Initiator o Responder.

Perfil moderno para contrapartes controladas

Si ambos lados admiten algoritmos actuales:

Key exchange: IKEv2
Phase 1: AES256GCM16, 19 (ecp256)
Phase 2: AES256GCM16, 19 (ecp256)
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 es un algoritmo AEAD: cifra y protege la integridad en una sola operación. Para esta combinación, SFOS no selecciona ningún algoritmo Authentication adicional como SHA2.

La Pseudo-Random Function para generar claves IKE no puede seleccionarse por separado en SFOS. El firewall la deriva de los algoritmos de integridad ofrecidos y la coordina con la contraparte.

El grupo 19 (ecp256) utiliza una curva elíptica. Para contrapartes actuales y controladas, Avanet lo prefiere a los grupos MODP más antiguos. AES128GCM16 también es un algoritmo vigente. La política criptográfica aplicable y el componente más débil del perfil determinan qué combinación es válida.

Perfil compatible sin AES-GCM o ECP

Si la contraparte no admite AES-GCM o no admite un grupo ECP, Avanet utiliza esta combinación más extendida como punto de partida compatible:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

A diferencia de las entradas AES-GCM, en SFOS AES256 se configura con el algoritmo Authentication independiente SHA2 256. DH14 y PFS14 son opciones de compatibilidad de Avanet, no la variante moderna preferida cuando ambas contrapartes admiten el grupo 19 (ecp256).

Evitar en perfiles nuevos

DES no figura entre los algoritmos IPsec compatibles con SFOS 22. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 y los grupos DH 1, 2 y 5 siguen siendo seleccionables, pero no deben usarse en perfiles nuevos. PFS: None también debe quedar reservado como excepción documentada para contrapartes que no admitan PFS.

A pesar de aparecer en el campo Phase 2 Encryption, AES-GMAC no cifra, sino que solo proporciona autenticación e integridad. Por tanto, un túnel Site-to-Site confidencial normal utiliza AES-GCM o AES con un algoritmo SHA2 adecuado.

En SFOS 22 y 23, las opciones documentadas dependen de la versión IKE y de la fase:

AES128GCM16, AES192GCM16 y AES256GCM16: en Phase 1 de IKEv2 y en Phase 2 de ambas versiones IKE, no en Phase 1 de IKEv1.
AES128GMAC, AES192GMAC y AES256GMAC: solo en Phase 2 de ambas versiones IKE, no en Phase 1.
TwoFish y Serpent: en Phase 1 y Phase 2 de IKEv1, no de IKEv2.

Son algoritmos seleccionables, no combinaciones vinculadas a grupos DH o algoritmos hash concretos, ni recomendaciones para perfiles nuevos.

Las excepciones Legacy se documentan con su motivo, la contraparte afectada, el riesgo, el Owner y la fecha de sustitución. Una combinación débil no debe permanecer junto a Proposals robustas únicamente porque el túnel también puede establecerse con ella. La BSI TR-02102-3 sobre IPsec e IKEv2 y la guía de NIST sobre VPN IPsec ofrecen orientación técnica.

Si un entorno debe cumplir requisitos criptográficos formales, el procedimiento específico explica cómo el modo FIPS 140-3 en Sophos Firewall afecta a plataformas, perfiles, certificados, backups y HA. El cumplimiento FIPS no sustituye la selección consciente de una proposal común y moderna.

Límites de la documentación antigua de la API VPNProfile

Al automatizar perfiles, no se debe interpretar la documentación XML antigua de Add VPN Policy / Edit VPN Policy (VPNProfile) como una traducción directa de esta guía de la interfaz. En KeyingMethod distingue entre Automatic y Manual. La rama manual con LocalSPI, RemoteSPI y claves de cifrado y autenticación de entrada/salida es una variante independiente de gestión de claves heredada: esas claves no son campos PSK de la conexión IPsec ni una receta alternativa para el ejemplo moderno de IKEv2. Ni el antiguo ejemplo DES/MD5 ni la lista de algoritmos demuestran compatibilidad actual o aprobación para perfiles nuevos.

La descripción de la API para SFOS 22 y 23 también contiene contradicciones que deben aclararse para la compilación concreta antes de automatizar:

PerfectForwardSecrecy indica Enable como valor predeterminado, pero la lista de valores permitidos solo admite y/n y el campo falta en el ejemplo XML. Esto no permite deducir una serialización fiable; no se debe convertir sin más Enable en y.
PFSGroup muestra SameAsPhase1 en el ejemplo, pero SameasPhase-I en la lista de valores permitidos. No se debe deducir la escritura a partir de la etiqueta de la interfaz ni tratar ambos literales como intercambiables.
AuthenticationAlgorithm1 figura como obligatorio en ambas fases, aunque la lista Encryption incluye GCM. Esto no aclara el caso AEAD en la API: no se debe forzar un hash adicional con GCM solo para completar el campo obligatorio.
KeyLife se define como un entero en segundos, mientras que el ejemplo contiene 3600 seconds. No se debe serializar el sufijo de texto como parte del valor de la API.

Hasta aclarar estos detalles de la API para la compilación instalada, el procedimiento admitido en la interfaz bajo Profiles > IPsec profiles sigue siendo la vía segura. Siguen vigentes las propuestas robustas, la clonación antes de los cambios, la comprobación tras una renovación y la vuelta al perfil anterior documentado. Aquí no se proporciona ningún payload XML ejecutable para los campos contradictorios.

Eliminar un perfil: comprobar el nombre y conocer los límites

La descripción general de la API antigua incluye Delete VPN Policy además de Add/Edit. Esta tarea se dirige al perfil IPsec indicado por su nombre, no a la desconexión de una conexión VPN. La descripción de Delete para SFOS 22 y 23 exige Name como parámetro obligatorio de tipo SCALAR y tipo de datos STRING; las palabras del nombre pueden separarse con espacios. Se trata del nombre del perfil que se quiere eliminar, no de la dirección de la contraparte ni del nombre de la conexión.

Antes de eliminarlo, hay que comprobar el nombre exacto del perfil y todas sus asignaciones, incluidas las de Site-to-Site, Remote Access y L2TP. Se documentan los valores y las asignaciones actuales para poder planificar la recuperación. Si el perfil sigue en uso o sus asignaciones no están claras, no se elimina; primero se aclara la migración prevista de las conexiones afectadas. No se elimina un perfil solo para desconectar un túnel o deshacer un cambio de perfil fallido: sigue siendo válido el procedimiento de recuperación descrito arriba, utilizando el perfil anterior.

La escueta documentación de Delete no proporciona una solicitud XML completa y ejecutable ni explica cómo gestiona el firewall los perfiles que siguen en uso o qué efecto tiene la eliminación en las conexiones activas. Enumera 200 y 500, pero el texto disponible no contiene los mensajes correspondientes. No se deducen de ello respuestas concretas ni reglas de éxito, error o dependencias. Por tanto, la eliminación automatizada queda suspendida hasta aclarar el formato de la solicitud y el comportamiento para la compilación instalada; aquí no se proporciona ningún payload de Delete.

Clonar o crear un perfil

Ruta de menú:

Profiles > IPsec profiles

Para conexiones Sophos con Sophos, los perfiles de sistema emparejados sirven como plantillas comprensibles:

Branch office (IKEv2) para la sucursal que inicia la conexión
Head office (IKEv2) para la central que responde

Se clona el perfil adecuado y se le asigna un nombre claro, por ejemplo Branch-Zurich-IKEv2. De este modo, el perfil de sistema permanece sin cambios y durante un Rollback puede volver a asignarse al túnel su perfil anterior.

General settings

Key exchange: utilizar IKEv2 para nuevas conexiones Site-to-Site. Utilizar IKEv1 solo para una contraparte Legacy documentada.
Authentication mode: solo existe para IKEv1. No utilizar Aggressive Mode porque, según Sophos, la información de autenticación se transmite en texto claro.
Key negotiation tries: Este campo define el número de intentos de negociación del intercambio de claves del túnel antes de que el firewall deje de intentarlo. Sophos recomienda 0. Sin embargo, en un VPN Failover Group, SFOS establece el valor efectivo en 3.
Re-key connection: activar para negociar nuevas claves de Phase 1 y Phase 2 antes de que caduquen. SFOS solo admite Rekeying basado en tiempo. Desactivar esta opción impide que el firewall local inicie la renovación, pero aún puede responder a solicitudes de renovación de la contraparte. La contraparte debe entonces iniciarla; la renovación permanece activada en al menos uno de los lados.
Use strict profile: activar cuando se conocen exactamente las Proposals de la contraparte. De este modo, SFOS solo ofrece los parámetros configurados. En perfiles de proveedores, comprobar primero sus requisitos; por ejemplo, el ejemplo oficial de AWS no utiliza esta opción.
Pass data in compressed format: Avanet suele dejar esta opción desactivada. Solo debe activarse si la contraparte admite IPComp y el ahorro de ancho de banda compensa la complejidad añadida.
SHA2 with 96-bit truncation: Esta opción acorta los valores hash HMAC de autenticación. activar solo por un requisito de compatibilidad documentado, no como mejora general de seguridad.

Use strict profile excluye del intercambio IKE los valores predeterminados del sistema que no estén configurados y puede ayudar con propuestas IKE demasiado grandes. Sin embargo, no es una opción que deba activarse sin comprobar en todos los perfiles de proveedor.

Phase 1

Phase 1 contiene Key life, Re-key margin, Randomize re-keying margin by, el DH Group y hasta tres pares de Encryption y Authentication. Introducir aquí Key life y Re-key margin en segundos. En Aggressive Mode solo puede guardarse una combinación Encryption/Authentication por fase; la advertencia contra este modo sigue vigente.

No debe elegirse sin más el valor máximo que acepte el campo. Re-key Margin debe ser considerablemente menor que Key Life y ajustarse al comportamiento de la contraparte; la aleatorización solo modifica este margen.

Solo se introducen los DH Groups y Proposals que sean realmente necesarios. El problema conocido NC-136352 puede producirse cuando un perfil IKEv2 predeterminado ofrece tantos DH Groups que el paquete IKE supera los 1500 bytes. Si un componente intermedio descarta los fragmentos, el Initiator transmite repetidamente mientras el Responder no ve nada. Para una contraparte conocida, un único DH Group confirmado es la configuración más limpia.

Phase 2

Phase 2 contiene PFS, Key Life, Encryption y Authentication para el tráfico útil. Esta fase también permite hasta tres combinaciones Encryption/Authentication. Introducir su propia Key life de Phase 2 en segundos. Los ajustes de renovación configurados en Phase 1, incluidos el margen y la aleatorización, también determinan los tiempos de renovación de Phase 2; no obstante, Phase 2 conserva su propia Key Life.

PFS fuerza un nuevo intercambio de claves DH durante el Rekeying de Phase 2. Si posteriormente se compromete una clave de larga duración, se pretende evitar que sesiones antiguas grabadas puedan descifrarse con el mismo material de claves. Por ello, se activa PFS y se selecciona un valor compatible con la contraparte. En perfiles modernos, el PFS Group suele coincidir con el DH Group de Phase 1.

En Use PFS group, Same as phase 1 utiliza los grupos DH seleccionados en Phase 1 para la negociación de Phase 2. Elegir un grupo explícito establece directamente el grupo DH de Phase 2; None desactiva PFS. Heredar los mismos grupos no significa que PFS requiera un número de grupo distinto.

Sophos recomienda elegir una Key Life de Phase 2 más corta que la Key Life de Phase 1. De este modo, las claves del tráfico útil se renuevan con mayor frecuencia que el canal de control IKE.

Dead Peer Detection

DPD detecta una contraparte que deja de responder. No sustituye ni a Gateway Monitoring ni a una prueba real de aplicaciones. Si el túnel de Phase 2 ha estado inactivo, DPD comprueba la disponibilidad de la contraparte antes de enviar datos.

Sucursal o Initiator: Re-initiate, para que el firewall intente inmediatamente un nuevo establecimiento tras un DPD Timeout. El número de intentos de Re-initiate depende de Key negotiation tries.
Central o Responder: Disconnect, para cerrar la conexión obsoleta. Hold es una alternativa deliberada cuando deben mantenerse los Traffic Selectors y la renegociación solo debe comenzar al llegar tráfico nuevo.
Check peer after every: intervalo de comprobación en segundos.
Wait for response up to: solo actúa con IKEv1. Con IKEv2, SFOS utiliza el IKE Retransmission Timeout interno; el valor introducido no modifica este comportamiento. Con IKEv1, el número de comprobaciones depende del tiempo de respuesta configurado aquí.

En los IPsec Failover Groups, SFOS desactiva DPD para las conexiones asignadas y establece Key negotiation tries en 3. La condición del grupo se encarga entonces de la supervisión. La guía enlazada explica el orden, la Failover Condition y Automatic failback; la vista del Profile por sí sola no muestra todo el comportamiento de Failover efectivo.

Interpretar correctamente Lifetimes y Rekeying

Key life no es un Session Timeout ni un Idle Timeout. Limita la duración de una Security Association. Antes de que caduque, la negociación de nuevas claves comienza dentro del Re-key Margin.

Las Lifetimes más cortas renuevan las claves con mayor frecuencia, pero provocan más carga de cálculo y más oportunidades para errores de interoperabilidad o Rekeying. Las Lifetimes más largas reducen esta carga, pero utilizan el material de claves durante más tiempo. Por tanto, ni el valor más corto ni el más largo permitido es automáticamente la mejor elección.

NIST SP 800-77r1 recomienda 24 horas para la IKE SA y 8 horas para la IPsec SA. Son recomendaciones de NIST independientes del fabricante, no valores predeterminados de SFOS. Sophos y los proveedores de nube utilizan otros valores según la función y la plataforma.

Sophos recomienda lo siguiente para evitar colisiones de Rekeying:

La Key Life del Initiator es más corta que la del Responder.
La Key Life de Phase 2 en ambos firewalls es más corta que la Key Life de Phase 1.
Rekeying está activado en al menos uno de los lados y utiliza expresamente Rekeying basado en tiempo con dispositivos de terceros.

La aleatorización modifica el Re-key Margin, no la Key Life completa. Con una Key Life de ocho horas, un Margin de diez minutos y una aleatorización del 20 por ciento, Sophos indica que el Rekeying comienza entre las 7 horas y 48 minutos y las 7 horas y 52 minutos.

Para proveedores, se utilizan sus valores exactos. En Sophos Firewall, el ejemplo documentado de AWS utiliza una Key Life de Phase 1 de 28000, un Re-key Margin de 360 y una aleatorización del 50 por ciento; Phase 2 utiliza 3600 segundos. Este es un ejemplo de AWS, no un valor predeterminado general de Avanet.

Asignar y probar el perfil de forma segura

Durante una ventana de mantenimiento, el nuevo perfil se asigna primero únicamente a la conexión prevista. Antes del cambio se documentan el nombre del perfil, los valores anteriores y el Rollback.

Para Site-to-Site, la asignación se realiza en:

Site-to-site VPN > IPsec

Remote Access IPsec también utiliza perfiles, pero tiene otros límites: la configuración actual de Sophos Connect acepta perfiles IKEv1 con DPD desactivado o configurado como Disconnect. Por ello, el moderno perfil IKEv2 para Site-to-Site no se reutiliza sin comprobarlo en Remote Access. El procedimiento completo se describe en Configurar Sophos Connect en Sophos Firewall. El caso específico de OTP y Rekeying se explica en Sophos Connect desconecta la conexión después de unas cuatro horas.

Los perfiles también se aplican en Remote access VPN > L2TP. L2TP utiliza Preshared Key o certificado digital y no admite IKEv2. Por tanto, el punto de partida moderno de Site-to-Site no puede aplicarse a L2TP.

Una vez establecida la conexión, Avanet utiliza en Advanced Shell únicamente los siguientes comandos de consulta para comprobar el estado y los últimos mensajes IKE:

ipsec statusall
tail -n 200 /log/strongswan.log

A continuación se prueba tráfico real en ambos sentidos. Los contadores de bytes de la Child SA deben aumentar. La prueba se repite después de al menos una renovación de Phase 2. Solo este paso adicional de aceptación de Avanet comprueba también las duraciones, PFS y el comportamiento de renovación.

Causas típicas según el síntoma:

El túnel no llega a establecerse: comprobar la versión IKE, Phase 1 Encryption, Authentication, DH, Strict Profile, ID y la autenticación de la contraparte.
NO_PROPOSAL_CHOSEN antes de Phase 1: comparar las Proposals de Phase 1.
Phase 1 está activa, pero falta la Child SA: comprobar Phase 2 Encryption, Authentication, PFS y Traffic Selectors.
Desconexión tras un intervalo similar: comparar Key Life, Re-key Margin, aleatorización y valores de Initiator y Responder.
El túnel está verde, pero no pasa tráfico: no modificar primero el perfil; comprobar las reglas de firewall, NAT, Routing, la ruta de retorno y los contadores de bytes.

Si el cambio causa problemas, se vuelve a asignar a la conexión el perfil anterior documentado. Para esta reversión no es necesario realizar cambios en Advanced Shell.