Tailscale derrière une Freebox : contourner le CGNAT

Ce que vous obtenez à la fin

Tailscale derrière une Freebox relie vos machines de la maison et votre VPS sur un même réseau privé, sans ouvrir un seul port entrant sur la box. L'IPv4 partagée de Free, celle qui fait échouer vos redirections de ports, ne gêne donc pas. Chaque extrémité n'émet que des paquets UDP sortants, et comme la Freebox distribue de l'IPv6 natif et que la plupart des VPS ont une adresse IPv6, la liaison se fait souvent en direct, sans aucune traversée de NAT (network address translation, la traduction d'adresse que fait la box).

Le VPS et le PC de la maison se voient alors avec des adresses stables en 100.x.y.z, comme s'ils étaient sur le même câble. Sur une Freebox Delta ou Ultra, une petite machine virtuelle Debian sur la box peut même annoncer tout le réseau de la maison au VPS, sans que chaque appareil fasse tourner Tailscale.

Pourquoi la redirection de port échoue : l'IPv4 partagée de Free

Sur une grande partie de ses lignes, surtout en fibre, Free attribue la même adresse IPv4 publique à quatre abonnés. Les 65536 ports de cette adresse sont découpés en quatre plages de 16384 ports : 0 à 16383, 16384 à 32767, 32768 à 49151 et 49152 à 65535. Chaque abonné n'en reçoit qu'une. Free appelle cela une « IPv4 partagée ». La plage qui vous revient est affichée dans Freebox OS (http://mafreebox.freebox.fr), fenêtre État de la Freebox, onglet Internet, ligne Plage de ports.

La conséquence est mécanique. Un paquet qui arrive sur le port 443 de cette adresse est livré à l'abonné qui détient la plage 0 à 16383, et à personne d'autre. Si votre plage est 49152 à 65535, une redirection du port 443 ou du port 22 vers votre NAS ne recevra jamais rien, parce que le paquet est remis à un voisin. Aucun réglage de Freebox OS ne change cela. Beaucoup de lecteurs arrivent ici en tapant « contourner cgnat free ». Au sens strict, Free ne fait pas de CGNAT (carrier-grade NAT, une traduction d'adresse réalisée chez l'opérateur) : c'est la Freebox elle-même qui traduit, avec une plage de ports réduite. Pour vous, le résultat est identique : les ports habituels sont hors de portée.

Il existe deux sorties. La première est de demander une « IPv4 full-stack », c'est-à-dire une adresse fixe dont vous détenez les 65536 ports. La demande se fait dans l'Espace abonné, rubrique Ma Freebox, lien « Demander une adresse IP fixe V4 full-stack ». Au moment où j'écris (septembre 2026), elle est gratuite. Free affiche un avertissement avant validation : l'opération est réservée aux utilisateurs avancés et elle est irréversible. Elle est aussi à refaire après un déménagement. Relisez le libellé exact dans votre espace et sur la page d'assistance de Free, car le nom du menu change parfois.

La seconde sortie est de ne plus avoir besoin de port entrant du tout. C'est ce que fait Tailscale.

Pourquoi Tailscale derrière une Freebox n'a besoin d'aucun port entrant

Tailscale est un réseau maillé (mesh) bâti sur WireGuard. Chaque machine génère une paire de clés. Un serveur de coordination, hébergé par Tailscale, distribue les clés publiques et les adresses de chaque nœud aux autres membres du réseau, que Tailscale appelle un « tailnet ». Ce serveur ne voit jamais votre trafic : il ne transporte que des métadonnées.

Le point qui compte pour une Freebox : la connexion entre deux machines part des deux côtés en même temps. Votre PC envoie un paquet UDP vers le VPS, le VPS en envoie un vers votre PC, et la Freebox, qui a vu sortir le paquet de votre PC, laisse revenir la réponse sur la même correspondance. Le port utilisé est celui que la box a choisi dans votre plage, et personne n'a rien à rediriger. Si aucun chemin direct n'aboutit, le trafic passe par un relais DERP (Designated Encrypted Relay for Packets), un serveur Tailscale joignable en TCP sur le port 443. Le relais le plus proche pour un abonné Free est en général celui de Paris, que Tailscale nomme « par ». Même en passant par le relais, le contenu reste chiffré de bout en bout par WireGuard ; le relais ne fait que transmettre des paquets qu'il ne peut pas lire.

C'est exactement le raisonnement qui fait préférer Tailscale à la redirection de port sur n'importe quelle box. Chez Free, la question ne se pose même pas, puisque la redirection n'a jamais été disponible sur votre plage.

Installer Tailscale sur le VPS et sur une machine de la maison

Le script officiel détecte la distribution et installe le paquet tailscale. Lancez-le sur le VPS, puis sur un PC ou un serveur du réseau de la maison.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

tailscale up affiche une URL de connexion. Ouvrez-la dans un navigateur, authentifiez-vous avec le compte de votre choix, et la machine apparaît dans la console d'administration sur https://login.tailscale.com/admin/machines. Faites la même chose sur la seconde machine avec le même compte.

tailscale ip -4
tailscale status

tailscale ip -4 affiche l'adresse 100.x.y.z de la machine dans le tailnet. tailscale status liste tous les nœuds. Un nœud avec lequel aucun trafic n'a encore circulé apparaît avec un tiret à la place du chemin ; c'est normal tant que vous n'avez rien envoyé.

Sur le VPS, ouvrez le port UDP de Tailscale dans le pare-feu, si vous en avez un. Ce n'est pas obligatoire, mais un côté joignable directement rend le chemin direct beaucoup plus probable, et un VPS a une adresse publique complète, ce qui est justement ce que votre Freebox n'a pas.

sudo ufw allow 41641/udp
sudo ufw allow in on tailscale0

La seconde ligne compte autant que la première. ufw avec sa règle par défaut « deny incoming » bloque aussi le trafic qui arrive par l'interface tailscale0, ce qui donne un nœud visible dans tailscale status mais qui ne répond pas au ping.

Lire tailscale status et tailscale ping : direct ou relais ?

Une fois un premier paquet échangé, tailscale status montre le chemin réel pour chaque pair. Depuis le PC de la maison :

100.101.102.103 vps-paris   anna@   linux   active; direct [2001:db8:1::1]:41641, tx <octets> rx <octets>
100.64.0.7      nas-salon   anna@   linux   active; relay "par", tx <octets> rx <octets>

Trois formes de chemin existent. direct <adresse>:<port> signifie que les paquets vont d'une machine à l'autre sans intermédiaire ; une adresse entre crochets est une adresse IPv6, donc un chemin direct en IPv6. relay "par" signifie que le trafic passe par le relais DERP de Paris. Un tiret signifie qu'aucun trafic n'a encore été échangé avec ce nœud.

tailscale ping force l'échange et raconte la négociation :

tailscale ping vps-paris

pong from vps-paris (100.101.102.103) via DERP(par) in <n> ms
pong from vps-paris (100.101.102.103) via DERP(par) in <n> ms
pong from vps-paris (100.101.102.103) via [2001:db8:1::1]:41641 in <n> ms

Les premières réponses passent par le relais pendant que les deux nœuds cherchent un chemin direct. Dès qu'un chemin direct est trouvé, la ligne change de forme et la commande s'arrête, parce que l'option --until-direct vaut true par défaut. Si toutes les lignes restent en via DERP(par) et que la commande se termine sans jamais changer, vous êtes en relais. Les valeurs de latence que vous lirez sont les vôtres, elles dépendent de votre ligne et du VPS, et la différence entre un chemin direct et un chemin relayé explique l'essentiel d'une connexion Tailscale lente.

Pour comprendre pourquoi vous êtes en relais, tailscale netcheck décrit le réseau tel que Tailscale le voit depuis la machine :

Report:
	* UDP: true
	* IPv4: yes, <votre IPv4 partagée>:<port dans votre plage>
	* IPv6: yes, [<adresse IPv6 de la machine>]:41641
	* MappingVariesByDestIP: false
	* PortMapping: UPnP, NAT-PMP
	* Nearest DERP: Paris

UDP: true dit que l'UDP sort et revient. IPv6: yes dit qu'un chemin IPv6 public existe. MappingVariesByDestIP: false dit que la box garde le même port externe quelle que soit la destination, ce qui est le cas facile pour la traversée de NAT ; true est le cas difficile. PortMapping liste les protocoles d'ouverture automatique que la box a acceptés. Les deux sections suivantes reprennent ces lignes une par une.

Pourquoi la Freebox se connecte souvent en direct en IPv6

La Freebox distribue de l'IPv6 natif. Free attribue un préfixe à chaque abonné, et chaque machine du réseau de la maison reçoit une adresse IPv6 publique dans ce préfixe. Il n'y a pas de NAT en IPv6 : l'adresse de votre PC est joignable telle quelle depuis Internet, et donc depuis le VPS. Quand le VPS a lui aussi une adresse IPv6, Tailscale connaît les deux adresses par le serveur de coordination et peut établir le chemin direct sans aucune négociation de port.

Ce qui reste entre les deux, c'est le pare-feu IPv6 de la Freebox, s'il est activé sur votre modèle. Il est à état : un paquet UDP sortant de votre PC vers le VPS crée une entrée, et la réponse du VPS vers votre PC est acceptée parce qu'elle correspond à cette entrée. Comme Tailscale envoie depuis les deux côtés, chaque extrémité a toujours une entrée ouverte pour l'autre. C'est pour cela que le chemin IPv6 fonctionne sans rien ouvrir dans la box.

Vérifiez d'abord que l'IPv6 est actif des deux côtés. Sur la Freebox : Freebox OS, Paramètres de la Freebox, Mode avancé, Configuration IPv6, case « Activer le support IPv6 ». Sur une machine du réseau de la maison :

ip -6 addr show scope global
ping -6 -c 3 2606:4700:4700::1111

La première commande doit afficher au moins une adresse qui ne commence ni par fe80 ni par fd. Sur la fibre Free, elle commence en général par 2a01:e0a. Si vous ne voyez que du fe80, votre machine n'a qu'une adresse locale de lien, et le chemin IPv6 n'existe pas pour elle. Le ping doit recevoir trois réponses ; s'il affiche Network is unreachable, la machine n'a pas de route IPv6 par défaut.

Sur le VPS, faites le même contrôle. Beaucoup d'hébergeurs livrent une adresse IPv6 sans la configurer dans l'image système : vous la voyez dans le panneau, mais ip -6 addr ne la montre pas. Dans ce cas, ajoutez-la dans la configuration réseau du VPS (netplan sur Ubuntu) avant d'attendre un chemin direct en IPv6.

ip -6 addr show scope global
ip -6 route show default

Sans route par défaut en IPv6, le VPS ne peut pas répondre à votre PC en IPv6, et Tailscale retombe sur l'IPv4 ou sur le relais.

Ce que changent UPnP et NAT-PMP sur le chemin IPv4

Sans IPv6, ou si le VPS n'en a pas, Tailscale doit traverser le NAT IPv4 de la Freebox. Dans Freebox OS, ouvrez Paramètres de la Freebox, Mode avancé, Gestion des ports. C'est dans cette fenêtre que se trouvent les redirections manuelles, et aussi les cases qui activent UPnP IGD et NAT-PMP. Le nom exact de l'onglet varie selon la version de Freebox OS ; cherchez les deux cases.

UPnP IGD (Internet Gateway Device) et NAT-PMP (NAT Port Mapping Protocol) laissent un appareil du réseau demander lui-même à la box une correspondance de port. Avec l'une des deux cases cochée, Tailscale demande une correspondance vers son port UDP, la box en ouvre une dans votre plage de ports, et la correspondance reste stable. Le VPS sait alors exactement à quelle adresse et à quel port envoyer, ce qui rend le chemin direct en IPv4 presque certain. tailscale netcheck le confirme sur la ligne PortMapping.

Sans ces cases, Tailscale s'appuie sur la correspondance que la box a créée en laissant sortir le premier paquet. Sur une Freebox en mode routeur, cela suffit souvent, et la ligne MappingVariesByDestIP: false de netcheck le montre. Si vous lisez true, la box change de port externe selon la destination, et le chemin direct en IPv4 devient difficile : activez UPnP ou NAT-PMP, ou comptez sur l'IPv6.

Le prix à payer : UPnP permet à n'importe quel appareil du réseau, une télévision connectée ou une console par exemple, d'ouvrir des ports sans vous le dire. Sur une IPv4 partagée, ces ouvertures restent limitées à votre plage, mais elles existent. Si cette idée vous déplaît, laissez les deux cases décochées et comptez sur l'IPv6, avec le relais DERP en secours. Notez enfin que si votre Freebox est en mode bridge, tout ceci ne s'applique plus : c'est votre propre routeur qui fait le NAT, et c'est chez lui qu'il faut regarder.

Freebox Delta et Ultra : une VM Debian comme routeur de sous-réseau

Tailscale ne s'installe pas sur Freebox OS, qui est un système fermé. Mais la Freebox Delta et la Freebox Ultra font tourner des machines virtuelles, et une VM Debian minuscule sur la box peut jouer le rôle de routeur de sous-réseau : elle annonce le réseau de la maison à votre tailnet, et le VPS atteint alors n'importe quel appareil du LAN, y compris ceux qui ne feront jamais tourner Tailscale, comme une imprimante ou un NAS ancien.

Créez la VM dans Freebox OS, icône VMs, bouton Nouvelle VM. Trois points sont à vérifier sur votre propre modèle, parce qu'ils diffèrent d'une box à l'autre et d'une version de Freebox OS à l'autre. Le processeur est ARM : une image x86 est refusée avec le message « Attention, votre image disque ne semble pas être pour l'architecture arm64 (ou aarch64) ; l'architecture x86 n'est pas supportée ». Free propose des images prêtes à l'emploi, dont Debian ; si vous apportez la vôtre, prenez la variante arm64. La VM a besoin d'un support de stockage sur la box, disque interne ou disque branché selon le modèle. Enfin, les ressources sont plafonnées : sur l'Ultra, les VM se partagent 2 Go de mémoire au total ; sur la Delta, une VM prend un ou deux processeurs virtuels et trois au maximum sont disponibles pour l'ensemble. Tailscale se contente de très peu, donc ces limites ne gênent pas ce cas d'usage.

La VM est raccordée au réseau de la maison comme n'importe quel appareil et reçoit une adresse par DHCP. Fixez-la avec un bail DHCP permanent dans Freebox OS (Paramètres de la Freebox, Mode avancé, DHCP), sinon une adresse qui change un jour rend la route annoncée fausse. Puis, dans la console de la VM :

curl -fsSL https://tailscale.com/install.sh | sh
printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' | sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale up --advertise-routes=192.168.1.0/24

Remplacez 192.168.1.0/24 par le réseau réel de votre Freebox ; ip route dans la VM l'affiche sur la ligne qui porte dev et le nom de l'interface. Les deux lignes sysctl sont indispensables : sans net.ipv4.ip_forward = 1, le noyau de la VM reçoit les paquets destinés au LAN et les jette, parce qu'il ne transmet pas ce qui ne lui est pas adressé. La route annoncée n'est pas active tant que vous ne l'avez pas approuvée : dans la console d'administration, page Machines, ouvrez la VM, section Subnets, et validez la route. Ensuite, sur le VPS :

sudo tailscale set --accept-routes
ip route show table 52
ping -c 3 192.168.1.254

ip route show table 52 liste les routes que Tailscale a installées sur le VPS ; 192.168.1.0/24 doit y figurer. Si elle manque, la route n'est pas approuvée ou --accept-routes n'est pas passé. Le ping vers l'adresse de la Freebox (192.168.1.254 sur les modèles récents) doit répondre. Par défaut, la VM fait une traduction d'adresse source pour le trafic qui entre dans le LAN, donc les appareils de la maison répondent à la VM sans avoir besoin d'une route retour vers 100.64.0.0/10. Les listes de contrôle d'accès et le cas de plusieurs sous-réseaux sont traités dans le guide du routeur de sous-réseau Tailscale. Dans l'autre sens, si vous voulez que le trafic Internet de la maison sorte par l'adresse du VPS, le VPS en nœud de sortie est le mécanisme symétrique.

Quand Tailscale ne répond pas au besoin

Tailscale résout l'accès entre vos propres machines, et rien d'autre. L'accès du public reste un problème séparé. Si des inconnus doivent joindre un site web sur le port 443 d'une machine de la maison, ils ne feront pas partie de votre tailnet, et l'IPv4 partagée bloque toujours. Dans ce cas, soit vous demandez l'IPv4 full-stack, soit vous faites porter le port public par le VPS avec un tunnel inverse depuis la maison vers le VPS, et le VPS relaie vers le service.

Le modèle de menace, dit simplement

Tailscale ne cache rien à Free. Free voit que votre box échange des paquets avec l'adresse du VPS et avec les serveurs de Tailscale, en quel volume et à quelle heure. Free ne peut pas lire le contenu, parce que WireGuard le chiffre de bout en bout, et le relais DERP ne peut pas le lire non plus. Le serveur de coordination de Tailscale connaît votre identité de connexion et, pour chaque machine, sa clé publique et son adresse publique ; il ne voit pas le trafic.

Ce que vous gagnez est précis : plus aucun port ouvert sur Internet, et seules les machines que vous avez authentifiées peuvent parler aux vôtres. Ce que vous ne gagnez pas : l'anonymat. Si votre besoin est de cacher vos destinations à Free, c'est un autre sujet, et ce n'est pas Tailscale qui le règle.

Pannes courantes, et ce que vous verrez

tailscale status reste en relay "par". Lancez tailscale netcheck des deux côtés. UDP: false veut dire qu'aucun paquet UDP ne sort ou ne revient, ce qui arrive avec un pare-feu de l'hébergeur qui bloque l'UDP dans son panneau, ou sur un réseau d'entreprise. IPv6: no d'un côté veut dire que le chemin IPv6 n'existe pas ; reprenez la section IPv6. Si les deux lignes sont bonnes, ouvrez UDP 41641 sur le VPS et relancez tailscale ping.

Le nœud est listé, tailscale ping répond, mais ping 100.x.y.z échoue. tailscale ping passe par Tailscale lui-même, pas par la pile réseau du système, donc il ne voit pas le pare-feu. Le ping classique, lui, arrive par tailscale0 et le pare-feu du VPS le bloque. sudo ufw allow in on tailscale0 règle le cas.

La route du sous-réseau est annoncée mais rien ne répond. Vérifiez, dans l'ordre : la route est-elle approuvée dans la console ; le VPS a-t-il --accept-routes ; la VM a-t-elle encore la même adresse sur le LAN ; sysctl net.ipv4.ip_forward dans la VM affiche-t-il 1. Un 0 signifie que la VM reçoit les paquets pour le LAN et les jette.

FAQ

Faut-il demander l'IPv4 full-stack pour utiliser Tailscale derrière une Freebox ?

Non. Tailscale n'a besoin d'aucun port entrant, donc la plage de ports réduite d'une IPv4 partagée ne le gêne pas. Les deux machines émettent des paquets UDP sortants, la Freebox laisse revenir les réponses, et si aucun chemin direct n'aboutit, un relais DERP prend le relais. Demandez la full-stack seulement si un service doit être joignable par des inconnus sur un port classique.

Comment savoir si ma Freebox est en IPv4 partagée ?

Ouvrez Freebox OS sur http://mafreebox.freebox.fr, fenêtre État de la Freebox, onglet Internet. Une ligne Plage de ports avec un intervalle de 16384 ports, par exemple 32768 à 49151, signifie que votre adresse est partagée avec trois autres abonnés. Une adresse full-stack n'affiche pas cette restriction.

Pourquoi tailscale status affiche relay "par" au lieu de direct ?

Parce qu'aucun chemin direct n'a abouti, et que le trafic passe par le relais DERP de Paris. Lancez tailscale netcheck des deux côtés. Un UDP: false se corrige côté pare-feu, celui du VPS ou celui du panneau de l'hébergeur. Un IPv6: no se corrige en configurant l'IPv6 du VPS. Un MappingVariesByDestIP: true se contourne en activant NAT-PMP dans Gestion des ports. Relancez ensuite tailscale ping et attendez la ligne via [adresse]:port.

Peut-on installer Tailscale directement sur la Freebox ?

Pas sur Freebox OS. Sur une Freebox Delta ou Ultra, la solution est une machine virtuelle Debian arm64 créée depuis l'icône VMs de Freebox OS, dans laquelle Tailscale tourne comme sur n'importe quel serveur et annonce le réseau de la maison avec --advertise-routes. Sur les autres modèles, un Raspberry Pi ou un mini PC sur le réseau de la maison joue le même rôle.

Tailscale cache-t-il mon trafic à Free ?

Il en cache le contenu, pas l'existence. WireGuard chiffre tout de bout en bout, donc Free ne lit pas ce que vous échangez avec le VPS. Free voit toujours les adresses contactées et les volumes échangés. Tailscale remplace des ports ouverts par un réseau authentifié ; ce n'est pas un outil d'anonymat.