VPN kill switch senza magie: come il kernel del sistema operativo blocca il traffico e protegge la privacy

Introduzione: perché serve davvero un VPN kill switch nel 2026

Obiettivi e realtà: cosa proteggiamo veramente

Una domanda semplice ma importante: cosa sei disposto a perdere in un solo secondo senza VPN? L'indirizzo IP, la cronologia delle richieste, i dati delle app? Nel 2026, quando le app sincronizzano praticamente tutto e i browser mantengono decine di connessioni in background, l'unico salvavita affidabile è il VPN kill switch. Fa una cosa netta: se il tunnel cade, blocca tutto il traffico senza eccezioni. Niente “forse”, niente “potrebbe reggere”. Spegne tutto, tranne il traffico che passa per l'interfaccia protetta. Sembra semplice? In realtà dietro le quinte c'è un gioco di abilità tra kernel del sistema operativo, tabelle di routing, marcature dei pacchetti, driver e regole firewall.

Perché è così critico proprio ora

I rischi oggi sono aumentati. Telecamere domestiche, email cloud, messenger super-sensibili, wallet di criptovalute: tutto si connette da solo e costantemente. Il tunnel traballa per un attimo — e arriva una perdita DNS oppure un endpoint API invia il vero IP. Sì, un solo secondo. Abbiamo visto casi: aggiornamento del driver di rete in Windows 11 24H2, micro-lag in Wi‑Fi, cambio rete sul laptop — ed è fatta. Il kill switch non discute, agisce: taglia. E tiene saldo il timone finché il tunnel non si stabilizza.

In sintesi: cosa fa il kill switch

Il kill switch non è un pulsante "spegnere internet". È un insieme di regole integrate nello stack di rete e nel firewall di sistema, che assicurano: solo i pacchetti che transitano attraverso l’interfaccia VPN (tun, tap, utun, wg, ikev2) possono uscire in rete; i pacchetti bypass sono bloccati fin dai primi hook. Inoltre, c'è il controllo DNS: la risoluzione avviene via VPN, mentre i resolver locali fuori tunnel sono vietati. E sì, tutto questo deve vivere non in un'app grafica, ma a livello di kernel OS. Altrimenti è una gara pericolosa e la privacy va persa.

Come funziona il kill switch a livello kernel: anatomia dello stack di rete

Routing, socket e hook: dove vengono intercettati i pacchetti

Nel kernel OS i pacchetti passano attraverso diverse fasi: creazione socket dall’app, scelta del percorso, applicazione delle regole firewall, gestione dell’interfaccia, invio. Il kill switch si inserisce abilmente in due punti: nelle tabelle di routing (per indirizzare tutto il «default» dentro il tunnel) e nel firewall (per bloccare immediatamente tutto ciò che non è contrassegnato come "attraverso VPN"). Questa doppia impostazione protegge dalle gare: se il percorso cambia improvvisamente, il firewall copre; se il firewall non ha ancora visto l’interfaccia, il routing impedisce al traffico di uscire fuori.

Livello kernel su Windows: WFP e filtri NDIS

Su Windows, il cuore è Windows Filtering Platform (WFP). Il client VPN installa un driver callout o utilizza livelli di sistema, filtra a livello di stack di trasporto e rete, marca il traffico dell’interfaccia VPN e blocca tutto il resto. In più si configurano profili firewall: regola "blocca tutto in uscita eccetto l’interfaccia VPN". Nel livello NIC si possono aggiungere driver NDIS LWF, ma nel 2026 la tendenza principale è WFP senza driver extra, per non rompere la compatibilità con Windows 11 24H2 e HVCI.

Linux: netfilter, nftables e cgroup-bpf

In Linux il kill switch si basa di solito su netfilter. La raccomandazione attuale è nftables (kernel 5.10+ e idealmente 6.x): si creano catene output/forward con politica drop, si autorizzano solo pacchetti contrassegnati o su interfacce specifiche (esempio wg0). In più policy routing: traffico con fwmark va su una tabella di routing separata, default è il tunnel, il resto cade in un buco nero. Per configurazioni avanzate si usa cgroup-bpf (BPF_CGROUP_INET_EGRESS): filtro a livello di processo per permettere, ad esempio, che ssh dell’amministratore esca dal kill switch per il debug, mentre tutto il resto resta bloccato. Flessibile e veloce.

macOS: Network Extension e PF

Su macOS ci si affida a Network Extension (NE) e al sistema Packet Filter (PF). Il client NE controlla il tunnel (interfaccia utun), mentre PF usa gli anchor per la politica restrittiva: blocca tutte le uscite, eccetto utunX e servizi autorizzati dentro il tunnel. Il DNS è forzato via NEAppProxyProvider o tramite impostazioni di sistema, in modo che le richieste passino per VPN. Con macOS 14+, Apple ha migliorato la stabilità di NE, e nel 2026 la maggior parte dei client maturi mantiene regole PF solide senza conflitti durante i cambi di rete.

Routing e tabelle: il modo più semplice per rompere o salvare la privacy

Il default route come centro nevralgico

Errore classico: avere due route di default — una verso la rete fisica e una verso il tunnel. L’OS sceglie la "migliore" in base alla metrica. Al riconnettersi, al cambio Wi‑Fi o al risveglio dallo sleep, le metriche possono saltare. Risultato: parte del traffico esce fuori VPN, soprattutto richieste DNS veloci. Il kill switch corretto assicura sempre che la route di default punti alla VPN e tutto il resto venga bloccato. E che l’aggiunta di un’interfaccia fisica non ripristini il vecchio default.

Policy routing e fwmark: chirurgia in Linux

In Linux la soluzione è semplice e affidabile. Si marcano i pacchetti delle app che devono passare nel tunnel (o tutto, se si ha una strategia totale), si crea una tabella di routing separata con default nel tunnel, mentre nella tabella principale il default è assente o punta a un blackhole. Anche se l’interfaccia cade, il traffico fuori tunnel non ha via d’uscita. Uno schema “a prova di bomba”, specialmente con nftables che permette condizioni raffinate: interfaccia, gruppo processo, uid, porte, domini (con sets e maps).

Windows: metriche e profili interfaccia

Windows ama la “libertà”. Quindi si fissano metriche interfaccia: la VPN ha la metrica più bassa, le fisiche più alte. Si impostano regole firewall per permettere uscite solo via l’interfaccia VPN (per InterfaceAlias o InterfaceType). Se il tunnel cade, il firewall taglia tutto, magari tranne gli indirizzi locali 127.0.0.0/8 e link-local per la stabilità OS. Nel 2026 molti client hanno implementato la correzione automatica delle metriche e il ripristino regole dopo riavvio del servizio BFE, cosa che prima era un tallone d’Achille.

macOS: sticky routes e PF anchors

Su macOS funziona bene lo schema con PF: si crea un anchor con politica di blocco di default e si autorizzano solo regole dove l’interfaccia è utunX. Le sticky route VPN vengono create automaticamente via NE, e PF impedisce qualsiasi uscita non autorizzata. Importante: dopo sleep e cambio rete aggiornare il numero dell’interfaccia utun, che può cambiare. Client intelligenti lo fanno da soli intercettando eventi via NE.

Regole firewall: come si costruisce il blocco

Linux: nftables al posto di iptables

Nel 2026 iptables esiste ancora, ma è superato. Si crea tabella inet vpn, catene input, forward, output. Politica output: drop. Si autorizza: established, related; interfaccia wg0 (o tun0); DNS via wg0; opzionalmente localhost. Possibile regola: se interfaccia != wg0, drop, altrimenti accept. Per sicurezza, in nftables route table si può maneggiare il traffico in caso di interfaccia down, ma spesso basta un output severo.

Windows: AdvFirewall e WFP

Scenario: si crea regola blocco uscita Block All, poi eccezione Allow VPN Interface. Con GUI è lungo e noioso, quindi si usa PowerShell. Si aggiunge New-NetFirewallRule con Direction=Outbound, Action=Block per tutti i profili, poi eccezioni puntuali Allow su InterfaceAlias. Client moderni usano WFP callout che droppa i pacchetti prima dello stack TCP, marcando i pacchetti VPN per bypassare regole Allow accidentali. Più veloce e affidabile che dipendere da regole utenti.

macOS: PF con anchor e states

PF fa la differenza: set block-policy drop, set skip on lo0, anchor vpn-killswitch con allow out su utunX da qualsiasi a qualsiasi ip mantenendo lo stato, più blocco su tutte le altre interfacce. Il trattamento stateful rende fluido il comportamento per le app. Poi la protezione DNS: bloccare udp/53 su tutte le interfacce tranne utun. Se usi DoH dentro il tunnel, ottimo: blocca completamente la 53 e lascia solo tcp/443 via utun.

DNS: un fronte a parte

Il DNS è il canale di fuga più insidioso. Regola semplice: risolvi solo tramite VPN o niente. In Linux si rimappa resolv.conf su resolver locale che ascolta solo su interfaccia tun oppure si usa systemd-resolved con routing per dominio. Su Windows si abilita “Block outside DNS” (flag presente in OpenVPN), più firewall che blocca udp/53 fuori VPN. Su macOS si usa NE per dns scoped, PF blocca 53 fuori utun. E attenzione ai client DoH (i browser sono scaltri): devono usare lo stack di sistema o endpoint DoH accessibile solo via tunnel.

Come i client VPN implementano il kill switch: analisi pratica

WireGuard: marcature e AllowedIPs

WireGuard è veloce, semplice e trasparente. Con wg-quick il kill switch arriva da due principi: AllowedIPs include tutto il traffico (0.0.0.0/0, ::/0), e routing + fwmark vincolano il traffico all’interfaccia wg. Se l’interfaccia cade, le politiche nftables bloccano l’uscita. Volendo si può mettere Table=off e gestire policy routing manualmente: flessibile e prevedibile. Per mobile è essenziale ricreare l’interfaccia al volo mantenendo regole drop.

OpenVPN: blocco fuori tunnel e rotte

OpenVPN è prova di tempo. Su Windows il parametro block-outside-dns chiude la falla DNS, client-config-dir e script route-pre-down aiutano a cambiare le rotte senza incidenti. In Linux la buona norma è nftables per bloccare tutto salvo tun0. Su macOS si usa PF e launchd con setup regole atomico. In caso di reconnect attivo, OpenVPN deve bloccare tutto prima che il TUN descriptor sia pronto. Per questo client avanzati partono con un blocco totale, poi alzano il tunnel, infine aprono il traffico via interfaccia.

IKEv2/IPsec: stack di sistema e selectors

IKEv2 su Windows e macOS si appoggia agli stack IPsec di sistema. Qui il kill switch spesso si fa OS-level: blocco uscite sull’interfaccia dell’adattatore virtuale, blocco 0.0.0.0/0 esterno, rotte esplicite per split-tunnel. Se la politica è no-split, tutto passa dal tunnel e gli altri sono bloccati globalmente. Su Linux strongSwan lega policy xfrm con nftables e routing per avere traffico non selezionato che semplicemente sparisce.

Client ibridi 2026: eBPF, NE e WFP

Tendenza 2026: meno hack, più integrazione. Su Linux eBPF filtra a livello di cgroup, su macOS NE con configurazioni PF precise e monitoraggio eventi, su Windows WFP senza trucchi utente. In più telemetria di stato: se l’interfaccia flappano, il client evita di toccare rotte ogni millisecondo, usando ritardi e transazioni per evitare fughe dati.

Configurazione passo passo: Windows, Linux, macOS

Windows 11: firewall e rotte

Piano base: prima blocco totale del traffico uscente, poi eccezioni per interfaccia VPN. Con PowerShell: si crea regola di blocco uscita per tutti i profili; si autorizza l’interfaccia VPN (es. "WireGuard Tunnel" o "Ethernet 5" a seconda del driver); si imposta la priorità interfacce – Set-NetIPInterface con AutomaticMetric Disabled e InterfaceMetric più basso per VPN. Così anche se il servizio VPN cade, il traffico resta bloccato. Trucchetto utile: una regola separata per loopback altrimenti alcune app si lamentano.

Linux (nftables + policy routing)

Procedura: si crea tabella inet vpn e catena output con policy drop. Si autorizza: interfaccia oifname "wg0" o "tun0", stato established, localhost. Separatamente si marcano i pacchetti fwmark (es. 0x1), si aggiungono ip rule lookup 100 per fwmark 0x1 e nella tabella 100 default si punta a VPN. Nella tabella principale manca il default o c’è un blackhole. Opzionale: cgroup-bpf per whitelist di servizi di amministrazione. Verifica con ping, curl bindato all’interfaccia, e traffico di sistema (NTP, sync) tutto deve passare dal tunnel.

macOS (PF + NE)

Come fare: avvia il client VPN su Network Extension e individua l’interfaccia utunX. Nel /etc/pf.conf crea anchor “vpn-killswitch”, attiva block drop di default, skip su lo0. Nell’anchor scrivi regole che permettono solo su utunX. Attiva pfctl caricando l’anchor. Configura DNS scoped nel client in modo che la risoluzione non “sfugga” all’esterno. Dopo il wake-up cattura eventi e aggiorna utunX nelle regole se il numero cambia. L’esperienza mostra che con questo metodo non ci sono fughe nemmeno con cambi Wi‑Fi bruschi.

Gestione app ed eccezioni

A volte servono eccezioni: aggiornamenti OS, agenti aziendali, VoIP fuori VPN. Fallo consapevolmente. Su Linux usa cgroup con regole separate. Su Windows WFP callout o regole AppPath/servizi. Su macOS NEFilterDataProvider con App Rules. Mantieni sempre un log completo: chi è uscito e perché. Per impostazione predefinita il kill switch resta rigido, eccezioni precise e controllate.

Verifica e test: come assicurarsi che il kill switch funzioni veramente

Controlli rapidi IP e DNS

1) Disconnetti VPN e verifica se c'è internet. Deve essere “no”. 2) Attiva VPN e apri pagina per vedere il tuo IP: deve apparire quello del provider VPN. 3) Taglia il tunnel forzatamente: ferma il servizio, disabilita interfaccia. Internet deve sparire. 4) Verifica DNS: effettua richieste e assicurati che passino dall’interfaccia VPN. Se la rete rimane aperta al crash, c’è una falla da correggere.

Ispezione di rotte e interfacce

Windows: route print, Get-NetRoute, Get-NetIPInterface - controlla metriche, rotte di default, NextHop su VPN. Linux: ip route, ip rule, ip -4 -6 route show table 100 - visualizza policy. macOS: netstat -rn, scutil --dns - verifica default route e scopes DNS. Disabilita tunnel e controlla che il default route sparisca e nessun default esterno rimanga senza blocco firewall. Se compare, devi migliorare la policy.

Sniffer minimale

Linux: tcpdump -i any not host indirizzo_VPN - non devono esserci pacchetti in uscita. Windows: pktmon integrato o Wireshark con filtro not ip.addr==VPN_IP e not interface==VPN. macOS: tcpdump -i en0 o en1 - quando tunnel cade silenzio totale. Lo sniffer è la prova più affidabile: se i pacchetti volano, c’è una falla.

Test race condition e sleep-wake

Scenario complesso ma rivelatore: download attivi, videochiamata, decine di tab browser, poi laptop va in sleep, torna, cambia Wi‑Fi con hotspot mobile, laptop veloce in dock station. Un kill switch ben fatto supera tutto senza inviare un byte fuori tunnel. Se nei log si vedono brevi fughe, rinforza le regole kernel, diminuisci le finestre tra rimozione e applicazione regole durante il reconnect.

Errori tipici e casi reali

Doppio default e metriche

Abbiamo visto errore classico: su Windows la metrica fisica è più bassa di quella VPN. Dopo aggiornamento driver le metriche “si ottimizzano automaticamente” e parte del traffico esce. Soluzione: fissare metriche manualmente e mantenere regole firewall con InterfaceAlias VPN chiaramente specificato.

Perdite DNS via DoH

I browser usano DoH con lista di resolver propria. Blocchi 53/udp? Bene, ma il browser continua a inviare DoH su 443 fuori tunnel. Soluzione: obbliga le app ad usare resolver di sistema tramite policy, e firewall consente DoH solo se oif=VPN. Su Linux utile nftables sets per IP provider DoH permessi e blocco globale per il resto.

Split-tunnel e fattore umano

Policy aziendali a volte permettono parte del traffico diretto. Il rischio è grande: un errore nella rete esclusa compromette la privacy. Approccio: split minimo necessario e audit rigoroso. Meglio risolvere whitelist domini via VPN e poi rilasciare indirizzi IP esterni solo se indispensabile.

Reti mobili e NAT64

LTE/5G a volte usano NAT64 e meccanismi di transizione che permettono a parte del traffico IPv6 di passare fuori filtro se blocchi solo IPv4. Assicurati che il kill switch copra IPv4 e IPv6. In AllowedIPs imposta 0.0.0.0/0 e ::/0. In nftables usa tabelle inet per gestire entrambi gli stack contemporaneamente.

Tecniche avanzate e tendenze 2026

eBPF su Linux: filtro a livello processo

Con eBPF ci si allontana dal blocco globale “alla sciabola” verso politiche intelligenti. cgroup-bpf permette di dire: di default nessun processo esce fuori wg0, ma il servizio “time update” può, e solo verso quel pool IP. Riduce problemi quando regole troppo rigide rompono funzionalità critiche. E rende il kill switch più amichevole senza perdere sicurezza.

Windows: WFP con telemetria di stato

I client moderni usano WFP callout che non solo droppa, ma “comprende” lo stato del tunnel. Se non è stabilito, blocco hard, se stabilito, permesso su interfaccia. Riduce le finestre temporali in cui le regole sono applicate ma il traffico già scorre. In più log dettagliati: quale processo ha tentato uscita, dove, quale protocollo — prezioso per investigazioni.

macOS: NE + PF con aggiornamenti atomici

Nel 2026 molti client hanno adottato aggiornamenti atomici di anchor PF: si genera una nuova configurazione, si carica in un nuovo anchor e si fa uno swap pulito. Niente interruzioni o conflitti. Inoltre NE permette di monitorare lo stato di rete: cambi Wi‑Fi aggiornano subito interfaccia e DNS scope nel client.

Protezione contro canali “nascosti”

Alcune app usano QUIC, uTP, proxy integrati per “ottimizzare” la rete. Il kill switch deve considerarli come possibili bypass. Soluzione: blocchiamo uscite su tutte le interfacce tranne VPN basandoci sullo stato del socket e non sulle porte; permettiamo solo se interfaccia o marchio coincidono. Così la mascheratura porta non aggira la policy.

Checklist di implementazione: passi da non saltare

Progettazione della policy

Decidi: tunnel totale o parziale. Lista di eccezioni, se inevitabili. Requisiti DNS (DoH, DoT). OS e versioni supportate (Windows 11 24H2+, kernel Linux 6.x, macOS 14+). Scenari sleep, roaming tra Wi‑Fi ed Ethernet, rete mobile.

Realizzazione tecnica

Windows: regole AdvFirewall + WFP; Linux: nftables + policy routing + eBPF se serve; macOS: NE + anchor PF. Fondamentale: bloccare tutto tranne oif VPN; vietare DNS fuori VPN; default route nel tunnel; buco nero per traffico se interfaccia cade.

Test e monitoraggio

Sniffer, stress test di reconnect, logging processi, verifica IPv6, verifica DoH, test app particolari (launcher di giochi, torrent, agenti aziendali). Monitoraggio: alert su default non VPN, notifiche caduta interfaccia, telemetria tentativi bypass.

Gestione operativa e rollback

Prepara una “chiave d’emergenza”: come rimuovere il kill switch se il client VPN si blocca e serve urgentemente internet. Su Windows uno script di rimozione regole, su Linux file con nft flush ruleset e backup config, su macOS pfctl -d con cautela e rollback del profilo NE. Fallo solo offline o con accordo per non compromettere la sicurezza.

Comandi pratici ed esempi: cheat sheet compatto

Windows PowerShell

Aggiungi blocco tutto uscente: New-NetFirewallRule -DisplayName "Block All Outbound" -Direction Outbound -Action Block -Profile Any. Permetti interfaccia VPN: New-NetFirewallRule -DisplayName "Allow VPN Outbound" -Direction Outbound -Action Allow -InterfaceAlias "Nome_interfaccia_VPN" -Profile Any. Fissa metriche: Set-NetIPInterface -InterfaceAlias "Nome_interfaccia_VPN" -AutomaticMetric Disabled -InterfaceMetric 5; per fisiche: 50 e oltre.

Linux nftables

Crea tabella e politica: add table inet vpn; add chain inet vpn output { type filter hook output priority 0; policy drop; }; add rule inet vpn output oifname "wg0" accept; add rule inet vpn output meta oifname "lo" accept; add rule inet vpn output ct state established,related accept. Policy routing: ip rule add fwmark 0x1 table 100; ip route add default dev wg0 table 100. Nella tabella principale, no default o blackhole default dev lo.

macOS PF

Nel pf.conf: set block-policy drop; set skip on lo0; anchor "vpn-killswitch"; nell’anchor: block out on ! utunX from any to any; pass out on utunX from any to any keep state; block out proto { udp, tcp } to port 53 on ! utunX. Attiva: pfctl -f /etc/pf.conf; pfctl -E. Aggiorna utunX al reconnect client.

Diagnostica DNS

Windows: Resolve-DnsName con tracing; verifica che server in Get-DnsClientServerAddress appartengano a VPN. Linux: resolvectl dns e resolvectl status; accertati che interfaccia sia tun/wg. macOS: scutil --dns — controlla scoped resolver; servizi di sistema devono indicare utun.

Perché a volte il kill switch "all’improvviso" non funziona e come risolvere

Race condition al reconnect

Se il client rimuove regole prima che il nuovo tunnel si alzi, si crea una finestra di millisecondi o secondi. Soluzione: transazioni atomiche. Prima mantieni blocco globale, poi alza tunnnel, infine apri regole sull’interfaccia. Solo così.

Servizi OS con privilegi speciali

Antivirus, agenti aziendali, aggiornamenti di sistema possono aggirare regole normali. Serve intrappolarli a livello kernel: WFP callout per Windows, cgroup-bpf per Linux, NEFilterDataProvider per macOS. Altrimenti un servizio "magico" apre una falla.

Incoerenza IPv6

Bloccare solo IPv4 è metà del lavoro. Nel 2026 IPv6 è ovunque. Controlla sempre ::/0, RA, SLAAC e blocca uscite fisiche su entrambi gli stack. Tabelle inet in nftables sono tue alleate, PF e WFP ce la fanno senza problemi.

Browser e stack di rete propri

Alcuni browser hanno stack DNS, QUIC e proxy propri. Disabilita “DNS-over-HTTPS sempre” se il tuo scenario non prevede il tunnel per DoH. Altrimenti DoH esce fuori. La soluzione migliore: DoH al tuo resolver dentro VPN e blocco severo per tutto il resto.

Conclusioni: come capire che hai un kill switch "corretto"

Segnali di una implementazione matura

Niente internet quando la VPN cade. Default route guarda al tunnel. DNS solo via VPN. IPv6 considerato. Eccezioni rare, puntuali e tracciate. Passa la verifica sniffer. Sleep, roaming, reconnect senza fughe.

Cosa ti dà davvero

Tranquillità. Vero. Sapere che se l’interfaccia cade nessun byte uscirà all’esterno ti permette di lavorare, guardare video, sincronizzare dati. Niente paura dei “secondi di verità”. Il kill switch è il salvavita che non tradisce.

Punto d’azione

Controlla oggi la tua configurazione. Correggi doppi default. Rafforza le regole. Chiudi il DNS. E con i log assicurati che quando VPN tace anche il traffico tace. Il resto sono dettagli.

FAQ: domande frequenti sul VPN kill switch

Si può fare un kill switch senza permessi amministrativi?

Affidabile, no. Servono permessi per modificare rotte e firewall. Altrimenti è solo un gioco, non una protezione.

In cosa differisce il kill switch da "bloccare internet in caso di disconnessione" nel client?

Un kill switch vero vive nel kernel e firewall. "Bloccare internet" nell’app arriva in ritardo e perde le gare di timing. Servono WFP, nftables, PF.

Se uso split-tunnel il kill switch perde senso?

No. Blocca comunque traffico non autorizzato. Ma i rischi aumentano: lo split è più complesso e richiede configurazioni precise.

Serve bloccare IPv6 se il provider non lo fornisce?

Sì. Le app possono creare sessioni IPv6 locali tramite reti vicine. Blocca su entrambi gli stack.

Come verificare che DoH non esca fuori VPN?

Sniffer sull’interfaccia fisica e regole firewall: permetti DoH solo su interfaccia VPN, blocca tutto il resto.

WireGuard di per sé garantisce il kill switch?

Quasi. Se AllowedIPs è 0.0.0.0/0, ::/0 e rotte configurate bene, però senza firewall ci sono finestre di fuga durante reconnect. Servono regole drop fuori wg.

Perché dopo la caduta VPN ho ancora accesso alla rete locale?

Le regole lo permettono. Permettere link-local e LAN a volte è necessario. Se vuoi più rigore, blocca anche loro, ma rischi di perdere stampanti e condivisioni.