Meilleures pratiques pour les sites IPsec - Migration vers IKEv2
En général, Cato recommande d'utiliser des sites IPsec IKEv2 comme meilleure pratique. Voici quelques-unes des améliorations apportées par IKEv2 :
IKEv2 accroît l'efficacité en réduisant le nombre de messages à échanger pour établir un tunnel VPN. Les tunnels sont mis en place plus rapidement et avec moins de bande passante.
IKEv2 est plus fiable. Il existe une vérification d'activité intégrée dans IKEv2 pour détecter quand le tunnel se déconnecte.
IKEv2 protège contre les attaques DoS. Contrairement à IKEv1, un répondant IKEv2 ne doit pas effectuer de traitement considérable tant que l'initiateur n'a pas prouvé qu'il peut recevoir des messages à son adresse IP annoncée.
NAT-T est intégré. NAT-T, ou NAT Traversal, est requis lorsqu'un point de terminaison VPN se trouve derrière un routeur qui effectue du NAT. Les tunnels IPsec transmettent les données en utilisant la charge utile de sécurité encapsulante (ESP), ce qui n'est pas compatible avec le NAT. Ainsi, le NAT-T est utilisé pour encapsuler les paquets ESP dans UDP qui peuvent alors être routés sur NAT.
Pour plus d'informations sur les avantages d'utiliser des sites IPsec IKEv2, consultez RFC 4306.
Similitudes entre IKEv2 et IKEv1
Ci-dessous, une comparaison des configurations strongSwan pour les tunnels IKEv1 et IKEv2. strongSwan est une solution IPsec open-source pour plusieurs systèmes d'exploitation, notamment Windows et macOS.
IKEv1 | IKEv2 |
| |
La seule différence est un seul nombre. Changer la valeur keyexchange de ikev1 à ikev2 est suffisant pour convertir strongSwan de IKEv1 à IKEv2.
Note : Vous pouvez définir le secret partagé IPSec (PSK) jusqu'à 64 caractères pour les sites IKEv1 et IKEv2.
Passage d'IKEv1 à IKEv2 dans l'application de gestion Cato
Les étapes nécessaires pour migrer d'un tunnel IKEv1 à IKEv2 sont listées ci-dessous.
Pour migrer un site d'un tunnel IKEv1 à IKEv2 :
Sur l'écran Réseau > Sites, sélectionnez le site que vous souhaitez passer d'IKEv1 à IKEv2.
Sur l'écran Réseau > Sites > [nom du site] > Configuration du site > Général, dans la liste déroulante Type de connexion, sélectionnez IPsec IKEv2. La Plage native du site et d'autres réseaux sont perdus lorsque vous changez le Type de connexion.

Sur l'écran Réseau > Sites > [nom du site] > Configuration du site > Réseaux, entrez la Plage native et tous les autres réseaux distants. Ce sont les sélecteurs de trafic distant.
Sur l'écran Réseau > Sites > [nom du site] > Configuration du site > IPsec, sous la section Primaire, sélectionnez l'IP Cato IP (Sortie) et entrez l'IP du site de la passerelle VPN distante.

Entrez le PSK dans le champ Mot de passe sous PSK primaire.

Développez la section Routage, ajoutez l'option de routage pour le site sous Plages de réseau. Ceux-ci devraient être tous des réseaux déjà configurés sur d'autres sites connectés à Cato ou la plage VPN de Cato.
,.mj
Cochez la case Initier la connexion par Cato pour que Cato initie la connexion VPN. Cette configuration est facultative mais recommandée car la passerelle VPN distante peut ne pas être configurée pour initier la connexion.
(Facultatif) Développez la Section des paramètres du message d'initiation et configurez les paramètres. Comme la plupart des solutions prenant en charge IPsec IKEv2 implémentent une négociation automatique des paramètres Init et Auth suivants, Cato recommande de les définir sur Automatique sauf instruction contraire de votre fournisseur de Pare-feu.
Vous avez peut-être remarqué que les paramètres de message Init et Auth sont presque identiques aux paramètres de Phases 1 et 2 de IKEv1, mais il existe une option de configuration pour l'algorithme PRF et l'intégrité dans IKEv2. La plupart des fournisseurs ne supportent pas les algorithmes PRF et d'intégrité différents, donc en cas de doute, définissez-les sur Automatique ou assurez-vous qu'ils sont définis sur la même valeur.
Cliquez sur Enregistrer.
IKEv2 : La dernière frontière
De nos jours, il n'y a vraiment qu'une seule raison de fêter comme si c'était 1999, ou plus précisément 1998, lorsque IKEv1 a été défini par l'IETF : si au moins un côté de la connexion VPN se termine sur un appareil hérité qui ne supporte que IKEv1. Les principaux fournisseurs de cloud (AWS, GCP, Azure, Alibaba Cloud) supportent IKEv2. Ainsi, sauf si vous vous connectez à un ancien point de terminaison VPN, IKEv2 devrait être votre premier choix lors de la configuration des tunnels VPN.