Tailscale e FRITZ!Box: cosa funziona davvero (e cosa no)

Perché Tailscale non si installa sul FRITZ!Box

Tailscale con un FRITZ!Box funziona, ma non sul FRITZ!Box. FRITZ!OS è un sistema chiuso: non ha un gestore di pacchetti, non ha una shell accessibile e non esegue software di terze parti. Non esiste quindi un pacchetto Tailscale da installare sul router, e non esisterà. Le strade reali sono due. La prima è un subnet router Tailscale su una macchina sempre accesa dentro la LAN (un Raspberry Pi, un NAS, un mini PC) che annuncia la rete predefinita del FRITZ!Box, 192.168.178.0/24, al resto della tua rete Tailscale. La seconda è la VPN WireGuard integrata in FRITZ!OS a partire dalla versione 7.50, che però funziona solo se la tua linea è raggiungibile dall'esterno.

La scelta tra le due dipende da un solo dato: l'indirizzo che il FRITZ!Box riceve dal provider. Se è un indirizzo IPv4 pubblico, entrambe le strade sono aperte. Se è un indirizzo nella rete 100.64.0.0/10, la linea è sotto CGNAT (carrier-grade NAT, la traduzione degli indirizzi fatta dal provider), la VPN di FRITZ!OS non può ricevere connessioni e Tailscale diventa l'unica opzione che non richiede di cambiare provider. Un VPS non serve per nessuna delle due configurazioni. Diventa utile solo per due cose precise, un exit node con IP di uscita fisso o un control plane Headscale, e le vediamo alla fine.

Leggi l'indirizzo WAN prima di decidere

Nell'interfaccia del FRITZ!Box (http://fritz.box oppure http://192.168.178.1) apri Internet e poi Monitor online. Le righe Internet, IPv4 e Internet, IPv6 mostrano gli indirizzi assegnati dal provider alla connessione. La knowledge base di AVM elenca gli intervalli IPv4 che significano "nessun indirizzo pubblico":

• da 10.0.0.0 a 10.255.255.255
• da 100.64.0.0 a 100.127.255.255, cioè CGNAT
• da 172.16.0.0 a 172.31.255.255
• da 192.0.0.0 a 192.0.0.7, cioè un tunnel DS-Lite
• da 192.168.0.0 a 192.168.255.255

Un indirizzo fuori da questi intervalli è pubblico, e il FRITZ!Box è raggiungibile da Internet su IPv4. Un indirizzo 100.64.x.y o 100.127.x.y invece appartiene alla rete condivisa che la RFC 6598 riserva ai provider: il tuo FRITZ!Box è dietro un secondo NAT, gestito dal provider, e nessuna porta che apri sul FRITZ!Box arriva da fuori, perché i pacchetti si fermano al NAT del provider prima ancora di raggiungere casa tua. In Italia questa situazione è comune sulle linee FWA e 5G, e compare anche su alcune linee in fibra. Non fidarti del nome del contratto: guarda l'indirizzo.

Una seconda verifica, dal terminale di un PC nella LAN, è confrontare l'indirizzo con cui esci su Internet con quello che vedi nel Monitor online:

curl -4 https://ifconfig.me

Se i due indirizzi sono diversi, tra il FRITZ!Box e Internet c'è un NAT che non controlli, anche se il Monitor online mostra un indirizzo che non è nella lista sopra. Controlla anche la sezione Condivisioni porte: se compare il messaggio che il provider mette a disposizione solo alcune porte, la linea è raggiungibile su IPv4 soltanto su quelle porte, e la VPN di FRITZ!OS deve usarne una.

Vale la pena ricordare perché così tanti FRITZ!Box italiani stanno su linee di cui non hanno scelto il NAT. Dalla delibera AGCOM 348/18/CONS del 2018 ogni utente ha il diritto di usare un modem proprio (il cosiddetto modem libero), e il FRITZ!Box è la scelta più diffusa. Il router però lo scegli tu, l'indirizzo lo decide il provider, e i due fatti sono indipendenti.

Strada 1: un subnet router Tailscale dentro la LAN

Un subnet router è un normale nodo Tailscale che, oltre a se stesso, rende raggiungibile una rete a cui è collegato. Funziona anche sotto CGNAT perché apre solo connessioni in uscita: HTTPS verso il server di coordinamento, UDP verso gli altri nodi per il tunnel WireGuard, e in caso di NAT ostile verso i relay DERP di Tailscale. Nessuna porta va aperta sul FRITZ!Box, e questo è il motivo per cui Tailscale sostituisce il port forwarding anche dove il port forwarding sarebbe possibile.

Serve una macchina accesa 24 ore su 24 nella LAN. I comandi che seguono sono per Ubuntu 24.04 e valgono uguali su Raspberry Pi OS o Debian, cambia solo la riga del repository. Molti NAS hanno un pacchetto Tailscale ufficiale con la stessa opzione di subnet router nell'interfaccia grafica; la logica di approvazione e le route sono le stesse.

Installa Tailscale dal repository apt ufficiale

Tailscale non è nei repository di Ubuntu. Il pacchetto arriva da pkgs.tailscale.com, e conviene aggiungere quel repository in modo esplicito, così apt upgrade aggiorna Tailscale insieme al resto del sistema. Questi sono i comandi che Tailscale pubblica per Ubuntu 24.04 (noble):

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

Su Raspberry Pi OS o Debian 12 sostituisci ubuntu/noble con debian/bookworm in entrambe le righe curl; la pagina pkgs.tailscale.com/stable elenca il nome corretto per ogni versione. Lo script curl -fsSL https://tailscale.com/install.sh | sh fa esattamente questi passaggi in automatico, ma nasconde quale repository ha aggiunto. Se apt-get install fallisce con un errore di firma o di repository, gli errori di installazione di Tailscale su Ubuntu hanno quasi sempre una delle cause spiegate in quella guida.

Prima di andare avanti, dai alla macchina un indirizzo fisso nella LAN. Nel FRITZ!Box apri Rete domestica, poi Rete, trova il dispositivo e attiva l'opzione che gli assegna sempre lo stesso indirizzo IPv4. Un subnet router che cambia indirizzo rompe la route statica della sezione SNAT e il DNS diviso della sezione successiva.

Abilita il forwarding dei pacchetti

Un sistema Linux scarta i pacchetti che non sono destinati a lui. Un subnet router deve invece riceverli dal tunnel e passarli alla LAN, quindi il forwarding va acceso, e va acceso in un file, perché un sysctl -w sparisce al primo riavvio:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sysctl net.ipv4.ip_forward

L'ultimo comando deve rispondere net.ipv4.ip_forward = 1. Se salti questo passaggio, Tailscale te lo dice al momento di annunciare la route con l'avviso Warning: IP forwarding is disabled, subnet routers and exit nodes will not work. e il ping verso la LAN non riceverà mai risposta.

Annuncia la rete del FRITZ!Box

Controlla quale rete usa davvero il tuo FRITZ!Box, perché non tutti hanno lasciato il valore di fabbrica. L'interfaccia collegata alla LAN mostra l'indirizzo con il suo prefisso, per esempio 192.168.178.20/24:

ip -4 -brief addr show

Poi collega la macchina al tuo account e annuncia la rete:

sudo tailscale up
sudo tailscale set --advertise-routes=192.168.178.0/24

tailscale up stampa un URL: aprilo nel browser e accedi. tailscale set cambia una sola impostazione senza dover ripetere tutti gli altri flag, ed è il motivo per cui è preferibile a tailscale up --advertise-routes=..., che alla seconda esecuzione si rifiuta di partire se non elenchi di nuovo ogni opzione già attiva.

Approva la route nella console di amministrazione

Annunciare una route non basta: per sicurezza Tailscale la ignora finché un amministratore non la approva. Nella console, pagina Machines, apri il menu del subnet router e scegli Edit route settings (nella versione più recente dell'interfaccia la stessa cosa si trova nella sezione Subnets del dispositivo, pulsante Edit). Spunta 192.168.178.0/24 e salva. Finché non lo fai, accanto alla route compare l'etichetta Unapproved, ed è la prima cosa da controllare quando la LAN non risponde. Se vuoi che le route future si approvino da sole, la policy ha una sezione autoApprovers che assegna il diritto a un tag o a un utente.

Abilita le route sui client

Windows, macOS, iOS e Android accettano le route annunciate in automatico. Linux no, per scelta esplicita di Tailscale, quindi su ogni client Linux esegui:

sudo tailscale set --accept-routes

Ora, da un dispositivo fuori casa collegato a Tailscale:

ping -c 3 192.168.178.1

Il FRITZ!Box risponde ai ping dalla propria LAN, e attraverso il subnet router la richiesta arriva proprio dalla LAN. Se il ping funziona, apri http://192.168.178.1 nel browser e trovi l'interfaccia del FRITZ!Box come se fossi a casa. Con tailscale status la riga del subnet router termina con direct seguito da indirizzo e porta, oppure con relay e il nome di un relay DERP: la seconda forma funziona ma è più lenta, e il motivo per cui una connessione Tailscale resta su relay invece che diretta merita una lettura a parte se vedi sempre relay.

SNAT: perché il FRITZ!Box non ha bisogno di una route statica

Questo è il punto che le guide generiche saltano. Di default il subnet router applica SNAT (source NAT) al traffico che entra dal tunnel: un pacchetto che arriva dal tuo telefono con sorgente 100.x.y.z esce verso la LAN con la sorgente riscritta nell'indirizzo LAN del subnet router, per esempio 192.168.178.20. Il FRITZ!Box e ogni altro dispositivo vedono quindi una richiesta da un vicino di rete e rispondono a lui direttamente. Il FRITZ!Box non deve sapere che esiste la rete 100.64.0.0/10, e non serve alcuna route statica. Il rovescio della medaglia: nei log dei dispositivi di casa tutti gli accessi da Tailscale sembrano venire dal subnet router.

Se vuoi che i dispositivi vedano il vero indirizzo Tailscale del client (per log leggibili, o per regole di firewall sul NAS basate sulla sorgente), disattiva SNAT:

sudo tailscale set --snat-subnet-routes=false

Da questo momento il NAS riceve un pacchetto con sorgente 100.x.y.z, non conosce quella rete e manda la risposta al suo gateway predefinito, cioè al FRITZ!Box. Il FRITZ!Box a sua volta non conosce 100.64.0.0/10 e la spedisce verso Internet, dove si perde. La connessione muore in silenzio. La soluzione è una route statica nel FRITZ!Box: apri Rete domestica, Rete, scheda Impostazioni di rete; attiva la vista avanzata se non vedi la sezione Route statiche, apri le route IPv4 e crea una nuova route con Rete IPv4 100.64.0.0, Maschera di sottorete 255.192.0.0, Gateway l'indirizzo LAN del subnet router (nell'esempio 192.168.178.20), e l'opzione Route attiva spuntata. La maschera 255.192.0.0 copre l'intero 100.64.0.0/10, cioè tutti gli indirizzi che Tailscale assegna ai nodi.

ACL: chi può entrare nella LAN

Approvare la route la rende disponibile a tutta la rete Tailscale, salvo quanto dice la policy. Per limitare l'accesso alla LAN di casa a un gruppo, nella policy della console (pagina Access Controls) usa un grant con la sottorete come destinazione:

{
  "groups": {
    "group:casa": ["tuonome@example.com"]
  },
  "grants": [
    {
      "src": ["group:casa"],
      "dst": ["192.168.178.0/24"],
      "ip": ["*"]
    }
  ]
}

Con SNAT attivo la regola viene comunque valutata sul subnet router prima della riscrittura, quindi funziona in entrambe le configurazioni. Ricorda che la regola predefinita di una rete nuova permette tutto a tutti: se condividi la rete Tailscale con altre persone, scrivila prima di approvare la route.

Il problema del 192.168.178.0/24 in trasferta

192.168.178.0/24 è la rete predefinita di ogni FRITZ!Box venduto. Quando ti colleghi al Wi-Fi di un amico che ha anche lui un FRITZ!Box, il tuo client ha due strade per 192.168.178.1: la rete locale e la route Tailscale. Quale delle due vinca dipende dal sistema operativo del client, e in ogni caso una parte del traffico finisce nel posto sbagliato. La stessa AVM, nella guida alla VPN WireGuard, consiglia di cambiare la rete IP del FRITZ!Box proprio per evitare questa collisione. Nel FRITZ!Box la trovi in Rete domestica, Rete, Impostazioni di rete, tra le impostazioni avanzate degli indirizzi IPv4: scegli una rete poco comune, per esempio 192.168.77.0/24, lascia che il DHCP riassegni gli indirizzi e poi ripeti tailscale set --advertise-routes= con la nuova rete e approvala di nuovo nella console.

Raggiungere i nomi fritz.box dalla rete Tailscale

Il FRITZ!Box risolve fritz.box e il nome di ogni dispositivo come nome.fritz.box, ma solo per chi gli chiede il DNS. I client Tailscale fuori casa usano il proprio resolver, e nas.fritz.box non risolve. Nella console, pagina DNS, aggiungi un nameserver personalizzato con indirizzo 192.168.178.1 e attiva Restrict to domain con il dominio fritz.box. Da quel momento solo le richieste per *.fritz.box vengono inviate al FRITZ!Box, attraverso il subnet router, e tutto il resto continua a usare il resolver normale. Serve che MagicDNS sia attivo e che i client Linux non abbiano disattivato --accept-dns.

Strada 2: la VPN WireGuard integrata in FRITZ!OS

Dalla versione 7.50 di FRITZ!OS il FRITZ!Box ha un server WireGuard integrato. Nella knowledge base italiana di AVM i requisiti sono due: FRITZ!OS 7.50 o successivo, e un FRITZ!Box che riceva dal provider un indirizzo IPv4 pubblico oppure un indirizzo IPv6. AVM chiede anche la registrazione a MyFRITZ!Net, perché la configurazione generata per il client usa il nome MyFRITZ! del router come endpoint, così un cambio di indirizzo non rompe il tunnel.

Il percorso è Internet, Abilitazioni, scheda VPN (WireGuard), pulsante Aggiungi connessione. Scegli l'opzione per collegare un singolo dispositivo, dai un nome alla connessione e conferma. Il FRITZ!Box genera le chiavi da solo e mostra un codice QR da scansionare con l'app WireGuard, oppure un file .conf da scaricare per un PC. Non c'è altro da configurare: niente forwarding, niente approvazioni, niente console. È la soluzione più semplice in assoluto, quando funziona.

E non funziona in due casi. Sotto CGNAT, il pacchetto iniziale del telefono deve arrivare al FRITZ!Box su una porta UDP, e il NAT del provider lo scarta perché non ha una sessione corrispondente. Il FRITZ!Box non può fare nulla al riguardo: non è una configurazione sbagliata, è la direzione del traffico. Con un indirizzo IPv6 la VPN funziona, ma solo se anche il dispositivo che si collega ha IPv6 in quel momento: molte reti ospiti e alcune reti mobili non lo forniscono, e allora l'handshake non parte. Se il tuo Monitor online mostra 100.64.x.y su IPv4 e nessun indirizzo IPv6, la strada 2 è chiusa e puoi smettere di cercare porte da aprire.

La differenza di fondo tra le due strade è quella tra WireGuard puro e Tailscale: la VPN di FRITZ!OS è WireGuard senza nulla intorno, con un endpoint fisso che deve essere raggiungibile, mentre Tailscale aggiunge il coordinamento e l'attraversamento del NAT. Esiste anche una terza strada, che AVM documenta come "connettere il FRITZ!Box a un provider VPN tramite WireGuard": il FRITZ!Box fa da client verso un server WireGuard tuo, per esempio un VPS con IP pubblico che fa da punto di ingresso per una rete sotto CGNAT. Funziona perché è il FRITZ!Box ad aprire la connessione, ma richiede un server da gestire, che è esattamente ciò che Tailscale ti evita.

Dove entra un VPS, e dove no

Per raggiungere la LAN di casa dal telefono non serve alcun VPS. Il subnet router sta nella LAN, il coordinamento lo fa Tailscale e il traffico tra i tuoi dispositivi passa in modo diretto o, nel peggiore dei casi, attraverso un relay DERP. Lo stesso meccanismo funziona anche al contrario: un subnet router Tailscale su un VPS rende raggiungibile la rete privata del provider cloud dai tuoi dispositivi, con gli stessi passaggi di route, approvazione e ACL. Un VPS ha due ruoli sensati nello schema di questa guida.

Il primo è l'exit node. Il subnet router porta il traffico verso casa, non verso Internet: quando sei su un Wi-Fi pubblico e vuoi che tutto il tuo traffico esca da un indirizzo fisso, un exit node Tailscale su un VPS fa questo, con sudo tailscale set --exit-node=<ip-del-vps> sul client e --exit-node-allow-lan-access=true se vuoi continuare a vedere la stampante del posto in cui ti trovi. Potresti fare exit node anche il Raspberry Pi di casa, ma allora tutto il tuo traffico esce dalla connessione domestica e ne consuma la banda in upload, che sulle linee FWA è quella scarsa.

Il secondo è il control plane. Se non vuoi che il server di coordinamento sia quello di Tailscale, Headscale su un VPS fa lo stesso lavoro con gli stessi client, e il subnet router dietro il FRITZ!Box si registra a quello invece che a Tailscale. Il resto di questa guida non cambia: route, approvazione, SNAT e ACL sono concetti che Headscale replica.

Modello di minaccia: cosa protegge e cosa no

Questa configurazione fa una cosa: rende la tua LAN raggiungibile dai tuoi dispositivi ovunque essi siano, con traffico cifrato tra il client e il subnet router. Non fa altre cose che spesso le vengono attribuite.

Non nasconde il tuo traffico al provider. Quando dal telefono apri un sito, il traffico non passa per casa a meno che tu non usi un exit node; e anche con l'exit node domestico, il provider di casa vede tutto quello che prima vedeva il provider del telefono. Non è una VPN per l'anonimato, è una rete privata tra macchine tue.

Il server di coordinamento di Tailscale vede quali dispositivi hai, i loro indirizzi pubblici e le chiavi pubbliche; non vede il contenuto del traffico e non ha le chiavi private, che restano su ogni dispositivo. Quanto sia sicuro Tailscale si riduce a quanto ti fidi di quel server per decidere chi entra nella tua rete, e la risposta a quella domanda si chiama Headscale o tailnet lock.

Infine, la LAN ora ha un ingresso in più. Chiunque abbia accesso al tuo account Tailscale, o a un dispositivo lasciato collegato, arriva al FRITZ!Box, al NAS e a ogni telecamera. Le ACL della sezione precedente e l'autenticazione a due fattori sull'identity provider sono il minimo. La VPN di FRITZ!OS ha lo stesso problema con le chiavi WireGuard salvate sul telefono: chi ha il telefono sbloccato è in casa tua.

Quando qualcosa non funziona

La LAN non risponde ma il subnet router sì. ping verso l'indirizzo Tailscale del router funziona e ping 192.168.178.1 no. Nell'ordine: la route è ancora Unapproved nella console; il client è Linux e manca --accept-routes; il forwarding è a 0 (sysctl net.ipv4.ip_forward sul router). Se la macchina ha ufw attivo, il traffico in transito è bloccato dalla policy predefinita di forward: sudo ufw route allow in on tailscale0 out on eth0, sostituendo eth0 con l'interfaccia che ip route show default indica.

Tutto va, ma solo con relay in tailscale status. Sotto CGNAT è normale che qualche coppia di dispositivi non riesca a stabilire una connessione diretta e passi dal relay DERP più vicino. tailscale netcheck sul subnet router riporta, tra le altre righe, MappingVariesByDestIP e PortMapping: la prima a true indica un NAT che cambia porta per ogni destinazione, il caso peggiore per l'attraversamento; la seconda elenca i protocolli con cui il router ha potuto aprire una porta. Con un FRITZ!Box su IP pubblico puoi aiutare Tailscale attivando, per il dispositivo, l'opzione che gli permette di modificare da solo le condivisioni porte (UPnP e PCP); sotto CGNAT quell'opzione non serve a nulla, perché la porta si aprirebbe sul FRITZ!Box e non sul NAT del provider.

La connessione cade quando il FRITZ!Box si riconnette. Alcune linee cambiano indirizzo pubblico a ogni riconnessione. Tailscale lo gestisce da solo, perché il subnet router comunica il nuovo endpoint al server di coordinamento; la VPN di FRITZ!OS si affida invece al nome MyFRITZ!, e un client che aveva in cache il vecchio indirizzo può restare muto finché l'app WireGuard non risolve di nuovo il nome, cosa che fa quando riattivi il tunnel.

Il nome nas.fritz.box non risolve. Manca il nameserver con Restrict to domain nella console, oppure il client Linux ha --accept-dns=false. Prova con l'indirizzo IP: se quello funziona, il problema è solo DNS.

FAQ

Posso installare Tailscale direttamente sul FRITZ!Box?

No. FRITZ!OS non esegue pacchetti di terze parti e non offre una shell, quindi non esiste un client Tailscale per FRITZ!Box e AVM non ne ha mai annunciato uno. La soluzione è un subnet router Tailscale su una macchina sempre accesa nella LAN, per esempio un Raspberry Pi, che annuncia la rete 192.168.178.0/24 al resto della tua rete Tailscale. Dal punto di vista dei dispositivi remoti il risultato è lo stesso: raggiungono il FRITZ!Box, il NAS e ogni altro dispositivo di casa con il loro indirizzo LAN.

Come capisco se la mia linea è sotto CGNAT?

Apri l'interfaccia del FRITZ!Box, vai in Internet e poi Monitor online, e leggi la riga Internet, IPv4. Un indirizzo tra 100.64.0.0 e 100.127.255.255 è CGNAT: il provider ti ha dato un indirizzo condiviso e nessuna connessione in ingresso raggiunge casa tua. Come controprova, da un PC nella LAN esegui curl -4 https://ifconfig.me: se l'indirizzo restituito è diverso da quello del Monitor online, c'è un NAT del provider tra te e Internet. In questo caso la VPN WireGuard di FRITZ!OS non può funzionare, mentre un subnet router Tailscale sì, perché apre solo connessioni in uscita.

Devo aggiungere una route statica nel FRITZ!Box per il subnet router?

Con la configurazione predefinita no. Il subnet router applica SNAT al traffico che arriva dal tunnel, quindi i dispositivi della LAN vedono le richieste provenire dall'indirizzo LAN del router stesso e rispondono a lui. La route statica serve solo se disattivi SNAT con tailscale set --snat-subnet-routes=false per vedere i veri indirizzi Tailscale nei log: in quel caso crea nel FRITZ!Box una route per la rete 100.64.0.0 con maschera 255.192.0.0 e come gateway l'indirizzo LAN del subnet router, altrimenti le risposte vengono spedite verso Internet e la connessione muore.

Mi serve un VPS per usare Tailscale con il FRITZ!Box?

No. Per raggiungere la LAN di casa bastano il subnet router nella LAN e il servizio di coordinamento di Tailscale. Un VPS ha senso per due casi specifici: come exit node, se vuoi che tutto il traffico dei tuoi dispositivi esca da un indirizzo fisso senza consumare l'upload della linea domestica, oppure come server Headscale, se vuoi gestire tu il control plane invece di affidarlo a Tailscale. Entrambi si aggiungono alla configurazione descritta qui senza cambiarla.