Quando nftables diventa il collo di bottiglia: la nostra esperienza con 50.000 prefissi CIDR

In Managed Server SRL, ci occupiamo da oltre 15 anni di sistemistica Linux, gestione di infrastrutture ad alte prestazioni e consulenza avanzata per ambienti web mission-critical. Nel corso di questo tempo abbiamo gestito migliaia di server, ottimizzato stack complessi per CMS ed e-commerce ad alto traffico e affrontato quotidianamente tutte le sfide tipiche dell’hosting professionale: sicurezza, performance e automazione dell’infrastruttura.

 Occupandoci di sistemistica Linux e consulenza da anni, come molti in questo settore abbiamo sempre avuto un rapporto intimo con Netfilter, iptables e tutto ciò che ruota attorno al filtraggio dei pacchetti nel kernel Linux. Il firewall a livello kernel non è semplicemente uno strumento di sicurezza: è spesso una componente fondamentale della stabilità dell’infrastruttura, soprattutto quando si gestiscono servizi pubblici esposti su Internet.

Quando abbiamo iniziato a sviluppare CFM 4 Linux (Centralized Firewall Manager), il nostro strumento interno per la gestione centralizzata delle regole firewall su flotte di server, la scelta del backend di filtraggio è stata una delle prime decisioni architetturali da prendere. Dovevamo decidere quale tecnologia utilizzare per gestire in modo efficiente grandi quantità di regole distribuite su decine o centinaia di macchine.

Ed è stata una decisione che ci ha portato dove non ci aspettavamo.

Questo articolo racconta quello che abbiamo scoperto, perché pensiamo che possa essere utile a chiunque stia valutando nftables per scenari ad alto volume di regole — in particolare il geo-blocking — e perché “più moderno” non sempre significa automaticamente “più veloce” o “più efficiente” in tutti i contesti operativi.

Il contesto: geo-blocking su scala

CFM gestisce policy firewall distribuite su decine di server all’interno di infrastrutture utilizzate per hosting, e-commerce e applicazioni web ad alto traffico. In scenari di questo tipo il firewall non è solo una barriera di sicurezza, ma diventa anche uno strumento operativo per controllare il tipo di traffico che raggiunge i servizi esposti. Tra le funzionalità più richieste dai nostri clienti c’è infatti il geo-blocking, ovvero la possibilità di bloccare (o consentire) il traffico in base al paese di origine dell’indirizzo IP.

Il caso d’uso più comune non è tanto il blocco selettivo di pochi paesi, quanto il modello inverso: consentire solo determinate aree geografiche e bloccare tutto il resto. Questo approccio è molto diffuso per siti e piattaforme che operano esclusivamente in specifici mercati — ad esempio Europa o Italia — e vogliono ridurre superfici di attacco, traffico indesiderato o scraping massivo proveniente da altre regioni del mondo.

Quando si applica una politica del tipo “consenti solo questi paesi”, il numero di prefissi CIDR da bloccare cresce rapidamente. In pratica bisogna inserire nel firewall tutti i range IP appartenenti ai paesi esclusi, che nella maggior parte degli scenari rappresentano la grande maggioranza dello spazio IP globale.

In termini concreti significa arrivare molto facilmente a 50.000–100.000 prefissi CIDR da gestire. Stiamo parlando di tutti i range IP allocati a 150 o più paesi che non rientrano nella whitelist.

Non è un numero inventato.

Il database GeoIP che utilizziamo — DB-IP Lite, integrato e normalizzato con i dati provenienti dai Regional Internet Registries (RIPE, ARIN, APNIC, LACNIC e AFRINIC) — produce tipicamente dataset di queste dimensioni:

• circa 51.000 prefissi IPv4 per uno scenario “consenti solo Europa”

• circa 44.000 prefissi IPv6 per lo stesso scenario

Il totale è quindi nell’ordine di 95.000 prefissi CIDR che devono essere inseriti nel firewall come regole DROP.

E questo è solo il caso base. In scenari più restrittivi — ad esempio consentire solo uno o due paesi specifici — il numero di prefissi può crescere ulteriormente, perché la whitelist diventa più piccola e la blacklist molto più ampia.

Il requisito architetturale per CFM era quindi chiaro fin dall’inizio: applicare queste regole in modo che il firewall continuasse a funzionare senza degradare le performance di rete del server. Un server web moderno può gestire decine di migliaia di connessioni al secondo, e qualsiasi inefficienza nel percorso di filtraggio dei pacchetti rischia di diventare immediatamente visibile in termini di latenza o throughput.

Sembra un requisito ovvio.

Ma, come vedremo nelle sezioni successive, quando si entra nell’ordine di decine di migliaia di regole CIDR, le differenze tra le varie tecnologie di packet filtering diventano molto più evidenti — e non sempre nel modo che ci si aspetterebbe.

La scelta di nftables: tutti dicevano che era meglio

Quando abbiamo progettato CFM4Linux, abbiamo fatto quello che fa qualsiasi team serio: ci siamo documentati a fondo. Abbiamo letto documentazione ufficiale, articoli tecnici, benchmark pubblicati, discussioni su mailing list e talk presentati a conferenze dedicate al networking Linux.

E il messaggio che emergeva era sempre lo stesso: nftables è il futuro, iptables è tecnologia legacy.

Questo non era solo marketing o narrativa da community. Negli ultimi anni il progetto Netfilter ha chiaramente spinto in questa direzione: nftables è stato progettato per sostituire progressivamente iptables, introducendo un modello più moderno, più coerente e — almeno sulla carta — più efficiente.

I punti a favore di nftables che trovavamo citati ovunque erano piuttosto convincenti:

• Set nativi con lookup O(1) tramite hash table o red-black tree, invece di catene lineari di regole con complessità O(n) tipiche di iptables

• Operazioni atomiche su intere tabelle e chain, evitando stati intermedi inconsistenti durante gli aggiornamenti delle regole

• Sintassi unificata per IPv4 e IPv6 tramite le tabelle inet, che eliminano la duplicazione delle regole tra iptables e ip6tables

• Maggiore flessibilità del linguaggio, con supporto a mappe, concatenazioni di chiavi e strutture dati più evolute

• Performance superiori nei benchmark pubblicati, incluso quello ufficiale pubblicato da Red Hat

Proprio quest’ultimo punto ha avuto un peso significativo nella nostra decisione.

Il benchmark pubblicato da Red Hat nel 2017,  (Benchmarking nftables — Red Hat Developer)  mostrava chiaramente come i set di nftables mantenessero tempi di lookup stabili indipendentemente dal numero di elementi, grazie all’uso di strutture dati più efficienti rispetto alla scansione sequenziale delle regole.

In altre parole: aggiungere 10 elementi o 100.000 elementi in un set nftables non dovrebbe cambiare significativamente il tempo di valutazione della regola.

Per un sistema come CFM, che doveva gestire decine di migliaia di prefissi IP, sembrava la soluzione perfetta.

Così abbiamo implementato il geo-blocking utilizzando named set nftables con il flag interval, che permette di rappresentare range CIDR in modo efficiente.

table inet cfm {
    set geo_blocked_v4 {
        type ipv4_addr
        flags interval
        elements = { 1.0.0.0/24, 1.0.4.0/22, 1.0.16.0/20, ... }
        # ~51.000 prefissi
    }

    chain cfm_input {
        type filter hook input priority 0; policy accept;
        ip saddr @geo_blocked_v4 drop comment "CFM:geo-allow-only"
    }
}

Dal punto di vista concettuale era una soluzione molto pulita:

• tutte le reti da bloccare erano contenute in un singolo set

• la chain input conteneva una sola regola

• l’aggiornamento del dataset poteva avvenire atomicamente

• IPv4 e IPv6 potevano essere gestiti nella stessa tabella inet

Il flag interval è fondamentale in questo contesto. Senza di esso, un set nftables accetta solo indirizzi IP esatti, mentre nel nostro caso dovevamo rappresentare interi blocchi CIDR.

Con flags interval, nftables utilizza internamente una struttura dati basata su red-black tree, implementata nel kernel nel file nft_set_rbtree.c. Questo è necessario perché il firewall deve poter gestire:

• intervalli di indirizzi

• range CIDR

• possibili sovrapposizioni tra prefissi

• lookup basati sull’inclusione dell’IP in un intervallo

In altre parole, il sistema non sta più facendo un semplice lookup in una tabella hash, ma una ricerca in un albero bilanciato di intervalli.

Sulla carta era comunque una struttura estremamente efficiente.

Ed è proprio qui che le cose hanno iniziato ad andare male.

Il disastro in produzione

Il primo deploy su un server di un cliente che necessitava mantenere raggiungibile solo dall’Italia il sistema di timbratura cartellino online (Hetzner, CentOS 7, kernel 6.1, nftables) è sembrato funzionare. Le regole venivano caricate, il set veniva popolato, nft list set inet cfm geo_blocked_v4 mostrava tutti i 51.000 prefissi. Tutto bene.

Poi abbiamo provato ad usare il server.

La connessione SSH è diventata inutilizzabile. Ogni comando aveva un ritardo di 5-10 secondi. Le pagine web non si caricavano. Un semplice curl https://www.google.com impiegava oltre 5 secondi — e il motivo era rivelatore: esattamente 5.05 secondi, che è il timeout di default per la risoluzione DNS.

Il DNS era rotto. Non completamente — le query andavano e tornavano — ma con una latenza talmente alta da causare timeout. E senza DNS funzionante, tutto il resto crolla.

La diagnosi

Abbiamo isolato il problema metodicamente:

1. Svuotato il set geo mantenendo solo le chain con ct state established,related accept → DNS tornato istantaneo (0.02s)
2. Ricaricato i 51.000 prefissi nel set → DNS di nuovo rotto (5+ secondi)
3. Ripetuto il test più volte → risultato deterministico e riproducibile

La causa era inequivocabile: il set nftables con flags interval e 51.000+ elementi causava un overhead per-pacchetto catastrofico a livello kernel.

E non si trattava di un problema di caricamento o di user-space. Il set era caricato correttamente nel kernel. Il problema era nel tempo di lookup per ogni singolo pacchetto che attraversava la chain contenente il riferimento al set.

Perché il DNS? Perché tutto?

Questo è un punto fondamentale da capire. In Netfilter, quando un pacchetto arriva su una chain con un match verso un set con flags interval, il kernel deve attraversare il red-black tree per determinare se l’IP sorgente rientra in uno dei range. Con un rbtree di 51.000 nodi, ogni lookup richiede fino a ~16 confronti (log₂ di 51.000), ma con le complessità aggiuntive della gestione degli intervalli sovrapposti, il costo reale è significativamente più alto.

Il problema non è il singolo lookup — sono i milioni di lookup al secondo che un server normale genera. Ogni pacchetto DNS in uscita, ogni ACK TCP, ogni pacchetto di una connessione SSH, ogni frammento di una pagina web — ognuno di questi deve attraversare il set. Anche i pacchetti che appartengono a connessioni già stabilite (ESTABLISHED,RELATED) subiscono il lookup se la regola ct state viene dopo il match sul set, o se si trovano in chain diverse con priorità differenti.

Quest’ultimo punto merita un approfondimento. In nftables, le chain base con priorità diverse vengono tutte valutate indipendentemente. Un accept in una chain a priorità -10 (la nostra chain di safety) non impedisce al pacchetto di essere valutato anche nella chain a priorità 0 (dove c’era il set geo). Solo un drop è terminale nel senso che blocca il pacchetto, ma un accept in una chain non salta le altre chain — il pacchetto continua il suo percorso attraverso tutte le chain registrate sullo stesso hook. Questo significa che anche i pacchetti loopback (127.0.0.1), già accettati dalla chain di safety, venivano comunque valutati contro il set di 51.000 prefissi.

I bug report che avremmo dovuto leggere prima

Dopo aver scoperto il problema, abbiamo cercato conferme nella community e le abbiamo trovate. Non eravamo i soli.

Netfilter Bug #1735 — “Adding nftables interval sets progressively gets slower and makes the nft CLI less responsive with each added set”. Segnalato nel gennaio 2024, descrive come i set con flags interval degradino progressivamente le performance. La prima iterazione impiega 0.12 secondi, alla quarantesima iterazione servono 1.59 secondi. E il consumo di memoria arriva a 180 MB. Ma questo bug parla del tempo di caricamento dei set, non del lookup per-pacchetto — il nostro problema era ancora peggiore.

Netfilter Bug #1439 — “Atomically updating/reloading a large set with nft -f is excessively slow”. Confermava che i set grandi, specificamente nello scenario geo-IP, erano impraticabili con il reload atomico. Questo bug è del luglio 2020 — sei anni fa.

OpenWrt Forum: “Nftables chokes on very large sets” — Utenti OpenWrt con kernel 5.15 che riportavano comportamenti anomali con set grandi, inclusi spike di memoria durante l’import.

OpenWrt Forum: “Some thoughts about nftables performance” — Una discussione approfondita sulle reali performance di nftables rispetto alle aspettative, con diversi utenti che riportavano problemi simili ai nostri.

Il kernel recente (6.19) ha introdotto ottimizzazioni nel backend pipapo (nft_set_pipapo.c) con il flag .abort_skip_removal (codice sorgente su GitHub), ma queste riguardano principalmente il tempo di cancellazione degli elementi, non il lookup per-pacchetto.

La soluzione: chain-splitting con iptables

Dopo aver compreso la natura del problema — il red-black tree degli interval set semplicemente non scala per 50.000+ prefissi sotto carico di rete reale — abbiamo dovuto trovare un’alternativa.

La soluzione che abbiamo adottato si chiama chain-splitting ed è implementata usando il buon vecchio iptables-restore. Il concetto è semplice ma efficace.

Come funziona

Invece di un unico set monolitico, raggruppiamo i prefissi CIDR per primo ottetto (il blocco /8 di appartenenza). Per ogni /8 che contiene almeno un prefisso da bloccare, creiamo una sub-chain dedicata:

*filter
:CFM_GEO - [0:0]
:CFM_GEO_01 - [0:0]
:CFM_GEO_02 - [0:0]
:CFM_GEO_05 - [0:0]
...

# Chain principale: jump per /8
-A CFM_GEO -s 1.0.0.0/8 -j CFM_GEO_01
-A CFM_GEO -s 2.0.0.0/8 -j CFM_GEO_02
-A CFM_GEO -s 5.0.0.0/8 -j CFM_GEO_05
...

# Sub-chain per il /8 = 1
-A CFM_GEO_01 -s 1.0.0.0/24 -j DROP -m comment --comment "CFM:geo"
-A CFM_GEO_01 -s 1.0.4.0/22 -j DROP -m comment --comment "CFM:geo"
...

COMMIT

La chain principale CFM_GEO contiene solo le jump rule per /8 — tipicamente 100-150 regole (non tutti i 256 possibili /8 sono popolati). Quando un pacchetto arriva con IP sorgente, diciamo, 1.2.3.4:

1. Attraversa la chain CFM_GEO: match su 1.0.0.0/8 → jump a CFM_GEO_01
2. Attraversa CFM_GEO_01: ~350 regole specifiche per quel /8
3. Se nessun match, ritorna e continua con il prossimo /8

Valutazioni per pacchetto: ~150 (jump) + ~350 (sub-chain) = ~500

Contro le 51.000 del set monolitico (o i ~16+ confronti nel rbtree, moltiplicati per la complessità della gestione intervalli). In pratica, il chain-splitting riduce le valutazioni per pacchetto di un fattore ~100x.

Per IPv6 usiamo lo stesso principio ma raggruppando per /16 (i primi due byte dell’indirizzo), dato che i prefissi IPv6 sono generalmente più ampi e meno numerosi.

I risultati

Dopo il passaggio al chain-splitting:

Non è un miglioramento marginale o come dire “cosmetico”. È la differenza tra un server funzionante senza alcun lag e senza alcun delay ed un server inutilizzabile.

Teniamo ulteriormente conto che questa configurazione IPTables girava su una configurazione estremamente modesta, ovvero 2 vCPU di un’istanza Hetzner, e appena 4GB di RAM, tenendo conto che a bordo c’era anche l’interprete PHP attivo con un WordPress installato, un database Percona Server 5.7, Memcache e ovviamente il WebServer più amato dai sistemisti mondiali : NGINX, per un uso già complessivo di suo di circa un paio di gigabyte almeno come da screen seguente.

Il paradosso delle performance

C’è un’ironia profonda in questa storia. nftables è stato progettato — e viene universalmente promosso — come il sostituto più performante di iptables. E per molti casi d’uso lo è. I set hash-based (senza flags interval) per IP esatti funzionano benissimo. Le operazioni atomiche sono eleganti. La sintassi unificata IPv4/IPv6 è un piacere.

Ma il caso d’uso specifico del geo-blocking con decine di migliaia di prefissi CIDR — che è probabilmente il caso d’uso più comune per set molto grandi — è proprio quello dove nftables fallisce catastroficamente.

Il motivo è strutturale: i set con flags interval usano un red-black tree, non una hash table. I range CIDR non possono essere hashati direttamente perché richiedono lookup per inclusione (l’IP 1.2.3.4 rientra nel range 1.2.0.0/16?), e questo tipo di ricerca richiede una struttura dati ordinata. Il red-black tree garantisce O(log n) per operazione, ma con 51.000 elementi e il traffico di rete di un server in produzione, quel logaritmo si moltiplica per milioni di pacchetti al secondo e diventa un collo di bottiglia intollerabile.

iptables, con il suo approccio “stupido” di regole lineari e banali, non ha questo problema perché il chain-splitting riduce la porzione di regole valutate per ogni pacchetto a un sottoinsieme gestibile. È meno elegante? Assolutamente sì. È vetusto ? Assolutamente si. È Antipattern, antiestetico ed antipatico ? Ancora si, si, si ! Funziona? Assolutamente sì.

Il resto, sono chiacchiere.

Lezioni apprese

1. I benchmark non sono il tuo caso d’uso

Il benchmark Red Hat del 2017 testava la velocità di lookup su set con migliaia di elementi, ma in condizioni controllate. Non testava cosa succede quando un server reale, con DNS resolver locale, connessioni SSH attive, web server, e servizi vari, deve valutare ogni pacchetto contro un interval set di 51.000 prefissi. I benchmark sintetici misurano il throughput massimo; la realtà misura la latenza sotto carico misto.

2. “Più moderno” non significa “migliore per ogni scenario”

nftables è oggettivamente superiore a iptables per la maggior parte degli scenari. Ma l’ingegneria del software è fatta di tradeoff, e la scelta della struttura dati per gli interval set (rbtree vs hash) è un tradeoff che penalizza fortemente il caso dei set molto grandi. Non è un bug — è una conseguenza architetturale.

3. Testare sempre con dati reali

Se avessimo testato subito con 51.000 prefissi reali invece che con qualche centinaio di regole di test, avremmo scoperto il problema in fase di sviluppo. La lezione è semplice: se il tuo sistema deve gestire N elementi in produzione, testa con N elementi in sviluppo.

4. Il fallback è fondamentale

CFM ora supporta tre backend (iptables, nftables, firewalld) e tutti e tre usano il chain-splitting per il geo-blocking. Avere un’architettura multi-backend ci ha permesso di isolare rapidamente il problema e implementare la soluzione senza riscrivere l’intero sistema.

Conclusione

Non scriviamo questo articolo per denigrare nftables — lo usiamo quotidianamente e ne apprezziamo le qualità. Lo scriviamo perché nella nostra esperienza, la narrativa dominante (“nftables è sempre più veloce di iptables”) ha bisogno di una qualificazione importante: dipende dal caso d’uso.

Se gestite set di qualche migliaio di IP esatti (blacklist, rate limiting, fail2ban), nftables con set hash è eccellente. Se dovete fare geo-blocking con decine di migliaia di prefissi CIDR, valutate attentamente il chain-splitting con iptables prima di assumere per partito preso che il set nftables sia la scelta giusta.

A volte la soluzione “vecchia” funziona meglio. E nel nostro mestiere — la sistemistica Linux in produzione — ciò che funziona batte ciò che è elegante, ogni singola volta.

Riferimenti

• Red Hat: Benchmarking nftables (2017)
• Red Hat: Optimizing iptables-nft large ruleset performance in user space (2020)
• Netfilter Bug #1735: interval sets progressively slower (2024)
• Netfilter Bug #1439: large set reload excessively slow (2020)
• OpenWrt: Nftables chokes on very large sets
• OpenWrt: Some thoughts about nftables performance
• Kernel source: nft_set_pipapo.c (pipapo/rbtree backend)
• nft-geo-filter — Geo-blocking tool per nftables