VPN sur routeur + Matter : le piège d’IPv6 désactivé avant même que le tunnel démarre

La serrure était à vingt centimètres de mon téléphone. Bluetooth fonctionnait. Le QR code Matter était reconnu. Mon HomePod mini apparaissait normalement dans la maison. Pourtant, au moment où l’installation devait réellement rejoindre le réseau, l’application tournait quelques secondes puis revenait avec une erreur.

J’ai recommencé. Réinitialisation de la serrure. Nouveau scan. Nouvel échec. Le suspect évident était mon VPN sur le routeur. Je l’avais configuré quelques jours auparavant pour éviter de gérer séparément le portable, la télévision et les autres appareils de la maison.

J’ai donc désactivé le profil VPN. Puis j’ai recommencé l’installation Matter. Même erreur. C’est là que le dépannage a pris une autre direction : le tunnel était coupé, mais quelque chose que j’avais modifié pour le faire fonctionner continuait à casser le réseau.

J’avais coupé IPv6 pour « nettoyer » mon VPN

Mon raisonnement initial n’avait rien d’absurde. J’utilisais un fournisseur VPN établi, avec des profils standards, beaucoup de documentation et une infrastructure largement éprouvée. Je voulais simplement déplacer la connexion du portable vers le routeur afin que plusieurs appareils puissent profiter du même tunnel.

Le routeur établissait correctement le VPN. IPv4 passait par la nouvelle route. IPv6, lui, compliquait le tableau. Certaines implémentations VPN de routeurs ne traitent toujours pas IPv6 de la même manière qu’IPv4. ASUS, par exemple, indique pour certaines de ses fonctions VPN que le tunnel prend en charge IPv4, mais pas IPv6.

Dans ce genre de configuration, une solution revient vite : désactiver IPv6 afin d’éviter que le trafic IPv6 continue à sortir directement pendant qu’IPv4 emprunte le VPN. Je l’avais fait. Le test d’adresse IP était devenu propre. Le VPN semblait propre.

Internet continuait à fonctionner. J’avais donc oublié ce réglage. Jusqu’à la serrure.

Matter n’attend pas Internet pour avoir besoin d’IPv6

C’est la partie que j’avais mal comprise. Je pensais à IPv6 comme à une deuxième autoroute vers Internet. Puisque mes sites web continuaient à fonctionner en IPv4, en fermer une me semblait surtout supprimer une complication. Matter l’utilise aussi comme une rue à l’intérieur de la maison.

Google décrit Matter comme utilisant IPv6 pour ses communications opérationnelles, en unicast comme en multicast. Lorsqu’un appareil passe par Thread, un Thread Border Router — HomePod mini, Apple TV compatible, Nest Hub ou autre équipement — relie ce petit réseau Thread au Wi-Fi ou à l’Ethernet de la maison.

Autrement dit, IPv6 n’est pas seulement une autre manière d’aller sur le Web. C’est aussi l’un des moyens dont les appareils Matter se servent pour se trouver et se parler localement.

Home Assistant résume très bien cette distinction : une connexion Internet IPv6 n’est pas nécessaire pour utiliser Matter, mais IPv6 doit fonctionner sur le réseau local et le multicast doit pouvoir circuler. Quand cette partie est cassée, les conséquences peuvent apparaître exactement là où je les voyais : appairage impossible, découverte défaillante ou appareils devenant indisponibles.

J’avais donc fermé une route locale pour corriger un problème de tunnel Internet. Et cela expliquait enfin pourquoi couper le VPN n’avait rien réparé.

Le piège devient beaucoup plus facile à rencontrer

Ce réglage aurait pu rester un détail de passionné de réseau. Il l’est de moins en moins. La Connectivity Standards Alliance a publié Matter 1.6 le 17 juin 2026, en poursuivant notamment le travail sur la configuration et les expériences entre plusieurs écosystèmes. Matter continue donc de s’installer dans davantage d’appareils et de maisons.

En France, IPv6 n’a plus grand-chose d’expérimental non plus. L’Arcep indiquait en juillet 2026 que 94 % des clients fixes grand public avaient IPv6 activé, contre 83 % sur le mobile.

Le vieux réflexe « je ne me sers pas d’IPv6, donc je peux le couper » devient alors beaucoup plus dangereux qu’il n’en a l’air.

Les discussions publiques montrent surtout pourquoi le diagnostic peut prendre autant de temps. En juillet 2026, un utilisateur de Firewalla décrivait deux installations où Apple Home et Matter over Thread étaient devenus injoignables sur des réseaux utilisant un VPN mesh. Les journaux faisaient apparaître une route IPv6 inaccessible et, surtout, désactiver le VPN mesh ne suffisait pas à faire revenir les appareils.

Ce détail m’intéresse davantage que l’incident lui-même. Quand le VPN est encore actif, on accuse le tunnel. Quand on le coupe et que rien ne revient, on commence à accuser la serrure, le hub, Thread, le Wi-Fi ou l’application. Alors que le changement responsable du problème peut être resté dans le routeur depuis le début.

Le test qui a réglé la serrure n’a utilisé aucun nouveau serveur VPN

J’ai laissé le profil VPN désactivé. Puis je suis retourné dans les paramètres réseau du routeur. IPv6 LAN : réactivé. J’ai vérifié au passage que je n’avais pas créé de règle bloquant le multicast local. Ensuite, j’ai redémarré le contrôleur et le Thread Border Router, puis relancé l’installation de la serrure.

QR code. Connexion. Cette fois, l’étape qui bloquait depuis près d’une heure est passée. La serrure est apparue dans l’application. J’ai touché « verrouiller ». Déclic. Puis « déverrouiller ». Deuxième déclic. C’était suffisant pour changer complètement mon critère de choix.

Je ne cherchais plus à obtenir le VPN le plus centralisé possible. Je cherchais à ajouter un tunnel sans toucher à la couche locale dont Matter avait besoin pour fonctionner. Cette différence paraît minuscule sur une page de configuration. Dans une maison connectée, elle change tout.

J’ai arrêté de demander au routeur de résoudre un problème qui concernait seulement mon ordinateur

Il me restait pourtant une vraie raison d’utiliser un VPN. Le soir, mon ordinateur devait passer par une autre route pour le service auquel je voulais accéder. C’était justement l’une des raisons pour lesquelles j’avais déplacé le VPN dans le routeur au départ : une seule configuration me semblait plus élégante que plusieurs applications.

Après l’épisode Matter, cette élégance avait perdu beaucoup de son charme. Pour obtenir exactement le comportement que je voulais du tunnel, j’avais fini par modifier le comportement réseau de toute la maison. Alors que l’appareil ayant réellement besoin du VPN était posé devant moi.

J’ai donc laissé le routeur tranquille. IPv6 actif. Matter actif. Aucune nouvelle modification du LAN. Puis j’ai installé OnlydogVPN^↗ directement sur l’ordinateur. L’approche était plus simple que celle que je venais d’abandonner. Je n’avais pas besoin de reconstruire un profil routeur ni de décider comment toute la maison devait se comporter. J’ai choisi le mode correspondant à mon usage et connecté.

Je suis revenu au service qui avait motivé le VPN. La page s’est ouverte par la nouvelle route. Puis, presque par réflexe, j’ai repris mon téléphone et ouvert la serrure Matter. Verrouiller. Déclic. Déverrouiller. Déclic. C’était le test qui manquait depuis le début.

Le VPN faisait son travail sur l’appareil qui en avait besoin, pendant que le routeur continuait à fournir à Matter le réseau IPv6 local dont la maison avait besoin.

Je n’avais pas rendu le tunnel plus sophistiqué. J’avais simplement cessé de lui donner autorité sur une partie du réseau qu’il n’avait aucune raison de modifier.

Le VPN sur routeur reste utile — quand le routeur doit vraiment porter le tunnel

Je ne suis pas sorti de cette histoire en pensant que les VPN sur routeur étaient une mauvaise idée. Ils gardent un avantage évident : si une télévision, une console ou un autre appareil incapable d’exécuter directement une application VPN doit passer par un tunnel, le routeur peut rester l’endroit logique où le faire.

Certains modèles permettent même d’appliquer le VPN uniquement à certains appareils. ASUS documente par exemple ce type de routage avec VPN Fusion. Dans une installation bien conçue, cette granularité évite justement de transformer une décision concernant un appareil en règle imposée à toute la maison.

Mais dans un réseau Matter, j’ajouterais désormais une question avant le nombre de profils, de serveurs ou de protocoles :

est-ce que cette configuration me permet de conserver correctement IPv6 sur le réseau local ?

Si oui, VPN sur routeur et Matter peuvent très bien cohabiter. Si le moyen le plus simple d’obtenir un tunnel « propre » consiste à couper IPv6 partout, je ne considère plus ce compromis comme anodin.

Le service plus petit garde d’ailleurs une limite très concrète dans ce scénario : une application installée sur l’ordinateur ne remplace pas un VPN de routeur lorsqu’un appareil qui ne peut pas installer de client doit lui-même passer par le tunnel. Dans ce cas, il faut résoudre proprement le routage au niveau du routeur.

Mais ce n’était pas mon problème. J’avais mis le VPN dans le routeur parce que cela semblait être la manière la plus propre de protéger quelques appareils. J’avais ensuite coupé IPv6 pour rendre cette installation encore plus propre. Et c’est précisément cette deuxième décision, prise avant même que le moindre paquet n’entre dans le tunnel, qui avait fait disparaître ma serrure Matter.

Depuis, mon test est beaucoup plus court. Je coupe le VPN et Matter reste inaccessible ? Alors je ne change plus de serveur. Je regarde d’abord si, en voulant sécuriser la route vers Internet, je n’ai pas supprimé celle que la maison utilisait pour se parler à elle-même.