Meilleures pratiques pour les connexions IPsec

L'un des problèmes les plus courants lors de la configuration d'une connexion IPsec est une mauvaise configuration des paramètres IPsec. L'élément clé lors de la configuration d'un tunnel IPsec est de s'assurer que les paramètres correspondent à 100 % pour les deux pairs de connexion. Si les paramètres de configuration ne correspondent pas des deux côtés de la connexion, des problèmes de connectivité et de routage peuvent survenir. Dans certains cas, le tunnel peut s'établir, mais si le routage n'est pas correctement configuré, le trafic ne peut pas être envoyé via le tunnel.

Par conséquent, nous recommandons vivement de vérifier les paramètres IPsec sur votre appareil de périphérie (routeur, pare-feu, VM, etc.) avant de configurer les paramètres de connexion IPsec de Cato. Ensuite, utilisez exactement les mêmes paramètres pour configurer le site IPsec.

L'une des erreurs de configuration les plus courantes est l'utilisation d'un groupe Diffie-Hellman (DH) incompatible. Le groupe DH détermine le niveau de force des clés utilisées pour les messages d'authentification et d'initialisation entre les pairs de connexion. Si le groupe DH ne correspond pas aux deux côtés, le tunnel échoue à se connecter. Par conséquent, vous devez sélectionner le groupe DH qui correspond aux deux côtés de la connexion IPsec. Configurez le paramètre de groupe DH dans l'Application de Gestion de Cato qui correspond à la configuration de votre appareil de périphérie.

Une autre recommandation importante concerne les configurations qui utilisent PFS (Perfect Forward Secrecy) pour le renouvellement des clés. Lorsque le paramètre de groupe DH est défini sur None, le PFS est désactivé. Par conséquent, si vous activez le PFS, vérifiez que le groupe DH est configuré dans la section Auth Message Parameters.

La capture d'écran suivante montre un exemple de paramètres de message d'authentification et d'options de groupe DH :

Nous vous recommandons d'éviter d'utiliser des paramètres de chiffrement faibles si possible et d'utiliser un groupe DH plus élevé pour offrir un niveau de sécurité plus élevé.

Lorsque vous configurez le site dans l'Application de Gestion de Cato, si aucun groupe DH n'est configuré pour IKEv2 dans les Auth Message Parameters, un groupe DH peut encore apparaître dans les Init Message Parameters pour l'Association de Sécurité Enfant (SA). Ceci est dû au fait que le premier SA enfant est toujours créé lors de l'échange initial IKE_AUTH et utilise le même matériel de clé que le IKE SA. Le IKE SA utilise le groupe DH qui est configuré dans la section Init Message Parameters. Il n'y a pas d'échange de groupe DH dans le IKE_AUTH.

Si un groupe DH est configuré dans la section Auth Message Parameters, il n'est utilisé que lors des échanges CREATE_CHILD_SA qui créent soit des SA enfants supplémentaires, soit renouvellent les existants.

Un point à surveiller est la discordance des groupes DH configurés dans l'Application de Gestion de Cato et le pair IKEv2. Dans cette situation, le tunnel s'établit initialement après l'échange IKE_AUTH, mais échoue à se renouveler en utilisant l'échange CREATE_CHILD_SA. Il peut y avoir une brève interruption avant que les échanges IKE_SA_INIT et IKE_AUTH ne rétablissent le tunnel.

Il est très important d'utiliser le même algorithme de chiffrement pour les deux pairs de connexion. Parfois, les utilisateurs activent plusieurs algorithmes de chiffrement sur leurs appareils de périphérie au lieu de choisir un seul algorithme. L'activation de trop d'algorithmes prend plus de temps pour que l'appareil établisse la connexion. Par conséquent, nous vous recommandons de n'activer que l'algorithme que vous utilisez des deux côtés du tunnel : moins c'est mieux.

Pour les sites IPsec avec une bande passante supérieure à 100 Mbps, utilisez uniquement les algorithmes AES 128 GCM-16 ou AES 256 GCM-16. Les algorithmes AES CBC sont uniquement utilisés sur les sites avec une bande passante inférieure à 100 Mbps.

Nous vous recommandons de configurer à la fois des connexions IPsec primaires et secondaires pour la redondance. De plus, vous devriez utiliser des adresses IP sources différentes et des PoPs de destination différents pour les connexions. En cas d'échec de connexion d'une source ou d'une destination, et que le tunnel tombe, le second tunnel passe le trafic à l'autre PoP. Si vous configurez la même adresse IP source pour les connexions primaires et secondaires et que cette IP source présente une défaillance, aucune autre connexion n'est disponible pour transférer le trafic.

Cato prend en charge à la fois IKEv1 et IKEv2 pour la négociation entre les deux pairs de connexion. Lorsque vous créez un site IPsec dans l'Application de Gestion de Cato, sélectionnez la version de l'Internet Key Exchange (IKEv1 ou IKEv2) qui correspond à votre appareil de périphérie. Si IKEv2 est pris en charge, alors généralement nous recommandons de l'utiliser. Cependant, certains appareils ne prennent pas en charge les mêmes paramètres IKEv2 qui sont disponibles dans l'Application de Gestion de Cato. Dans ce cas, utilisez IKEv1 à la place. Par exemple, si votre pare-feu ne prend pas en charge le chiffrement AES CBC 256, ne l'utilisez pas dans votre configuration IPsec. Pour plus d'informations sur IKEv1 et IKEv2, voir Guide IPsec de Cato : IKEv1 vs IKEv2

Si vous avez activé un site IKEv2, nous recommandons vivement de sélectionner l'option Démarrer la connexion par Cato. Dans la plupart des cas, les appareils de périphérie sont configurés avec un long délai entre les tentatives de reconnexion. Lorsque ces appareils initient la connexion, le processus de négociation VPN prend beaucoup de temps. En revanche, lorsque Cato initie la connexion, la négociation est beaucoup plus rapide.

La capture d'écran suivante montre l'option d'initiateur IKEv2 :

Les configurations IPsec pour les différents VPN des fournisseurs de cloud peuvent être incompatibles. Chaque fournisseur de cloud (par exemple : Amazon AWS, Microsoft Azure ou GCP) utilise différentes paramètres de configuration par défaut pour les tunnels IPsec. Vérifiez la configuration IPsec de votre fournisseur de cloud et utilisez une configuration qui correspond au site IPsec de Cato.

Remarque: Si vous modifiez les paramètres IPsec par défaut du cloud, n'oubliez pas d'utiliser les mêmes paramètres dans les paramètres du site IPsec de l'Application de Gestion de Cato.

Par exemple, Azure gère le PFS différemment selon qu'il est initiateur ou répondant pour une SA enfant (ESP SA). Lorsqu'il est initiateur, Azure n'envoie pas de groupe DH par défaut. Lorsqu'il est répondant, Azure accepte un groupe DH du pair. Cela signifie que si un groupe DH est configuré dans la section Auth Message Parameter dans l'Application de Gestion de Cato et qu'Azure tente de créer un ESP SA en utilisant l'échange CREATE_CHILD_SA, Cato répond avec "Aucune proposition choisie" et le SA échoue à s'établir. Cependant, si Cato initie l'échange CREATE_CHILD_SA, l'ESP SA s'établit si le groupe DH configuré est accepté par Azure en tant que répondant. Par conséquent, pour garantir une compatibilité maximale avec Azure, définissez soit le groupe DH sur None dans la section Auth Message Parameter de la configuration du site IKEv2, soit configurez une politique personnalisée dans Azure qui spécifie le même groupe PFS que le groupe DH configuré dans l'Application de Gestion de Cato.

La capture d'écran suivante montre un exemple de configuration personnalisée d'Azure :

Pour plus d'informations sur les paramètres VPN d'Azure, consultez À propos des appareils VPN et des paramètres IPsec.

Cato Networks vous permet de sélectionner des paramètres Automatiques pour les Init et les Paramètres de message d'authentification IKEv2, tels que les algorithmes de cryptage, RPF et d'intégrité. Si vous rencontrez des problèmes de connectivité ou de routage lors de l'utilisation de la configuration automatique, nous vous recommandons de sélectionner exactement la configuration qui correspond aux paramètres de votre appareil de périphérie et d'éviter d'utiliser Automatique.

Cependant, pour les sites configurés avec GCM pour l'algorithme de cryptage (AES GCM 128 ou AES GCM 256), alors l'algorithme d'intégrité n'est pas pertinent car GCM fournit également l'intégrité. Lorsque vous sélectionnez un algorithme de cryptage AES GCM, l'algorithme d'intégrité est défini sur Automatique.