WireGuard Home Assistant : le LAN fonctionnait, Internet non — le piège était de lire `AllowedIPs` comme une permission

J’étais à 300 kilomètres de chez moi quand j’ai compris que mon VPN fonctionnait exactement comme je le lui avais demandé.

C’était justement le problème.

J’avais installé WireGuard sur Home Assistant pour une raison simple: depuis mon téléphone, je voulais pouvoir ouvrir l’adresse locale de mon tableau de bord sans exposer directement Home Assistant sur Internet.

Le test principal était réussi. J’ai activé WireGuard sur la 5G. 192.168.1.50:8123. Home Assistant s’est ouvert. J’ai vérifié une caméra.

Puis une prise. Même mon NAS répondait sur son adresse locale. Parfait. J’ai fermé Home Assistant et ouvert un site web. Rien.

Safari a tourné quelques secondes avant d’abandonner. Un deuxième site: rien. Je coupe WireGuard. Internet revient immédiatement. Je le rallume.

Home Assistant: oui. Le reste d’Internet: non. Mon premier réflexe a été de chercher ce qu’il fallait ajouter. Une nouvelle route? 0.0.0.0/0?

Une plage plus large?

Plus je regardais AllowedIPs, plus ce nom semblait me pousser dans cette direction: si certaines adresses fonctionnent, il faut probablement en « autoriser » davantage.

J’étais donc sur le point d’ouvrir tout le trafic dans le tunnel.

Puis j’ai compris que je lisais le paramètre à l’envers.

Home Assistant avait rendu WireGuard facile à installer, pas forcément facile à lire

Depuis Home Assistant 2026.6, publié le 3 juin 2026, les anciens « add-ons » sont présentés comme des Apps, avec une interface plus accessible. Home Assistant cite notamment les VPN parmi les logiciels que l’on peut faire tourner à côté du système.

Et pour l’accès distant, l’idée est logique: la documentation de Home Assistant présente le VPN comme une méthode sûre pour joindre son installation sans exposer directement le service sur Internet.

C’était exactement mon usage. Le problème n’était donc pas d’avoir choisi WireGuard. Le problème commençait juste après.

Une fois le tunnel activé, il fallait encore répondre à une question que l’interface ne formule pas aussi clairement:

quels paquets mon téléphone doit-il réellement envoyer dans ce tunnel?

C’est là que AllowedIPs entre en jeu.

Et le mot « Allowed » est trompeur.

AllowedIPs ressemble à une permission, mais agit aussi comme un panneau routier

WireGuard associe chaque pair à une ou plusieurs plages d’adresses. C’est ce que le projet appelle le Cryptokey Routing.

Pour mon téléphone, la manière la plus simple de le comprendre était la suivante: AllowedIPs ne disait pas seulement ce que j’avais le droit d’atteindre. Il disait aussi pour quelles destinations WireGuard devait être utilisé. Si j’écrivais: 192.168.1.0/24

je disais essentiellement:

pour atteindre mon réseau domestique 192.168.1.x, prends le tunnel WireGuard.

Le reste pouvait continuer à utiliser normalement la 5G ou le Wi-Fi du téléphone. En revanche: 0.0.0.0/0 couvre toutes les destinations IPv4.

Avec wg-quick, les routes sont justement construites à partir des AllowedIPs. Quand 0.0.0.0/0 est présent, WireGuard devient la route par défaut pour le trafic IPv4.

Le brouillard s’est dissipé d’un coup.

Mon LAN fonctionnait parce que WireGuard savait parfaitement joindre ma maison.

Internet disparaissait parce que j’avais également demandé à mon téléphone d’envoyer tout le reste dans cette même direction, alors que mon installation Home Assistant n’était pas configurée pour devenir une sortie Internet complète.

Je n’avais pas un tunnel cassé.

J’avais un tunnel trop ambitieux.

Le détail qui changeait tout était client_allowed_ips

L’App WireGuard communautaire de Home Assistant ajoute une subtilité importante: elle distingue allowed_ips et client_allowed_ips.

Ce dernier sert à générer la partie AllowedIPs du profil client.

Et si client_allowed_ips n’est pas défini, la configuration générée utilise par défaut 0.0.0.0/0.

Voilà ce qui s’était passé.

Je pensais avoir créé:

un accès distant à Home Assistant et à mon LAN.

J’avais en réalité demandé:

un accès à mon LAN, plus le passage de tout mon trafic Internet à travers ma maison.

Ce sont deux installations très différentes.

La première a simplement besoin de savoir quelles plages privées doivent passer dans WireGuard.

La seconde transforme la maison en passerelle Internet. Il faut alors gérer correctement le transfert IP, le NAT, le DNS et tout ce qui permet au trafic arrivé par WireGuard de repartir vers Internet. La documentation de l’App précise d’ailleurs que l’IP forwarding entre en jeu lorsque le serveur doit router le trafic du client vers d’autres destinations.

J’étais parti pour ouvrir une lumière à distance.

J’avais presque transformé Home Assistant en routeur de voyage.

J’ai résolu le problème en retirant des routes

Ma maison utilisait: 192.168.1.0/24 Je voulais atteindre Home Assistant, mon NAS et quelques équipements du LAN. Rien de plus.

Je n’avais aucune raison pour que les actualités, la météo ou chaque onglet Safari du téléphone fassent un détour par ma connexion domestique.

J’ai donc remplacé la route globale par les seules plages privées dont j’avais réellement besoin.

Sauvegarde.

Puis nouveau profil client.

Ce dernier détail compte: modifier les valeurs sur Home Assistant ne modifie pas automatiquement un profil WireGuard déjà importé sur le téléphone. Il faut régénérer ou mettre à jour la configuration côté client.

J’ai rescanné le QR code. Activé WireGuard. Home Assistant. Le tableau de bord apparaît. Caméra.

OK. NAS. OK. Puis Safari. La page s’ouvre immédiatement.

Je n’avais ajouté aucune règle mystérieuse. Aucun nouveau serveur. Aucun redémarrage du routeur. J’avais seulement cessé d’envoyer dans le tunnel du trafic qui n’avait rien à y faire.

Et surtout, je venais enfin de comprendre pourquoi « ajouter 0.0.0.0/0 » peut être à la fois une bonne réponse et une très mauvaise réponse.

0.0.0.0/0 répond à une autre question

Une discussion publique sur r/homeassistant montre bien la confusion que ce réglage peut créer: l’utilisateur cherchait à faire passer seulement le trafic utile à Home Assistant dans WireGuard tout en conservant l’accès Internet normal pour le reste. La discussion tourne justement autour des plages du tunnel, de celles du LAN et de client_allowed_ips.

C’est le point qui m’intéressait. 0.0.0.0/0 n’est pas une réparation universelle. C’est la réponse à une question précise:

veux-tu que tout le trafic IPv4 parte dans ce tunnel?

Si la réponse est oui, très bien. Il faut alors terminer correctement la configuration full tunnel derrière. Ma réponse était non. Je voulais une porte vers ma maison. Pas déplacer tout Internet derrière cette porte.

Et une fois cette distinction claire, j’ai aussi arrêté d’essayer de faire accomplir deux métiers différents au même WireGuard.

J’ai séparé l’accès à la maison du VPN pour Internet

Le problème suivant était plus pratique que technique. Quand je voyage, je veux parfois les deux choses: accéder à Home Assistant; et utiliser un VPN pour mon trafic Internet sur un Wi-Fi d’hôtel, de gare ou d’aéroport. C’était la raison pour laquelle le full tunnel m’avait semblé séduisant au départ.

Un seul bouton. Un seul tunnel. Tout passe par la maison. Mais cette élégance avait un prix.

Mon trafic Internet dépendait alors du débit montant de ma connexion domestique, de la disponibilité de Home Assistant comme passerelle, du NAT, du DNS et de toute ma configuration réseau à 300 kilomètres de distance.

Si quelque chose cassait, je pouvais me retrouver avec exactement le symptôme qui m’avait amené ici:

Home Assistant accessible.

Internet mort.

C’est à ce moment-là que OnlydogVPNVPN a trouvé une place beaucoup plus simple dans mon usage.

Je n’en avais pas besoin pour remplacer WireGuard. J’en avais besoin pour lui enlever un travail. WireGuard gardait une seule mission: me ramener vers mon LAN.

Quand je voulais protéger ma navigation sur un réseau extérieur, j’utilisais l’autre application pour la connexion Internet.

Le changement de logique était minuscule, mais le résultat était beaucoup plus propre. Pour accéder à la maison: WireGuard. Pour le trafic Internet: le service dédié.

Je n’avais plus à transformer Home Assistant en passerelle générale juste parce que je voulais un VPN en voyage.

L’application m’a aussi évité de revenir dans des plages CIDR et des routes pour cette seconde tâche. Son interface est organisée autour de l’usage, et l’utilisation de base ne repose pas sur le traditionnel compte avec adresse e-mail et mot de passe.

Dans mon cas, c’était précisément l’avantage: moins de réseau à administrer pour une fonction qui ne concernait pas Home Assistant.

WireGuard est resté — mais avec un seul métier

Je n’ai donc pas remplacé WireGuard. Je l’ai simplifié. Et c’était finalement beaucoup plus utile.

Un fournisseur plus ancien conserve évidemment des avantages, notamment davantage de régions disponibles. Et si mon objectif était de faire volontairement sortir mon téléphone par l’adresse IP de ma maison, je terminerais correctement une configuration full tunnel WireGuard.

Mais je n’avais pas besoin de ça. Je voulais ouvrir Home Assistant à distance, puis continuer à utiliser Internet normalement. Pour ce besoin précis, la bonne correction n’était pas d’ouvrir davantage AllowedIPs. C’était de le rendre plus précis. Depuis, je ne lis plus cette ligne comme:

« qu’est-ce que WireGuard m’autorise à atteindre? »

Je la lis comme:

« quelles destinations ai-je décidé de confier à ce tunnel? »

Cette nuance aurait suffi à m’éviter une heure de dépannage.

Elle m’a surtout évité de transformer mon installation Home Assistant en routeur Internet simplement parce que mon téléphone avait besoin d’atteindre 192.168.1.50.

Pour cette configuration, ma règle est désormais très concrète: WireGuard transporte les routes de ma maison; mon Internet reste ailleurs tant que je n’ai pas volontairement décidé de faire de la maison sa passerelle.