Quel est le meilleur VPN compatible IPv6 ? Celui qui ne laisse pas une deuxième route contourner le tunnel

Tout fonctionnait, et c’est précisément ce qui m’a inquiété. Mon VPN affichait « connecté », le fichier de travail que je devais envoyer progressait normalement et mon adresse IPv4 appartenait bien au serveur que j’avais choisi.

Par habitude, j’ai quand même ouvert un test d’adresse avant de valider l’envoi. La première ligne était celle que j’attendais. La seconde beaucoup moins : une longue adresse IPv6 appartenant toujours à mon fournisseur d’accès français.

Mon premier réflexe a été de penser à une vieille information mise en cache par le navigateur. J’ai ouvert une fenêtre privée, relancé le test, puis essayé dans un autre navigateur.

Même résultat.

IPv4 : VPN.

IPv6 : ma connexion fibre.

Le tunnel n’était donc pas complètement cassé. C’était justement le piège : il faisait assez bien son travail pour paraître normal.

Rien dans l’icône verte ne m’aurait poussé à chercher plus loin.

IPv6 n’est plus le détail que je pouvais ignorer sur une box française

Quelques années plus tôt, j’aurais probablement désactivé IPv6 et oublié le problème.

En 2026, cette solution ressemble davantage à un contournement qu’à une vraie réponse.

Le baromètre publié par l’Arcep le 16 juillet montre à quel point la situation française a changé. Fin 2025, 94 % des clients fixes grand public et 83 % des clients mobiles avaient déjà IPv6 activé. Sur le fixe, Free atteignait 99 %, Orange 97 % et Bouygues Telecom 96 %.

Autrement dit, pour beaucoup d’utilisateurs français, IPv6 n’est plus une option exotique cachée au fond de la box. Il fait simplement partie de la connexion.

Le plus simple est d’imaginer que mon ordinateur possède désormais deux portes vers Internet. L’une est IPv4, l’autre IPv6. Sur une connexion « dual stack », les deux restent disponibles et l’appareil emprunte celle qui convient au service qu’il contacte. C’est aujourd’hui une manière courante de faire cohabiter les deux générations du réseau.

Mon VPN avait fermé et redirigé la première porte.

La deuxième était encore ouverte.

RFC 7359 décrit exactement ce genre de situation : lorsqu’un VPN dirige correctement IPv4 dans son tunnel mais ne prend pas correctement en charge IPv6, une partie du trafic peut continuer à utiliser directement le réseau local.

Ce qui m’a dérangé n’était donc pas de découvrir un problème technique rare.

C’était de comprendre qu’il pouvait rester parfaitement invisible tant que je ne regardais que mon IPv4.

Je n’avais même pas besoin d’un test IP pour finir par le remarquer

C’est aussi pour cela que je ne considère plus cette fuite comme une curiosité réservée aux gens qui aiment examiner leurs tables de routage.

Dans une discussion publique sur r/VPN, un utilisateur avait configuré plusieurs appareils de streaming pour passer par un VPN avec une IPv4 statique. Il ne s’est aperçu que quelque chose clochait qu’après des problèmes avec la notion de « foyer » d’un service de streaming. En récupérant les données associées à son compte, il a découvert qu’un appareil arrivait bien avec l’IPv4 prévue, tandis que d’autres étaient vus avec différentes adresses IPv6 publiques.

C’est le genre de problème qui change complètement la manière de regarder le bouton « connecté ».

Le VPN peut sembler fonctionner. Le service peut s’ouvrir. Et pourtant, une deuxième route continue d’exister à côté du tunnel.

Dans mon cas, j’avais eu la chance de la voir avant d’envoyer le fichier.

Je voulais maintenant la supprimer sans transformer mon ordinateur en projet réseau du dimanche soir.

Mon grand VPN m’a donné beaucoup de choses à essayer, sauf le résultat que je voulais

J’utilisais mon fournisseur habituel depuis assez longtemps pour lui faire confiance. L’application était mature, le choix de serveurs énorme et les réglages bien plus détaillés que ceux dont j’avais besoin au quotidien.

J’ai commencé par changer de serveur.

Nouvelle IPv4.

Même IPv6 de mon fournisseur.

J’ai changé de protocole.

Nouvelle connexion.

Même résultat.

À ce stade, passer de Paris à Amsterdam ou Londres n’avait plus beaucoup de sens. Je pouvais déplacer la première porte autant que je voulais ; la seconde restait ouverte à côté.

J’ai donc appliqué la solution la plus directe : désactiver IPv6 sur l’interface réseau.

Le résultat a été immédiat.

Je me suis reconnecté au VPN, j’ai refait le test et l’adresse IPv6 de ma fibre avait disparu.

Techniquement, la fuite n’existait plus.

Mais j’avais obtenu ce résultat en retirant IPv6 de la connexion.

C’est là que mon idée d’un VPN « compatible IPv6 » a changé.

RFC 7359 traite justement la désactivation d’IPv6 comme une solution temporaire lorsqu’un client VPN ne sait pas gérer correctement ce trafic. La correction propre consiste à prendre en charge IPv6 lui-même et à faire suivre le trafic par la route attendue.

Je ne voulais donc plus d’un VPN qui devenait étanche une fois IPv6 supprimé.

Je voulais laisser ma fibre fonctionner normalement, activer le VPN et ne plus avoir à me demander laquelle des deux portes Internet venait de rester ouverte.

Pour le test suivant, j’ai volontairement remis IPv6

J’ai réactivé IPv6 exactement comme avant.

Puis j’ai ouvert la petite application que je gardais installée comme solution secondaire.

Son interface ne m’a pas renvoyé vers une immense carte de serveurs. J’ai choisi le mode de confidentialité et laissé le service établir sa route.

Premier test : l’IPv4 avait changé.

Je suis descendu jusqu’à la ligne qui avait déclenché toute cette histoire.

L’adresse IPv6 de mon fournisseur n’était plus exposée.

Je n’avais rien désactivé dans Windows.

Je n’avais rien modifié dans ma box.

Je n’avais pas transformé ma connexion IPv6 en connexion IPv4 pour que le VPN paraisse propre.

Cette fois, les deux portes étaient prises en charge.

Je ne voulais pourtant pas m’arrêter à une page de diagnostic. Une fuite IP bien corrigée ne m’aurait servi à rien si le travail qui m’attendait cessait de fonctionner.

J’ai donc rouvert le portail, repris le transfert dans l’application de bureau et attendu.

Le fichier est parti.

La progression a continué.

Puis l’écran de confirmation est apparu.

C’était finalement le test le plus simple de toute la soirée : laisser IPv6 actif, connecter le VPN, vérifier que l’adresse de mon opérateur ne réapparaissait plus, puis terminer la tâche réelle.

Un précédent test du service avait déjà montré le même comportement dans un autre environnement : après établissement de la connexion, le contrôle IPv6 ne montrait plus le réseau de l’hôtel, tandis que le navigateur et l’application de bureau utilisaient tous deux la route sélectionnée.

Cette fois, je retrouvais la même chose sur ma fibre.

Et surtout, je n’avais rien eu à désactiver pour y arriver.

J’avais compliqué la définition de « compatible IPv6 »

Je pensais auparavant que la question était surtout de savoir si un fournisseur annonçait « IPv6 supporté ».

En réalité, pour mon usage, deux vérifications suffisaient.

D’abord : est-ce que le VPN fonctionne normalement alors que ma connexion Internet possède IPv4 et IPv6 ?

Ensuite : est-ce que mon IPv6 réel reste à l’intérieur du dispositif au lieu de contourner discrètement le tunnel ?

Il existe des usages plus techniques où l’on veut recevoir une IPv6 publique particulière via le VPN, faire du routage entrant ou utiliser des services IPv6 natifs de manière avancée. Dans ce cas, il faut vérifier précisément ce que le fournisseur propose.

Mais ce n’était pas mon problème.

Je ne cherchais pas une IPv6 plus sophistiquée.

Je cherchais à empêcher celle que j’avais déjà de sortir par derrière.

Et pour quelqu’un sur une fibre française moderne, cette différence me paraît beaucoup plus importante que la présence du mot « IPv6 » sur une page de fonctionnalités.

L’icône verte ne me suffit plus

La petite application a des limites faciles à voir : moins de localisations que les grands fournisseurs et moins d’années d’historique public derrière elle.

Mais dans ce test, ce n’était pas ce qui décidait si je pouvais garder le VPN activé.

J’avais déjà énormément de serveurs avec mon fournisseur habituel.

Je pouvais changer de pays, changer de protocole et obtenir une nouvelle IPv4 presque à volonté.

Ce qu’il ne m’avait pas donné, c’était une connexion que je pouvais laisser telle quelle sans supprimer IPv6 moi-même.

C’est finalement là que les deux approches se sont séparées.

Avec mon premier VPN, j’avais réussi à rendre la connexion propre en retirant la seconde porte.

Avec le service plus petit, j’ai pu laisser cette porte en place et constater qu’elle ne contournait plus le tunnel.

Depuis, mon contrôle tient en moins d’une minute.

Je laisse IPv6 activé. Je connecte le VPN. Je vérifie IPv4 et IPv6. Puis j’ouvre l’application que je compte réellement utiliser.

Si mon adresse opérateur réapparaît sur l’une des deux routes, le test est terminé.

Si elle ne réapparaît pas et que mon travail continue normalement, je n’ai plus besoin de surveiller quelle génération d’IP l’application choisira ensuite.

Avant cette soirée, je pensais qu’un VPN « compatible IPv6 » devait surtout savoir parler IPv6.

Sur ma fibre française, j’ai fini par préférer une définition beaucoup plus concrète : je peux laisser IPv6 allumé et arrêter de vérifier s’il est en train de sortir par derrière.