FortiClient bloqué à 98 % : désactivez IPv6 sur cet adaptateur

La barre atteint 98 %, le client reste là, et ressaisir le mot de passe ne change rien. C'est l'indice utile : le client a déjà accepté le certificat de la passerelle, envoyé les identifiants et reçu une configuration de tunnel. Ce qui reste, c'est de monter l'adaptateur virtuel et de confirmer que le tunnel transporte du trafic. Quand cette dernière étape ne se termine jamais, la panne est locale, et aucune ressaisie d'identifiants ne l'atteint.

Quatre étapes, et la première consiste à lire le journal plutôt que la barre.

Ce que le compteur de 98 % signale réellement

Le pourcentage est le compteur d'étapes du client lui-même, pas une mesure de débit. Un blocage au même nombre à chaque tentative signifie que le client atteint une étape précise et attend ; c'est pourquoi une connexion lente et un client bloqué se distinguent dans le journal. Un problème d'identifiants afficherait une erreur d'identifiants au lieu d'une pause silencieuse.

Fortinet a documenté ce symptôme face à une cause côté client : IPv6 activé sur l'adaptateur utilisé par le client. Cela fait du réglage de l'adaptateur la première chose à tester, et non une explication universelle pour chaque SSL-VPN blocage.

Étape 1 : lisez le journal avant la barre

Avant de changer quoi que ce soit, capturez les lignes juste avant le blocage. Vous cherchez à savoir si l'adaptateur de tunnel a été créé, si une adresse a été attribuée et si le client a cessé d'attendre une famille d'adresses. Un blocage à un autre pourcentage est une autre étape avec son propre diagnostic, et un avertissement de certificat ou une mauvaise adresse de passerelle produit son propre message au lieu d'une attente silencieuse. Notez l'horodatage, car la tentative suivante ajoute un autre bloc au même fichier.

Si le journal montre une connexion terminée suivie de rien, vous êtes dans la configuration locale et l'adaptateur est un suspect légitime.

Étape 2 : limitez le changement IPv6 à un seul adaptateur

Le changement concerne l'adaptateur, pas la machine. Dans les propriétés de l'adaptateur Windows, cela signifie décocher Internet Protocol Version 6 (TCP/IPv6) sur l'interface concernée, et depuis un shell c'est Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Confirmez l'état avec Get-NetAdapterBinding -ComponentID ms_tcpip6 avant de vous reconnecter. Reconnectez-vous ensuite et regardez si la barre dépasse 98 % au lieu de s'y arrêter.

Délimitez d'abord, testez ensuite. Désactiver IPv6 globalement est un changement plus large que ce que la question exige et cela touche des services que vous ne vouliez pas modifier.

Étape 3 : vérifiez ce que le blocage masquait

Un tunnel qui se connecte n'est pas un tunnel qui fonctionne. Vérifiez l'adresse attribuée par le client, les routes installées par le profil et la résolution de noms pour un hôte interne : Resolve-DnsName files.corp.example. Un client qui se connecte et ne résout rien a un problème DNS, et c'est facile à mal interpréter comme le retour de la même panne.

Testez une ressource interne par son nom et une destination publique, pour qu'un tunnel divisé cassé ne soit pas pris pour un client réparé.

Étape 4 : rendez le correctif reproductible

Si le réglage doit atteindre un parc, mettez-le dans le paquet de déploiement ou dans la configuration de l'adaptateur plutôt que dans une étape manuelle répétée sur chaque portable. Notez dans le ticket que le blocage à 98 % était lié à IPv6 sur l'interface réseau, et indiquez ce d'autre sur l'hôte dépendait d'IPv6 avant que quelqu'un le réactive pour corriger autre chose.

Un correctif qui n'existe que dans la mémoire d'un ingénieur est un correctif qui revient au trimestre suivant.

Si la barre s'arrête encore à 98 % avec IPv6 désactivé, la note du fournisseur ne l'explique plus et le journal est votre prochaine preuve. Arrêtez de traiter le symptôme et revenez au compteur d'étapes.