WireGuard dietro CGNAT: perché il port forwarding fallisce e come risolverlo (2026)

Hai installato WireGuard sul tuo server di casa, aperto l'UDP 51820, inoltrato la porta sul router - e ancora non si connette dall'esterno. Prima di ricontrollare la configurazione per la decima volta, sospetta della rete: il motivo più comune per cui un VPN self-hosted non è raggiungibile da internet è il CGNAT, e nessuna configurazione del router lo risolve. Ecco cos'è, come confermarlo e le soluzioni che funzionano davvero.

Cos'è il CGNAT e perché rompe il self-hosting

Il CGNAT (Carrier-Grade NAT) è il modo in cui molti ISP affrontano la scarsità di indirizzi IPv4: invece di dare a ogni cliente il proprio IP pubblico, mettono molti clienti dietro un unico indirizzo pubblico condiviso. Il lato WAN del tuo router riceve un indirizzo di intervallo privato (spesso in 100.64.0.0/10), e il NAT dell'ISP decide cosa entra.

La conseguenza è semplice e frustrante: nessun IP pubblico punta alla tua linea, quindi le connessioni in ingresso non hanno dove atterrare. Il port forwarding sul router controlla solo il traffico che ha già raggiunto il router - e con il CGNAT non ci arriva mai, perché il blocco è un livello più su, dentro l'ISP.

Come verificare se sei dietro CGNAT

Puoi confermarlo in un minuto. Apri la pagina di amministrazione del router e trova il suo IP WAN. Poi controlla il tuo IP pubblico su un servizio come whatismyip. Se i due non coincidono, sei dietro CGNAT. Un IP WAN del router in 100.64.0.0/10, o un intervallo privato come 10.x.x.x o 192.168.x.x, è un segnale inequivocabile.

Le soluzioni, dalla più pulita alla più arrangiata

• Un VPS con IP pubblico (la più affidabile). Ospita WireGuard su un VPS economico. Ha un vero IPv4 pubblico, quindi nessun NAT da combattere - i tuoi dispositivi si collegano direttamente. Se devi anche raggiungere la tua LAN di casa, avvia un piccolo tunnel da casa verso il VPS; quella connessione è in uscita, cosa che il CGNAT consente.
• Una rete con NAT traversal (la più facile). Tailscale, il Headscale self-hosted, o Netbird usano connessioni in uscita e server relay per collegare due dispositivi dietro NAT, senza alcun port forwarding. Vedi cos'è Tailscale e come funziona.
• Chiedi un IP pubblico al tuo ISP. Alcuni ti tolgono dal CGNAT o ti vendono un IP statico, a volte per un piccolo costo.
• IPv6. Se il tuo ISP fornisce IPv6 reale e instradabile, WireGuard su IPv6 evita il problema dell'IPv4 condiviso - a patto che entrambe le estremità abbiano IPv6 funzionante.
• Tunnel inversi. Cloudflare Tunnel, wstunnel o un tunnel SSH inverso si avviano in uscita da casa verso un endpoint pubblico, quindi passano anch'essi il CGNAT.

Qualunque strada scegli, ti servirà un nome stabile per raggiungerla; la nostra guida al DNS dinamico spiega come tenere un hostname puntato su un indirizzo che cambia.

Perché la via del VPS è di solito la migliore

Per un VPN su cui fai affidamento, un VPS con il proprio IP pubblico elimina l'intera classe di problemi. Ottieni un indirizzo prevedibile, pieno controllo di firewall e porta, nessuna dipendenza dalla buona volontà dell'ISP, e funge anche da exit node se ne vuoi uno. Il compromesso onesto sono pochi euro al mese e la piccola responsabilità di tenere il server aggiornato.

In sintesi

Se WireGuard si connette bene sulla rete locale ma mai dall'esterno, sospetta del CGNAT prima della tua configurazione. Confermalo con il confronto IP WAN contro IP pubblico, poi scegli una soluzione: un VPS con IP pubblico è la più affidabile e quella su cui si fermano la maggior parte dei self-hoster, una rete con NAT traversal è l'opzione senza forwarding più semplice, e IPv6 o un IP pubblico dell'ISP funzionano bene dove sono disponibili. Il problema è la condivisione degli indirizzi del tuo ISP, non il tuo file WireGuard.