TL;DR : si t'as un boîtier VPN Cisco ASA ou Fortinet qui ne fonctionne plus (établissement du VPN bloqué à 98 %) ou qui fonctionne partiellement (quand il est établit, des sites web ne s'affichent plus, des connexions SSH ne s'établissent plus) lorsqu'il est utilisé avec un partage d'une connexion 4G Bouygues pro et que tu n'as pas déployé IPv6 sur ton réseau (côté serveur VPN, donc), alors tu as un problème de MTU lié aux mécanismes de traduction IPv6<>IPv4 (NAT64, DNS64, 464XLAT, etc.). Je n'explique pas cela puisque la traduction IPv4->IPv6 consomme seulement 20 à 28 octets supplémentaires alors qu'il m'a fallu descendre la MTU de 114 octets. Nous constaterons, sans savoir l'expliquer, que la MTU possible à l'intérieur d'un même VPN établi au-dessus d'une traduction IPv6<>IPv4 diffère entre la version 7 et la version 9 d'Android. Peut-être que tous ces problèmes résident dans la manière dont Android gère le partage de connexion (genre filtrage excessif d'ICMPv6) ? Configurer, sur un Cisco ASA, une MTU de 1288 octets à l'intérieur des VPN TLS corrige le tir. Pas d'idée pour Fortinet. OpenVPN sur UDP n'est pas impacté (TCP non testé). :)
Nous avons un boîtier VPN Cisco ASA que nous utilisons pour établir des VPN TLS. En octobre 2019, un collègue informaticien en déplacement établit une connexion VPN en utilisant le client libre openconnect
sur son ordinateur GNU/Linux raccordé à Internet via le partage Wi-Fi de connexion 4G de son ordiphone professionnel. Il ne parvient pas à accéder à l'interface web de notre Mattermost (Slack-like libre et auto-hébergé) ni à d'autres sites web internes (nous ne permettons pas d'accéder à Internet à travers notre VPN). Il ne parvient pas non plus à se connecter en SSH à plusieurs de nos serveurs : il n'a pas la demande de saisie du mot de passe (le déploiement de l'authentification par clé progresse lentement…). En revanche, ça fonctionne pour d'autres serveurs. Tous les serveurs testés sont dans le même réseau et une même règle de filtrage est appliquée par notre pare-feu en ce qui concerne SSH et le web. Il peut ping
les serveurs avec lesquels il ne peut pas établir de session SSH.
J'emprunte son ordiphone, j'active le partage de connexion, et je reproduis le problème avec mon ordinateur GNU/Linux. Un coup de wireshark
est sans appel : il s'agit d'un problème de MTU. Je t'ai déjà expliqué ce qu'est la MTU, son origine et les problèmes associés. Quand tu essayes d'accéder à une ressource web, que la poignée de main TCP se passe bien, mais que le navigateur web ne reçoit plus de réponse du serveur web après lui avoir envoyé une requête GET, c'est très souvent un problème de MTU. Et pour le comportement de SSH ? J'ai mis du temps à comprendre. Il était possible d'établir une session SSH avec de vieux serveurs (Debian 8 ou inférieur), mais pas avec des serveurs Debian 9. Wireshark montrait un blocage dès la poignée de main SSH (quand le client et le serveur s'échangent leur bannière). Le paquet « Key Exchange Init » du serveur n'arrivait jamais au client. Normal, SSH sur Debian 9 propose plus de suites de chiffrement, donc le paquet SSH « Key Exchange Init » est plus gros (1076 octets contre 948 octets).
Comment expliquer ce changement de MTU ? Rancid montre aucun changement dans la configuration de notre boîtier VPN depuis des années. Même chose côté routage et pare-feu (mais s/années/mois/). Je suis étonné que personne se soit plaint plus tôt. Je pense à un problème partiel visant uniquement certains équipements. J'emprunte l'ordiphone d'une collègue, partage de connexion, tout ça, et là, ça fonctionne. Le client VPN est le même (openconnect sur mon ordinateur GNU/Linux), donc il est à exclure. Le boîtier VPN est identique, donc il est à exclure. Il reste le réseau entre les deux. Un des ordiphones fonctionne avec Android (marche pas), l'autre avec IOS (marche). L'un utilise un forfait Bouygues pro (marche pas), l'autre un forfait Orange perso (marche). Il y a donc quelque chose avec Android + Bouygues Pro.
Intuitivement (on verra plus loin que je bluffe), je pense au déploiement d'IPv6 sur le réseau Bouygues. Sur le moment, je trouve, sur le web, un article qui expose que, bien que Bouygues a proposé IPv6 très tôt (mi-2017), l'opérateur était en train de le forcer progressivement comme protocole réseau par défaut. Évidemment, à l'heure de rédiger ce shaarli, je ne retrouve pas ledit article, graaah. :( IPv6 n'est pas du tout déployé dans mon organisation (oui, je sais, je sais… On ne déploiera pas dans les prochaines années :( ). Donc, depuis un réseau IPv6, une connexion à notre serveur VPN utilise forcément un mécanisme de traduction IPv6<>IPv4 mis en place par l'opérateur (Bouygues, Orange, Free, SFR, etc.).
À titre de comparaison, l'ARCEP, l'autorité administrative de régulation des télécoms, nous informe que, sur les offres mobiles, Bouygues est le principal acteur a avoir activé IPv6 à la mi-2019 (configuration automatique et à distance des ordiphones par l'opérateur pour ce faire) et que la majorité des offres mobiles à mi-2019 sont uniquement IPv6, ce qui suppose un mécanisme de traduction. Dans ces documents de l'ARCEP, on lit qu'Orange a fait un effort pour activer IPv6 sur les iPhone en septembre/octobre 2019, donc que mon test Android versus IOS aurait pu échouer.
Je désactive IPv6 sur l'ordiphone : Paramètres -> Connexions -> Réseaux mobiles -> Nom des points d'accès -> cliquer sur le seul APN proposé -> Protocole APN -> Changer la valeur d'IPv6 à IPv4. Je réactive le partage de connexion, je monte le VPN ASA et… tout fonctionne. Je retire le VPN, je désactive le partage de connexion, je réactive IPv6 sur l'ordiphone, j'active à nouveau le partage de connexion et le VPN : les problèmes reviennent. La cause du changement de la MTU est donc bien liée à IPv6 et à l'utilisation d'un mécanisme de traduction IPv6<>IPv4 sur nos forfaits mobiles Bouygues Pro. C'est difficile à croire, puisque NAT64 implique une surcharge de 20 ou 28 octets seulement et uniquement dans le sens IPv4->IPv6, mais les faits sont là…
Actuellement, la MTU appliquée à l'intérieur de nos VPN ASA est de 1406 octets. J'identifie la nouvelle MTU avec ping -M do -s <taille_variante_en_octets> <destination>
(avec le VPN établi, donc). La nouvelle MTU est de 1352 octets. Pour l'appliquer, il faut aller dans ASDM -> Configuration -> Remote Access VPN -> Network (Client) Access -> Group Polices -> double-cliquer sur un groupe -> Advanced -> AnyConnect client -> champ « MTU ».
Je croyais en avoir terminé, mais non. Quelques jours plus tard, un autre collègue informaticien me rapporte ne pas avoir pu se connecter à certains de nos serveurs via le VPN sur un partage de connexion 4G. Il a un ordiphone Android et le même forfait mobile Bouygues pro que le collègue précédent. Ça devrait donc fonctionner !
Je teste avec mon ordinateur et son ordiphone : en effet, ça ne fonctionne pas. J'identifie la MTU : 1288 octets. Je désactive IPv6 sur son ordiphone et ça fonctionne. Je configure cette nouvelle MTU dans notre Cisco ASA, je ré-active IPv6 sur l'ordiphone, et ça fonctionne. Puisque le forfait mobile est identique et que les ordiphones sont de même marque (Samsung), je regarde les versions d'Android : ce collègue a Android 9. Le premier a Android 7. Entre la version 7 et la version 9 d'Android, y a-t-il un réglage différent côté partage de connexion ou une implémentation différente de la traduction d'adresses IPv6<>IPv4 en lien avec l'opérateur ? Aucune idée. :- Je n'arrive pas à expliquer cette différence. J'arrive encore moins à expliquer comment l'activation d'IPv6 sur Android 9 peut faire perdre 114 octets de MTU (1406-1288).
Parallèlement à ces ennuis du quotidien, je testais un produit Fortinet avec le premier ordiphone décrit ci-dessus (Android 7, donc). Aucun souci en partage de connexion 4G avec openfortivpn
(implémentation libre d'un FortiClient VPN pour GNU/Linux vu la déplorable implémentation digne d'un étudiant en première année d'informatique livrée par Fortinet). Aucun souci avec l'application mobile officielle pour Android. En revanche, impossible d'établir le VPN depuis un ordinateur winwin 7 ou 10 : FortiClient VPN reste bloqué à 98 % de l'établissement de la connexion avant de revenir au formulaire identifiant+mdp sans afficher un quelconque message d'erreur (classe pour un produit professionnel, non ?). Notre intégrateur Fortinet ne nous a pas proposé de solution.
En désactivant IPv6 sur l'ordiphone, cela fonctionne. Le VPN met longtemps à s'établir, plus de 30 secondes, mais il fonctionne. Donc, on est toujours face à la même cause. Pourquoi le client GNU/Linux fonctionne-t-il ? Probablement pas la même implémentation. L'implémentation libre utilise PPP sur TLS sur TCP. Qu'utilise la privatrice ? TCP, mais après ? En revanche, l'application officielle qui fonctionne sur Android nous oblige à constater que l'origine de tous les problèmes décrits dans ce shaarli pourrait être du côté Android, de son implémentation du partage de connexion 4G, et pas du côté de l'opérateur. Un changement de paramètre côté Android ou quelque chose du genre.
Parallèlement, je testais une solution PFSense+OpenVPN. Force est de constater qu'OpenVPN, dans une configuration UDP (TCP non testé), n'a pas bronché, même sur un partage de connexion 4G avec IPv6 activé. C'est même son journal détaillé qui m'a mis sur la piste IPv6 puisqu'il affichait un « UDP link remote » suivi d'une IPv6 fabriquée par DNS64 reconnaissable par son préfixe « 64:ff9b:: » réservé à l'IANA.