La regola di Sophos Firewall non si applica: verifica delle cause

Quando una regola di Sophos Firewall non si applica, non si dovrebbero spostare subito le regole o ampliare gli oggetti. Per prima cosa occorre riprodurre e osservare un singolo flusso di dati: il pacchetto arriva, quali Firewall Rule ID e NAT Rule ID lo elaborano, viene inoltrato e arriva una risposta?

Nella maggior parte dei casi emerge che una condizione è diversa dal previsto, che si applica una regola più generale posizionata più in alto o che il problema si verifica solo dopo la decisione della regola. Il firewall stesso è molto meno spesso la causa rispetto a un test definito in modo impreciso.

Decisione rapida: Se un Packet Capture avviato e filtrato correttamente non mostra alcun pacchetto, verificare prima client, VLAN, gateway o il percorso a monte. Una Rule ID diversa rimanda all’ordine e al matching. Se Rule ID e NAT ID sono corrette, proseguire l’analisi con routing, percorso di ritorno, sistema di destinazione o un modulo di sicurezza.

Percorso rapido: seguire un flusso concreto

Per la prima delimitazione sono sufficienti sei passaggi:

1. Definire il flusso di test: Annotare Source IP, Source zone, utente, destinazione, protocollo, porta e ora.
2. Dimostrare l’ingresso: Avviare Packet Capture con un filtro di cattura ristretto e generare lo stesso flusso.
3. Verificare la Firewall Rule ID: Confrontarla con la regola prevista in Log Viewer o Packet Capture.
4. Verificare la NAT Rule ID: Se è coinvolto NAT, controllare la regola NAT effettiva e la sua traduzione.
5. Verificare inoltro e risposta: Cercare Forwarded, l’interfaccia di uscita e i pacchetti di ritorno.
6. Solo dopo approfondire: Esaminare routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy o il sistema di destinazione.

Questa procedura mantiene separati i livelli. Una regola firewall decide l’accesso e le funzioni di protezione, NAT traduce indirizzi o porte, il routing sceglie il percorso successivo e il sistema di destinazione deve conoscere il percorso di ritorno. Se tutti i livelli vengono modificati contemporaneamente, il sintomo può scomparire, ma la causa rimane poco chiara.

Se il test è diretto a WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP o a un altro servizio del firewall stesso, non si applicano le stesse regole del traffico in transito. In questo caso, il percorso diagnostico porta direttamente a Administration > Device access e alla Local Service ACL.

Definire un caso di test riproducibile

Un’affermazione come «Internet non funziona» o «la regola VPN non si applica» è troppo generica. Un caso di test utile può essere, ad esempio:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com oppure intenzionalmente nessun User Matching
• Destination: app.example.net, attualmente risolto in 203.0.113.20
• Service: TCP 443
• Regola firewall prevista: LAN-App-HTTPS, Rule ID 37
• Regola NAT prevista: NAT Rule ID 12 oppure esplicitamente nessuna regola NAT
• Ora del test: 2026-08-08 10:15:00

Gli indirizzi IP, gli ID, i nomi e l’ora sono valori di esempio e devono essere sostituiti con quelli del proprio ambiente. Ciò che conta è la forma: durante la diagnosi, origine, IP di destinazione, porta e utente restano invariati. Se nel frattempo cambiano la risoluzione DNS, il client o l’applicazione, non si sta più confrontando lo stesso flusso.

Interpretare le prime osservazioni

• Un Packet Capture attivo non mostra alcun pacchetto nonostante un filtro adatto: Verificare prima lo stato della cattura, il filtro e il buffer. Se sono corretti, la causa si trova probabilmente prima del firewall, ad esempio nel client, nella VLAN, nello switch, nel gateway, nel provider o nel Security Group cloud.
• Log Viewer mostra una Rule ID diversa: Viene valutata prima una regola più generale, generata automaticamente o comunque corrispondente.
• La Firewall Rule ID è corretta, la NAT Rule ID no: Verificare l’ordine NAT e source, destination e service originali.
• Rule ID e NAT ID sono corrette, ma non è visibile alcun Forwarded: Verificare l’azione della regola, Reason, il routing o un modulo di sicurezza.
• Forwarded è visibile, ma non arriva alcuna risposta: Verificare la route di ritorno, il sistema di destinazione, il firewall locale del server o un blocco esterno.
• Sono interessati solo determinati utenti: Controllare separatamente l’autenticazione e lo User Matching del flusso di dati effettivo.

La procedura combinata dettagliata è disponibile in Testare una regola firewall con Log Viewer, Policy Tester e Packet Capture. Questo articolo si concentra sulla spiegazione di un match di regola inatteso.

Verificare l’ordine e il matching delle regole

Una regola firewall si applica solo se tutti i criteri rilevanti corrispondono e nessuna regola precedente ha già elaborato lo stesso traffico.

La prima regola corrispondente vince

Sophos Firewall valuta le regole dall’alto verso il basso e interrompe la ricerca alla prima regola corrispondente. La posizione nell’elenco è quindi decisiva; la Rule ID è solo un identificatore fisso e non corrisponde alla posizione.

Occorre inoltre considerare quanto segue:

• Una regola generale posizionata sopra può nascondere completamente una regola specifica sottostante.
• I Rule Groups migliorano la visione d’insieme, ma non creano una propria logica di matching. Vengono valutate le regole che contengono.
• Le regole generate automaticamente, ad esempio per MTA, IPsec o hotspot, possono essere inserite in alto e verificate per prime.
• Un filtro attivo nella tabella delle regole può nascondere regole rilevanti. Prima dell’analisi utilizzare Reset filter.
• La regola Default Drop non modificabile ha Rule ID 0, si trova alla fine e non dispone di un normale Usage Counter. I filtri della tabella non si applicano a questa regola.

Per riesaminare completamente la logica di base di una regola, consultare Comprendere e configurare correttamente le regole di Sophos Firewall.

Leggere insieme tutti i criteri di matching

Una regola che appare corretta può fallire a causa di un solo campo:

• Source zones: Il client proviene da un’altra zona, ad esempio VPN anziché LAN, oppure la VLAN è assegnata diversamente.
• Source networks and devices: L’oggetto IP, il gruppo di host o la sottorete non contiene la Source IP effettiva.
• Destination zones: La zona di destinazione è errata, soprattutto con DNAT, VPN o reti instradate.
• Destination networks: L’IP effettivamente contattato non corrisponde all’oggetto oppure sono state confuse le viste pre e post NAT.
• Services: Manca la porta, TCP e UDP sono stati scambiati oppure l’applicazione apre connessioni aggiuntive.
• Users or groups: Il firewall non riesce ad associare l’utente alla Source IP oppure il gruppo importato non corrisponde.
• Schedule: La pianificazione non è attiva al momento del test.
• Exclusions: Il flusso viene escluso dalla regola e poi confrontato con le regole successive.

Per il traffico web, anche il protocollo fa parte del test. I browser possono utilizzare QUIC su UDP 443, mentre la regola o l’ispezione web prevista copre solo il classico HTTPS su TCP 443. Controllare QUIC su Sophos Firewall ne spiega gli effetti.

Azzerare in modo controllato il volume di dati trasferiti

La voce di menu Reset data transfer count può essere utile durante il test, ma viene spesso interpretata male. Azzera il volume di dati trasferiti attraverso la regola; non è un contatore di sessioni o corrispondenze.

1. Aprire Rules and policies > Firewall rules.
2. Cercare la regola interessata e aprire il menu a tre punti.
3. Selezionare Reset data transfer count.
4. Generare nuovamente il flusso di test definito.
5. Valutare insieme volume di dati, Rule ID e Packet Capture.

Se il valore aumenta dopo il test controllato, indica che è stato trasferito traffico attraverso questa regola. Se rimane invariato, ciò da solo non dimostra che la regola non abbia mai trovato corrispondenza. Per una conclusione affidabile, verificare la Rule ID effettiva in Log Viewer e il percorso dei pacchetti in Packet Capture. Questo contatore di dati non è comunque disponibile per la regola Default Drop ID 0.

Leggere correttamente Log Viewer, Policy Tester e Packet Capture

Gli strumenti rispondono a domande diverse:

• Log Viewer: Quale sessione registrata, regola, regola NAT, azione e utente sono stati rilevati?
• Policy Tester: Quale logica di policy si applicherebbe ai valori inseriti?
• Packet Capture: Quali pacchetti arrivano realmente, come li elabora il firewall e vengono inoltrati nuovamente?

Nessuno strumento sostituisce completamente gli altri. Se la simulazione e il flusso di pacchetti effettivo si contraddicono, i dati di log e dei pacchetti del test riproducibile hanno maggiore importanza.

Log Viewer: Rule ID e NAT Rule ID effettive

Nella regola firewall deve essere attivato Log firewall traffic. Inoltre, in System services > Log settings deve essere abilitato il tipo di log appropriato per la visualizzazione locale, Sophos Central o syslog.

Per il test sono utili filtri sui seguenti campi:

• Source IP e Destination IP
• Porta o servizio
• Rule ID e Rule name
• NAT rule ID
• Action e User
• l’ora del test annotata

L’assenza di una voce non dimostra ancora che il firewall non abbia visto nulla. Le sessioni firewall vengono registrate, tra l’altro, quando la connessione termina con un evento Destroy. In caso di interruzione improvvisa della connessione, la voce prevista può quindi mancare o apparire più tardi. Packet Capture fornisce in tal caso il risultato più diretto. I servizi e i file di log pertinenti sono descritti in Troubleshooting di Sophos Firewall: servizi e log.

Policy Tester: logica di policy senza un flusso di pacchetti reale

In Diagnostics > Tools > Policy tester si impostano deliberatamente URL, utente, ora, Source IP e Source zone. Protocollo e porta devono risultare dall’URL completo, ad esempio https://app.example.net:8443/. Senza protocollo, lo strumento testa HTTP; per HTTPS viene utilizzata per impostazione predefinita la porta 443, mentre una porta diversa deve essere indicata nell’URL.

Policy Tester è utile, ma presenta limiti chiari:

• Non genera un flusso di pacchetti reale e non verifica né il sistema di destinazione né il percorso di ritorno.
• I risultati non riflettono le route SD-WAN.
• Le regole con indirizzi MAC in Source networks and devices non possono trovare corrispondenza.
• I problemi di provider, switch, gateway e perdita di pacchetti restano invisibili.

⚠️ Su SFOS 22.0 GA Build 411, NC-177587 e NC-176083 potevano causare risultati errati di Policy Tester. Il traffico appariva bloccato o associato alla regola sbagliata, anche se in realtà fluiva correttamente. MR1 Build 490 contiene le correzioni documentate. In caso di risultati contraddittori, verificare prima la versione del firmware, Log Viewer e Packet Capture, prima di modificare le regole di produzione.

Packet Capture: verificare il percorso effettivo dei pacchetti

In Diagnostics > Packet capture si imposta innanzitutto un filtro di cattura BPF ristretto, ad esempio su Source IP, Destination IP e porta del flusso di test. Quindi si attiva Trace On, si svuota l’elenco e si genera esattamente il flusso definito.

Un Packet Capture vuoto è significativo solo se sono soddisfatte queste condizioni:

1. Trace On è attivo.
2. Il filtro di cattura BPF corrisponde alla destinazione effettiva e non nasconde il flusso.
3. Il buffer non ha già sovrascritto il traffico di test rilevante. Senza Wrap capture buffer once full, la registrazione si arresta quando il buffer da 2048 KB è pieno e riprende con Clear. Con l’opzione Wrap attiva, la registrazione continua e sovrascrive i pacchetti più vecchi.

Un Display Filter aggiuntivo non modifica ciò che è stato registrato, ma può nascondere le voci esistenti. Pertanto, verificare separatamente il filtro di cattura e il Display Filter.

I valori di stato significano:

• Incoming: Il pacchetto è stato ricevuto su un’interfaccia.
• Forwarded: Il firewall inoltra il pacchetto tramite un’interfaccia di uscita.
• Consumed: Il pacchetto è destinato al firewall stesso o viene utilizzato da quest’ultimo.
• Generated: Il firewall ha generato autonomamente il pacchetto.
• Violation: Una violazione di policy causa lo scarto; il campo Reason spiega più precisamente il motivo.

Rule ID, NAT ID, Reason e interfacce di ingresso e uscita devono essere sempre letti insieme. Consumed e Generated sono risultati normali e non rappresentano automaticamente errori.

⚠️ Su SFOS 22.0 MR1 Build 490, NC-178387 può mostrare gli scarti della regola predefinita ID 0 solo come Incoming. La voce prevista Violation Firewall e la voce in drppkt mancano, sebbene il firewall continui a scartare il flusso. Per questa versione interessata possono essere utili Policy Tester o una regola di scarto con logging, posizionata deliberatamente alla fine dell’elenco di regole personalizzato. L’attuale indicazione Known Issues non specifica una versione corretta.

Una procedura dettagliata di cattura è disponibile in Utilizzare Packet Capture in Sophos Firewall WebAdmin. Analizzare i pacchetti scartati su Sophos Firewall tratta gli scarti e una regola finale controllata.

Verificare NAT, DNAT, routing e percorso di ritorno

NAT non consente il traffico. Traduce indirizzi o porte per il traffico consentito da una regola firewall. Pertanto, Firewall Rule ID e NAT Rule ID devono corrispondere separatamente.

Valutare insieme Firewall Rule ID e NAT Rule ID

• La Firewall Rule ID è corretta, la NAT Rule ID è errata: Verificare l’ordine NAT, i campi Original e le regole NAT più generali.
• La NAT Rule ID è corretta, la Firewall Rule ID è errata: Confrontare ordine delle regole firewall, zone, source, destination, service e schedule.
• Entrambi gli ID sono corretti, ma la connessione non riesce: Verificare routing, percorso di ritorno, server di destinazione, modulo di sicurezza o applicazione.
• Non è visibile alcuna NAT Rule ID, sebbene sia previsto NAT: Controllare direzione, Inbound/Outbound Interface e criteri originali della regola NAT.

Anche in Rules and policies > NAT rules vince la prima regola corrispondente. Una regola SNAT o MASQ generale può quindi nascondere una regola specifica sottostante. Inoltre, le Linked NAT Rules vengono prese in considerazione solo per il traffico che corrisponde alla regola firewall associata; una regola NAT autonoma precedente può comunque applicarsi per prima.

Comprendere NAT su Sophos Firewall spiega la logica completa degli ID.

Comprendere DNAT dal punto di vista pre e post NAT

Per il traffico DNAT in ingresso vale un’importante regola generale:

La regola firewall utilizza la zona di destinazione dopo NAT, ma come Destination Network l’indirizzo contattato originariamente prima di NAT.

Esempio di port forwarding:

• Il client esterno si connette a 198.51.100.10 su TCP 8888.
• La regola NAT traduce verso il server 10.10.50.20 nella zona DMZ e verso TCP 4444.
• Nella regola NAT, TCP 8888 è l’Original service e TCP 4444 il Translated service (PAT).
• La regola firewall utilizza WAN come Source zone, DMZ come Destination zone e 198.51.100.10 come Destination network.
• Nell’esempio PAT ufficiale di Sophos, la regola firewall associata contiene sia il servizio originale sia quello tradotto.

Il test esterno continua a essere eseguito verso la porta 8888; il server interno riceve la connessione sulla porta 4444. Se si considera solo una delle due porte, la regola può sembrare corretta anche quando matching del servizio e traduzione non coincidono. La pubblicazione completa è descritta in Pubblicare un server tramite DNAT su Sophos Firewall.

Stabilire una nuova connessione dopo modifiche NAT

Sophos Firewall valuta una regola NAT solo per il primo pacchetto di una connessione. Le sessioni esistenti continuano a utilizzare la traduzione precedente, anche se nel frattempo la regola NAT è stata modificata.

Dopo una correzione NAT, stabilire una nuova connessione: terminare il test in corso, chiudere la sessione esistente del browser o dell’applicazione e avviare nuovamente il flusso. Un reload all’interno della stessa sessione TCP non dimostra in modo affidabile la nuova configurazione NAT.

Esaminare il routing solo dopo aver confermato il match

Se Rule ID e NAT Rule ID sono corrette e Packet Capture mostra Forwarded, il matching della regola è dimostrato in linea di principio. Successivamente verificare:

• route statica o Default Route appropriata
• SD-WAN route e gateway attivo
• interfaccia di uscita effettiva
• route sul sistema di destinazione e nelle reti remote
• percorso di ritorno simmetrico tramite VPN, MPLS o WAN
• firewall locale del server di destinazione

Policy Tester non riflette SD-WAN. Per la decisione effettiva sono determinanti Gateway ID, interfaccia e percorso dei pacchetti. Regolare la priorità di routing su Sophos Firewall spiega l’ordine delle route statiche, SD-WAN e VPN.

Casi speciali dopo il primo risultato

Solo dopo aver classificato il flusso di base è utile approfondire servizi locali, utenti, risoluzione dei nomi o moduli di sicurezza.

Traffico verso il firewall stesso: Device Access invece di una regola firewall

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS e SNMP terminano sul firewall. Packet Capture può quindi mostrare lo stato Consumed. L’accesso viene controllato in Administration > Device access e con le Local Service ACL Exception Rules, non con una normale regola di transito.

Verificare zona, rete sorgente attendibile, servizio autorizzato, autorizzazione dell’utente e MFA. Proteggere Sophos Firewall Device Access e Local Service ACL spiega l’interazione rilevante per la sicurezza; Panoramica dei portali Sophos Firewall classifica le diverse interfacce web.

Separare login utente e User Matching

Un login riuscito a VPN Portal, User Portal, Captive Portal o tramite Entra ID SSO conferma inizialmente solo l’autenticazione. Affinché la regola utente prevista si applichi, il firewall deve anche associare l’utente al flusso di dati effettivo e alla relativa Source IP.

Risultati tipici:

• Il campo User in Log Viewer è vuoto: Verificare STAS, AD SSO, Captive Portal, Entra ID SSO o Clientless User. Per un IP fisso del dispositivo, configurare e testare Clientless Users mostra l’associazione con la verifica in Live Users e il test negativo.
• L’utente è visibile, ma si applica un’altra regola: Confrontare la posizione della regola, la condizione del gruppo o una regola più generale posizionata sopra.
• Sono interessati solo gli utenti VPN: Verificare la zona VPN, il pool VPN, Source network e il matching dei gruppi.
• Sono interessati solo singoli utenti: Confrontare UPN, indirizzo e-mail, gruppo di directory importato e gruppo Sophos Firewall.

Per gli ambienti AD locali sono utili Configurare STAS su Sophos Firewall e Aggiungere Active Directory a Sophos Firewall. A seconda del percorso di login Entra, consultare Entra ID SSO per Sophos Connect e VPN Portal oppure Entra ID SSO per Captive Portal. Con un numero molto elevato di utenti rilevati o Clientless Users può essere rilevante anche il limite User ID di Sophos Firewall.

Verificare DNS, FQDN, CDN e IPv6

Per il matching della regola conta l’IP di destinazione effettivamente utilizzato, non solo l’hostname inserito. Cache DNS, Split DNS, servizi CDN, un altro resolver, destinazioni API aggiuntive o IPv6 possono indirizzare il flusso verso un altro indirizzo.

Il firewall risolve autonomamente i normali FQDN Hosts e aggiorna l’associazione in base al TTL DNS. I Wildcard FQDN funzionano diversamente: il firewall apprende gli indirizzi IP dei sottodomini corrispondenti dalle risposte DNS osservate. Se il client utilizza un resolver esterno, il relativo traffico DNS UDP sulla porta 53 deve attraversare il firewall. Se il firewall non vede la risposta interessata, l’IP del sottodominio può mancare nell’oggetto wildcard e la regola può non trovare corrispondenza, nonostante il nome sembri corretto.

Inoltre, gli FQDN Hosts non supportano la risoluzione IPv6. Prima di ampliare un oggetto, confrontare la risposta DNS, l’IP di destinazione e la versione IP con Log Viewer o Packet Capture. I dettagli su TTL, wildcard e comportamento di apprendimento sono disponibili in FQDN Hosts e Wildcard FQDN su Sophos Firewall. Per la risoluzione interna sono utili le DNS Request Routes; un ambiente IPv6 attivo necessita di regole proprie adeguate e di una strategia IPv6 ben definita.

Distinguere moduli di sicurezza e Traffic Shaping

Se Firewall Rule ID, NAT Rule ID e routing sono corretti, un modulo assegnato alla regola può influenzare l’applicazione:

• Web Policy e Application Control
• SSL/TLS inspection rule e Decryption Profile
• IPS Policy e Malware Scan
• Zero-Day Protection
• Security Heartbeat

Si isola sempre un solo modulo per il flusso concreto e per un breve periodo di test. Un’eccezione rimane limitata a source, destinazione e servizio; successivamente si ripristina la protezione originale oppure si documenta l’eccezione necessaria. Per i problemi HTTPS è utile il rollout controllato di TLS Inspection.

Traffic Shaping, invece, è una funzione QoS. Garantisce, assegna priorità o limita la larghezza di banda e può quindi causare throughput basso, perdita di pacchetti in caso di congestione o timeout. Non è la stessa cosa della decisione di accesso Drop o Reject. Per un blocco effettivo, verificare lo stato di Packet Capture, Reason e il modulo di sicurezza responsabile. Per trasferimenti di grandi dimensioni o connessioni VPN, includere anche MTU e MSS nell’analisi.

Testare e documentare le modifiche in modo controllato

In caso di problemi con le regole, modificare una sola variabile per ogni test:

1. Annotare lo stato iniziale con source, destinazione, servizio, utente, ora, Rule ID e NAT ID.
2. Modificare esattamente una posizione di regola, un oggetto, un servizio o un modulo.
3. Per NAT, stabilire una nuova connessione; altrimenti, generare nuovamente lo stesso flusso di test.
4. Confrontare Log Viewer e Packet Capture con gli stessi filtri.
5. Documentare il successo o il fallimento e solo dopo verificare la modifica successiva.

Le regole temporanee Allow, Drop o di eccezione ricevono un nome comprensibile, un Owner e una data di scadenza. In caso contrario, un aiuto diagnostico temporaneo può rapidamente rimanere in modo permanente nell’insieme di regole.

Se la connessione funzionava ancora il giorno precedente, nella verifica rientrano anche le ultime modifiche alla configurazione. Audit Trail Logs mostra chi ha modificato regole o oggetti. Config Studio aiuta a confrontare configurazioni più estese. Se la modifica proviene da Sophos Central, verificare anche la Central Firewall Task Queue.

Checklist per il troubleshooting delle regole

• È stato definito un flusso di test concreto con source, destinazione, servizio, utente e ora.
• È stato verificato se si tratta di traffico in transito o di un servizio locale del firewall.
• Sono stati controllati la posizione delle regole, le regole automatiche e i filtri nascosti della tabella.
• Tutti i campi di matching sono stati confrontati con il flusso effettivo.
• Il volume di dati è stato utilizzato solo come indicazione e non come contatore di corrispondenze.
• Log Viewer mostra la Firewall Rule ID effettiva e, se applicabile, la NAT Rule ID.
• Il risultato di Policy Tester è stato confrontato con la versione del firmware e i dati effettivi dei pacchetti.
• Packet Capture è in esecuzione con un filtro di cattura adatto e spazio disponibile nel buffer.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason e le interfacce sono stati interpretati correttamente.
• Per DNAT sono stati verificati la zona di destinazione dopo NAT, Destination Network prima di NAT ed entrambi i servizi PAT.
• Dopo le modifiche NAT è stata stabilita una nuova connessione.
• Sono stati verificati risposta DNS, IP di destinazione, comportamento di apprendimento FQDN e versione IP.
• Login utente e User Matching del flusso di dati sono stati verificati separatamente.
• Routing, SD-WAN, gateway e percorso di ritorno sono stati esaminati solo dopo aver confermato il match della regola.
• I moduli di sicurezza sono stati verificati singolarmente e Traffic Shaping come QoS.
• Ogni modifica è stata documentata; le regole di test hanno un Owner e una data di scadenza.

FAQ