---
title: "Migrare a nftables prima che iptables-legacy sparisca da Debian"
description: "Debian ha avviato la rimozione di iptables-legacy, binari via con forky e poi il supporto kernel: come scoprire se sei a rischio e la checklist di migrazione a nftables."
canonical: "https://www.mauriziofonte.it/blog/post/iptables-legacy-rimozione-debian-forky-migrare-nftables.html"
author: "Maurizio Fonte"
date: "2026-11-09T08:52:49+01:00"
modified: "2026-11-09T08:52:49+01:00"
section: "Sicurezza Informatica"
tags: ["Sicurezza Informatica", "VPS & Hosting"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html)

# [Migrare a nftables prima che iptables-legacy sparisca da Debian](https://www.mauriziofonte.it/blog/post/iptables-legacy-rimozione-debian-forky-migrare-nftables.html)

Lunedì 9 Novembre 2026, alle 08:52 ![Migrare a nftables prima che iptables-legacy sparisca da Debian](https://www.mauriziofonte.it/image/005820200-iptables-legacy-rimozione-debian-forky-migrare-nftables.jpg)

A novembre 2025, sulla mailing list debian-devel, il kernel team di Debian ha aperto il [Mass Bug Filing che annuncia la rimozione di iptables-legacy](https://lists.debian.org/debian-devel/2025/11/msg00303.html), e il piano dichiarato non lascia spazio a interpretazioni: le interfacce legacy del kernel usate da iptables, arptables ed ebtables sono deprecate e ormai **disabilitate di default nel kernel**, i pacchetti e i binari legacy verranno eliminati con Debian 14 "forky", e dopo il rilascio di forky sparirà anche il supporto lato kernel. In forky il vecchio stack potrà ancora funzionare, ma senza alcun supporto e con l'etichetta di deprecato stampata sopra. Nel frattempo systemd 259 ha già tolto a networkd e nspawn la capacità di creare regole NAT via iptables, solo nftables, uno dei cambi di rotta che ho messo in fila [analizzando le novità operative di quella release](https://www.mauriziofonte.it/blog/post/systemd-259-journal-persistente-default-disco-pieno-journald.html): quando l'init system e la distribuzione madre spingono nella stessa direzione nello stesso anno, la direzione non è più in discussione. La direzione è una sola e la velocità sta aumentando: il layer di compatibilità che da anni permette di far finta di niente sta esaurendo il suo mandato. La buona notizia è che per la maggior parte dei VPS moderni la migrazione è già avvenuta a tua insaputa; quella meno buona è che i sistemi dove non è avvenuta sono esattamente quelli con gli script più vecchi e meno documentati. In questo articolo la checklist completa: come scoprire in trenta secondi da che parte stai, e i sette passi per portare un firewall iptables storico su nftables nativo senza chiuderti fuori dalla macchina.

## TL;DR

> - **Verifica (30 secondi):** `iptables -V`. Se dice `(nf_tables)` sei sul backend moderno; se dice `(legacy)` la migrazione ti riguarda davvero.
> - **Controlla il doppio stack:** `iptables-legacy -L -n` e `nft list ruleset` insieme: regole in entrambi = configurazione da bonificare.
> - **Traduzione automatica:** `iptables-restore-translate -f regole.txt` converte il salvataggio iptables in sintassi nftables: base da revisionare, non da eseguire alla cieca.
> - **Destinazione:** ruleset nativo in `/etc/nftables.conf` + `systemctl enable nftables`; poi neutralizza gli script legacy (rc.local, hook di rete) e allinea Fail2ban con `banaction = nftables-multiport`.
> - **Sicurezza anti-lockout:** ogni switch si prova con la console del provider pronta e con la sessione SSH vecchia aperta finché la nuova non è verificata.

## Come scopro se sono ancora su iptables-legacy?

La risposta sta in un comando, perché da anni Debian gestisce la convivenza dei due mondi con le alternatives. `iptables -V` risponde con la versione **e il backend fra parentesi**: `iptables v1.8.x (nf_tables)` significa che i tuoi comandi iptables sono già tradotti verso il sottosistema moderno del kernel, ed è il default su Debian dalla buster in poi; `iptables v1.8.x (legacy)` significa che qualcuno, o qualche pacchetto, ha commutato le alternatives verso il binario storico, e sei nel perimetro del problema. Il quadro completo lo danno tre comandi in fila:

```bash
iptables -V
update-alternatives --display iptables | head -3
iptables-legacy -L -n 2>/dev/null | head   # regole caricate sul VECCHIO stack
nft list ruleset | head                     # regole nel sottosistema nuovo
```

Il caso patologico da riconoscere subito è il **doppio stack**: regole presenti sia nell'output di `iptables-legacy` sia in `nft list ruleset`. Succede più spesso di quanto si creda, tipicamente dopo migrazioni a metà o per colpa di un tool che parla con un backend mentre gli script di avvio parlano con l'altro, e produce il peggio dei due mondi: il pacchetto in ingresso attraversa **entrambi** gli stack, il comportamento effettivo è l'intersezione di due policy che nessuno ha mai pensato insieme, e il debugging diventa un esercizio di archeologia. Se ti riconosci qui, la migrazione non è procrastinabile: è già in corso, solo male.

C'è un dettaglio del piano Debian che rende il rischio meno teorico di quanto sembri: le interfacce legacy sono ormai **disabilitate di default nel kernel**, il che significa che il vecchio stack smette di essere qualcosa che "c'è comunque" e diventa qualcosa che c'è solo dove la configurazione lo riabilita. Tradotto in pratica: uno script iptables-legacy che oggi funziona sulla tua macchina aggiornata di versione in versione può fallire in silenzio sulla prossima installata da zero, e il fallimento di uno script firewall ha due esiti possibili, la macchina spalancata o la macchina irraggiungibile, a seconda di dove lo script si interrompe. È la classe di sorpresa che conviene incontrare in un laboratorio, non in un ripristino d'emergenza.

Vale la pena chiarire anche cosa NON sparisce, perché sul tema circola confusione. Il layer `iptables-nft`, quello che ti fa usare la sintassi iptables sopra il kernel moderno, non è oggetto di questa rimozione: a sparire sono i binari `-legacy` e, dopo forky, le interfacce kernel su cui poggiano. Quindi la migrazione ha due livelli di ambizione: il livello minimo, assicurarsi che tutto passi dal backend `nf_tables`, che ti mette al riparo dalla rimozione; e il livello giusto, passare alla **sintassi nativa di nftables**, che è il punto d'arrivo raccomandato anche dalla [pagina ufficiale della wiki Debian](https://wiki.debian.org/nftables) e quello che questa checklist costruisce, perché continuare a scrivere iptables nel 2026 significa formarsi su una sintassi in via di pensionamento.

Nel mio lavoro sui parchi VPS delle PMI questo genere di transizione silenziosa è pane quotidiano dei subentri: [nel mio profilo professionale](https://www.mauriziofonte.it/pages/about) trovi come lavoro su hardening e messa in sicurezza di macchine ereditate, dove il firewall scritto da qualcuno che non c'è più è un classico del genere.

## La checklist di migrazione, passo per passo

**Passo 1: fotografa l'esistente.** Prima di toccare qualunque cosa, il censimento: `iptables-save > /root/fw-legacy-backup.txt` (e `ip6tables-save`, che tutti dimenticano, lasciando IPv6 scoperto o spalancato). Questo file è insieme il tuo backup, la tua documentazione e la materia prima della traduzione. Leggilo davvero: nella mia esperienza il salvataggio di un firewall storico contiene sempre regole morte, riferimenti a IP che non esistono più, catene di tool disinstallati anni fa. La migrazione è l'occasione per potare, non per trasportare fossili: ogni regola che non sai spiegare è una regola da capire adesso o da eliminare adesso, perché tradurla senza capirla significa solo trasferire il debito tecnico su una sintassi nuova, con gli interessi maturati nel viaggio.

**Passo 2: traduci con lo strumento apposta.** La suite iptables moderna include i traduttori ufficiali, ed è un lusso che poche migrazioni tecnologiche offrono:

```bash
iptables-restore-translate -f /root/fw-legacy-backup.txt > /root/fw-nft-bozza.nft
ip6tables-restore-translate -f /root/fw6-legacy-backup.txt >> /root/fw-nft-bozza.nft
```

L'output è sintassi nftables legittima, ma trattalo come una **bozza da revisionare**, non come un artefatto finito: i moduli esotici possono non avere traduzione diretta (il traduttore li segnala nei commenti), e la traduzione meccanica riproduce la struttura storica invece di sfruttare ciò che nftables fa meglio, come i set per le liste di IP e le tabelle `inet` che unificano IPv4 e IPv6 in un colpo solo, dimezzando le regole da mantenere. Un assaggio del guadagno, perché rende l'idea meglio di ogni argomento: la blocklist che in iptables era duecento righe fotocopiate diventa

```text
set blocklist {
    type ipv4_addr; flags interval;
    elements = { 203.0.113.0/24, 198.51.100.7 }
}
# ... e una sola regola: ip saddr @blocklist drop
```

e aggiornare la lista diventa un `nft add element` atomico invece di una ricarica completa del firewall. È il genere di semplificazione che si apprezza alla terza modifica, e per sempre.

**Passo 3: componi il ruleset di destinazione.** La casa del firewall diventa `/etc/nftables.conf`, caricata dal servizio dedicato: `systemctl enable nftables`. Qui non riparto da zero perché la configurazione completa di un firewall nftables per un VPS, policy default-deny, rate limiting SSH, anti spoofing, l'ho già scritta ed è il complemento naturale di questo pezzo: la trovi nella [guida alla configurazione di nftables su VPS](https://www.mauriziofonte.it/blog/post/configurare-firewall-nftables-vps-senza-personale-tecnico.html). Il lavoro di questo passo è fondere la tua bozza tradotta con quella struttura pulita, e validare la sintassi **prima** di caricare: `nft -c -f /etc/nftables.conf` controlla senza applicare, ed è il comando che separa una migrazione da un lockout.

**Passo 4: allinea gli inquilini del firewall.** Il firewall non è mai solo: altri software scrivono regole, e vanno commutati insieme a te. **Fail2ban** in testa: la `banaction` va portata su `nftables-multiport` (o `nftables-allports`) in `jail.local`, altrimenti i ban continueranno a finire nello stack sbagliato, dove non incontrano più il traffico. **Docker** è il caso più delicato, tanto che figura esplicitamente fra i pacchetti citati nel MBF: il demone gestisce le proprie regole in autonomia sul backend iptables-nft, e la regola pratica è non mescolare mai le tue regole con le sue catene, tenendo le tue policy nella tabella nftables tua e lasciando che Docker amministri le sue. E qualunque VPN, pannello o script di provisioning che invochi iptables va censito adesso: la lista si costruisce con un `grep -r iptables /etc/ /usr/local/bin/ 2>/dev/null` che riserva quasi sempre sorprese.

**Passo 4-bis: valuta se un wrapper fa al caso tuo.** La checklist assume che il firewall tu voglia scriverlo e capirlo, che per un VPS esposto resta la mia raccomandazione. Ma esiste una via legittima per chi vuole solo uscire dal legacy con il minimo attrito: i wrapper moderni. La stessa wiki Debian suggerisce firewalld per chi non vuole mantenere script propri, e chi già usa ufw sta comunque poggiando sul backend moderno. Il criterio di scelta è onesto: se il tuo firewall è "porte 22, 80 e 443 aperte e basta", un wrapper ti dà la migrazione quasi gratis; se hai rate limiting, set dinamici, NAT o policy per interfaccia, il ruleset nativo è più leggibile di qualunque astrazione che ci si appoggi sopra.

**Passo 5: neutralizza gli avviatori storici.** Il firewall legacy non vive solo nelle regole ma nei meccanismi che le caricano al boot: righe in `rc.local`, hook in `/etc/network/if-up.d/`, unit systemd artigianali, il pacchetto `iptables-persistent`. Vanno trovati e disattivati tutti, perché il sintomo classico della migrazione lasciata a metà è la macchina che dopo il riavvio ricarica lo stack vecchio sopra quello nuovo, ricreando il doppio stack del quale al passo zero ti eri appena liberato.

**Passo 6: lo switch, con le cinture allacciate.** Il momento del passaggio segue la regola d'oro che ho già raccontato nella [sequenza per lavorare via SSH senza chiudersi fuori](https://www.mauriziofonte.it/blog/post/upgrade-debian-13-trixie-via-ssh-sequenza-sicura-screen.html): console del provider verificata prima, sessione SSH esistente che resta aperta, caricamento del ruleset nuovo, e **connessione di prova da un altro terminale** prima di dichiarare vittoria. Per i paranoici giustificati, un `at` che azzera il firewall fra dieci minuti se non lo cancelli è la rete di sicurezza che non costa niente, si disinnesca con un comando quando la prova di connessione riesce, e una volta nella vita ripaga tutto. Infine il riavvio di collaudo, perché un firewall si giudica a freddo: la macchina deve tornare su con il ruleset giusto, uno solo, e con `iptables-legacy -L -n` ormai vuoto.

**Passo 7: iscrivi la migrazione nel calendario del parco.** Se gestisci più macchine, il censimento del passo 1 va fatto su tutte adesso, con la migrazione calendarizzata per lotti: il costo marginale della seconda macchina è una frazione della prima, e arrivare a forky con il parco già nativo significa leggere le release notes di Debian 14 con la serenità di chi quel capitolo l'ha chiuso un anno prima.

> Le deprecazioni annunciate con anni di anticipo sono il modo in cui l'open source ti regala il tempo di fare le cose bene. Il paradosso è che proprio quell'abbondanza di preavviso le rende procrastinabili all'infinito: nessuna delle macchine ancora su iptables-legacy oggi è di qualcuno che non è stato avvisato, e lo stesso varrà per chi arriverà impreparato a forky.

C'è un ultimo argomento per farlo adesso e non con l'acqua alla gola, ed è di formazione più che di tecnica: nftables non è una sintassi nuova per le stesse idee, è un modello più pulito, tabelle e catene che crei tu invece di ereditare, famiglie `inet` unificate, set e mappe come cittadini di prima classe, e il tempo che investi oggi a padroneggiarlo lo reinvesti su ogni firewall che scriverai nei prossimi dieci anni, incluso quello che systemd, i container e ogni nuovo componente dell'ecosistema ormai danno per scontato. Se il censimento del tuo parco rivela firewall storici, doppi stack o script di avvio misteriosi, e preferisci che la migrazione la conduca qualcuno che l'ha già fatta molte volte, con la finestra concordata e il piano anti-lockout scritto, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): su un VPS tipico la migrazione completa sta in una mezza giornata, verifiche a freddo comprese.

Dall'articolo al lavoro vero

Questo problema di sicurezza, sul tuo sistema

Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti.

[Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Lunedì 9 Novembre 2026, alle 08:52 [« Articolo precedenteConviene comprare un Raspberry Pi adesso se il Pi 6 non arriva prima del 2028?6 Novembre 2026](https://www.mauriziofonte.it/blog/post/raspberry-pi-6-2028-comprare-o-tenere-homelab-prezzi.html)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Migrare a nftables prima che iptables-legacy sparisca da Debian", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/iptables-legacy-rimozione-debian-forky-migrare-nftables.html

Pubblicato: 2026-11-09 · Aggiornato: 2026-11-09.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.