Bonjour,
je suis de retour.
Je suis perdu sur ce sujet et j’espère trouver de l’aide.
Pour mon organisation, j’ai configuré un VPN IKEv2 sur notre pare-feu. Et cela semblait fonctionner correctement, tous mes collègues l’utilisent sans problème. Mais il y a quelques jours, un de nos utilisateurs m’a approché pour me demander quand leur problème serait « enfin résolu ».
Quel problème ? Je n’étais pas au courant qu’il y en avait un.
Nous avons eu quelques coupures majeures d’Internet il y a trois semaines, mais elles ont été résolues par notre fournisseur d’accès. Mais depuis lors, leurs connexions VPN tombent régulièrement, toutes les 1-2 heures. Les utilisateurs pensaient que ces deux problèmes étaient liés d’une manière ou d’une autre.
Alors que Windows leur indique toujours que la connexion VPN est établie, le pare-feu a déjà décidé de couper la connexion, probablement à cause du DeadPeerDetection.
Je ne sais pas exactement à qui demander. Le pare-feu est un FortiGate. Le système d’exploitation est Windows, et le profil VPN est configuré dans Intune.
Quelqu’un aurait-il un conseil pour moi ? Qu’est-ce qui peut causer un tel comportement ?
Avez-vous rekey=yes ?
Avez-vous ikelifetime=VALUE EN HEURES ?
Il est possible que les valeurs par défaut soient non et 1 heure.
ETA : Vérifiez aussi les paramètres personnels du système de l’utilisateur. J’ai eu un utilisateur qui avait configuré une déconnexion automatique par défaut toutes les 15 minutes si aucune trafic dirigé n’était détecté.
Vous naviguez un peu à l’aveugle sans journaux. Si c’est juste un personne, cela vient probablement de leur connexion Internet.
Vérifiez s’ils utilisent un service 4G/5G et aussi quel routeur ils ont.
Certains activent l’inspection des paquets, mais généralement ce n’est pas appelé comme ça dans les options.
Les services non 4G/5G peuvent aussi avoir ce genre de routeurs.
De plus, - ikev2 peut rencontrer des problèmes lors de la renegociation du tunnel sur les connexions cellulaires. Consultez la documentation Fortinet sur la fragmentation MTU de IKEv2 IPsec. Mais d’abord, vérifiez la connexion Internet / routeur de vos clients.
Ça semble prometteur.
Je n’ai pas beaucoup expérimenté avec l’intervalle de rekey.
Je dois d’abord vérifier comment cette option est appelée sur notre pare-feu.
Je suppose que c’est « Autokey Keep Alive » et « Key Lifetime » qui est actuellement réglé sur 43200 secondes (12 heures).
Est-ce trop ? Probablement.
Je devrais peut-être essayer de le réduire et voir l’impact.
Malheureusement, il est difficile de localiser précisément ce problème. Le pare-feu ne me permet de lancer qu’un journal de débogage de 30 minutes. Et il n’est pas garanti que je capture l’erreur durant cette période.
Les VPN IPSec ont deux phases et chacune a des minuteries de rekey, où ils renégocient de nouvelles clés pour l’encryption, afin que les clés ne deviennent pas ‘périmées’. Les valeurs de rekey ne doivent pas nécessairement correspondre des deux côtés, elles doivent juste convenir que les autres valeurs sont correctes.
La phase 1 (IKEv2) est l’endroit où ils conviennent d’un ensemble d’algorithmes pour communiquer en toute sécurité (échange Diffie-Hellman) et ils se connectent en toute sécurité (c’est un ensemble de clés). Ensuite, ils négocient en toute sécurité les paramètres pour la phase 2, qui dans laquelle toutes les données sont cryptées (c’est un second ensemble de clés).
Après un certain temps présélectionné ou si des données ont été transférées, CE CÔTÉ du tunnel tentera une rekey.
Voici où votre problème pourrait se situer : si votre serveur VPN tente de rekey en premier, il enverra un paquet à (peut-être) un routeur de modem câblé, qui le laissera sûrement tomber. C’est un paquet entrant sans session sortante correspondante, car la session sortante datait de 24 heures lorsque votre utilisateur s’est connecté pour la première fois à domicile.
Ce que vous pouvez essayer, c’est de configurer le timer de rekey sur le CLIENT VPN, pour les deux phases, pour qu’ils soient plus courts que ceux du serveur VPN. De cette façon, la tentative de connexion sortante du client ne devrait pas être bloquée.
Vous pouvez aussi tester si c’est le problème en modifiant un peu les timers maintenant, pour voir si cela raccourcit ou allonge le temps avant que cet utilisateur ne se déconnecte. Une nouvelle connexion doit être établie après que les timers aient été modifiés.