Prácticas recomendadas para conexiones IPsec

Uno de los problemas más comunes al configurar una conexión IPsec es la configuración incorrecta de las configuraciones IPsec. El elemento clave al configurar un túnel IPsec es asegurarse de que las configuraciones coincidan al 100% para ambos pares de conexión. Si las configuraciones de configuración no coinciden para ambos lados de la conexión, pueden ocurrir problemas de conectividad y enrutamiento. En algunos casos, el túnel puede establecerse, pero si el enrutamiento no está configurado correctamente, el tráfico no puede ser enviado a través del túnel.

Por lo tanto, recomendamos enfáticamente que verifique las configuraciones IPsec en su dispositivo de borde (enrutador, cortafuegos, VM, etc.) antes de configurar las configuraciones de conexión IPsec de Cato. Luego use las mismas configuraciones exactas para configurar el sitio IPsec.

Uno de los errores de configuración más comunes es usar un grupo Diffie-Helman (DH) incompatible. El grupo DH determina el nivel de fuerza de las claves utilizadas para los mensajes de autenticación e inicio entre los pares de conexión. Si el grupo DH no coincide en ambos lados, el túnel falla al conectar. Por lo tanto, debe seleccionar el grupo DH que coincida en ambos lados de la conexión IPsec. Configure el parámetro de grupo DH en la Aplicación de Gestión de Cato para que coincida con la configuración de su dispositivo de borde.

Otra recomendación importante es para configuraciones que usan PFS (Perfect Forward Secrecy) para renovación de claves. Cuando el parámetro de grupo DH está configurado en None, el PFS está desactivado. Por lo tanto, si está habilitando el PFS, verifique que el grupo DH esté configurado en la sección Auth Message Parameters.

La siguiente captura de pantalla muestra un ejemplo de parámetros de mensaje de autenticación y opciones de grupo DH:

Recomendamos que evite usar configuraciones de cifrado débiles si es posible y utilice un grupo DH más alto para proporcionar un mayor nivel de seguridad.

Cuando configure el sitio en la Aplicación de Gestión de Cato, si no se configura un grupo DH para IKEv2 en los Auth Message Parameters, un grupo DH aún puede aparecer en Init Message Parameters para la Asociación de Seguridad Infantil (SA). Esto se debe a que el primer SA infantil siempre se crea en el intercambio inicial de IKE_AUTH y utiliza el mismo material de clave que el IKE SA. El IKE SA utiliza el grupo DH que está configurado en la sección Init Message Parameters. No hay intercambio de grupo DH en el IKE_AUTH.

Si un grupo DH está configurado en la sección Auth Message Parameters, solo se usa durante los intercambios de CREATE_CHILD_SA que crean SA infantiles adicionales o se reutilizan existentes.

Algo a tener en cuenta es que los grupos DH configurados en la Aplicación de Gestión de Cato y el par IKEv2 no coincidan. En esta situación, el túnel se establece inicialmente después del intercambio IKE_AUTH pero falla al reutilizar usando el intercambio CREATE_CHILD_SA. Puede haber una breve interrupción antes de que los intercambios IKE_SA_INIT e IKE_AUTH vuelvan a establecer el túnel.

Es muy importante usar el mismo algoritmo de cifrado para ambos pares de conexión. A veces los usuarios habilitan múltiples algoritmos de cifrado en sus dispositivos de borde en lugar de elegir un solo algoritmo. Habilitar demasiados algoritmos lleva más tiempo para que el dispositivo establezca la conexión. Por lo tanto, recomendamos que habilite solo el algoritmo que usa en ambos lados del túnel: menos es mejor.

Para sitios IPsec con ancho de banda superior a 100Mbps, use solo los algoritmos AES 128 GCM-16 o AES 256 GCM-16. Los algoritmos AES CBC solo se utilizan en sitios con ancho de banda inferior a 100Mbps.

Recomendamos que configure tanto conexiones IPsec primarias como secundarias para redundancia. Además, debería usar diferentes direcciones IP de origen y diferentes PoPs de destino para las conexiones. En caso de que una fuente o destino falle en conectar y el túnel se caiga, el segundo túnel pasa el tráfico al otro PoP. Si configura la misma dirección IP de origen en ambas conexiones primarias y secundarias y esta dirección IP de origen tiene una falla, no hay otras conexiones disponibles para pasar el tráfico.

Cato admite tanto IKEv1 como IKEv2 para la negociación entre los dos pares de conexión. Cuando cree un sitio IPsec en la Aplicación de Gestión de Cato, seleccione la versión de Intercambio de Claves de Internet (IKEv1 o IKEv2) compatible que coincida con su dispositivo de borde. Si se admite IKEv2, generalmente recomendamos usarlo Sin embargo, algunos dispositivos no admiten los mismos parámetros de IKEv2 disponibles en la Aplicación de Gestión de Cato. En ese caso, use IKEv1 en su lugar. Por ejemplo, si su cortafuegos no admite el cifrado AES CBC 256, no lo use en su configuración de IPsec. Para más información sobre IKEv1 e IKEv2, consulte Guía IPsec de Cato: IKEv1 vs IKEv2

Si tiene un sitio IKEv2 habilitado, recomendamos encarecidamente que seleccione la opción Iniciar conexión por Cato. En la mayoría de los casos, los dispositivos de borde están configurados con un retraso largo entre los intentos de reconexión. Cuando estos dispositivos inician la conexión, el proceso de negociación VPN toma mucho tiempo. En contraste, cuando Cato inicia la conexión, la negociación toma mucho menos tiempo.

La siguiente captura de pantalla muestra la opción de iniciador IKEv2:

Las configuraciones IPsec para diferentes VPN de proveedores de nube pueden ser incompatibles. Cada proveedor de nube (por ejemplo: Amazon AWS, Microsoft Azure o GCP) utiliza diferentes configuraciones predeterminadas para los túneles IPsec. Verifique la configuración IPsec de su proveedor de nube y utilice una configuración que coincida con el sitio IPsec de Cato.

Nota: Si cambia las configuraciones predeterminadas de IPsec en la nube, recuerde usar las mismas configuraciones en las configuraciones del sitio IPsec de la Aplicación de Gestión de Cato.

Por ejemplo, Azure maneja el PFS de manera diferente dependiendo de si es el iniciador o respondedor de una SA Infantil (ESP SA). Cuando es el iniciador, Azure no envía un grupo DH por defecto. Cuando es el respondedor, Azure acepta un grupo DH del par. Esto significa que si un grupo DH está configurado en la sección Auth Message Parameter en la Aplicación de Gestión de Cato y Azure intenta crear un ESP SA usando el intercambio CREATE_CHILD_SA, Cato responde con "No se eligió propuesta" y el SA no logra establecerse. Si Cato inicia el intercambio CREATE_CHILD_SA, sin embargo, el ESP SA se establece si el grupo DH configurado es uno que Azure acepta como respondedor. Por lo tanto, para asegurar la máxima compatibilidad con Azure, ya sea que configure el grupo DH a None en la sección Auth Message Parameter de la configuración del sitio IKEv2 o configure una política personalizada en Azure que especifique el mismo grupo PFS que el grupo DH configurado en la Aplicación de Gestión de Cato.

La siguiente captura de pantalla muestra un ejemplo de configuración personalizada de Azure:

Para más información sobre parámetros de VPN de Azure, consulte Acerca de los dispositivos VPN y parámetros IPsec.

Cato Networks le permite seleccionar parámetros Automáticos para los Init y Auth Message Parameters de IKEv2, como algoritmos de cifrado, RPF y algoritmos de integridad. Si experimenta problemas de conectividad o enrutamiento al usar la configuración automática, recomendamos que seleccione exactamente la configuración que coincide con la configuración de su dispositivo de borde y evite usar Automático.

Sin embargo, para sitios configurados con GCM para el algoritmo de cifrado (AES GCM 128 o AES GCM 256), entonces el algoritmo de integridad no es relevante porque GCM también proporciona integridad. Cuando selecciona un algoritmo de cifrado AES GCM, el algoritmo de integridad se establece en Automático.