Configurare zone e interfacce Sophos Firewall

Zone e interfacce sono una delle basi più importanti di Sophos Firewall. Se vengono pianificate bene, regole firewall, NAT, VPN, Web Protection e troubleshooting diventano molto più semplici. Se vengono configurate in fretta, spesso nasce un ambiente in cui le regole diventano confuse o i servizi di management sono raggiungibili dai punti sbagliati.

Una zona è un gruppo logico di sicurezza. Un interface è una connessione fisica o virtuale, per esempio Port1, una VLAN, un bridge, un LAG, un alias, un’interfaccia RED o un’interfaccia XFRM per VPN route-based. Ogni interface è assegnata esattamente a una zona. Le regole firewall usano molto queste zone, quindi la struttura va pianificata anche dal punto di vista della sicurezza.

Perché le zone sono importanti

Le zone in Sophos Firewall sono più di un raggruppamento visivo. Definiscono aree di sicurezza e vengono usate in diversi punti:

• Le regole firewall usano Source zone e Destination zone.
• Device Access controlla per zona quali servizi locali del firewall sono raggiungibili.
• NAT, SD-WAN, VPN, Web Protection e log sono più facili da capire con zone pulite.
• Il troubleshooting è più chiaro, perché si vede subito da quale area di sicurezza arriva un pacchetto e dove deve andare.

Una buona suddivisione in zone non evita automaticamente ogni errore, ma impone confini chiari. Una rete client, una rete server, una WiFi ospiti e una DMZ non dovrebbero essere trattate tutte come LAN se hanno rischi e regole diverse. Altrimenti compaiono più tardi regole Allow troppo ampie, eccezioni poco chiare e accessi di management inutilmente aperti.

Una buona zona risponde sempre a questa domanda: quali reti hanno lo stesso livello di fiducia e possono essere trattate in modo simile? Se due reti hanno diritti di accesso, requisiti di logging o accessi di management diversi, conviene una zona dedicata o almeno un concetto di regole molto consapevole.

Capire le zone standard

Sophos Firewall include diverse zone standard:

Le zone standard si trovano in Network > Zones. Le zone personalizzate possono essere create come tipo LAN o DMZ. Non è possibile creare liberamente ulteriori zone WAN o VPN, perché questi tipi hanno funzioni speciali nel firewall.

Importante: una zona non è un’autorizzazione automatica. Anche tra due interfacce nella stessa zona servono regole firewall adatte, a seconda della direzione e dello scenario. Sophos indica esplicitamente che il traffico tra due interfacce in una zona LAN non è automaticamente consentito e richiede una regola LAN-to-LAN adatta.

Pianificare le zone prima di crearle

Prima di creare le zone, conviene annotare quali reti hanno requisiti di sicurezza diversi. Esempi tipici:

• LAN postazioni
• rete server
• rete di management
• DMZ
• WiFi ospiti
• VoIP
• rete telecamere o IoT
• rete di produzione
• client VPN
• collegamenti MPLS o tra sedi

Una zona dedicata ha senso se una rete richiede regole proprie, Device Access proprio o un diverso livello di fiducia. Più VLAN possono anche stare nella stessa zona se devono essere trattate allo stesso modo. Troppe zone non rendono automaticamente una configurazione più sicura. Aiutano solo se dietro ci sono regole chiare.

Per molte infrastrutture piccole e medie, questa struttura di base è un buon punto di partenza:

Non ogni VLAN richiede automaticamente una propria zona. Se più VLAN client ricevono esattamente le stesse regole firewall, la stessa web policy e lo stesso Device Access, possono restare in una zona client comune. Se però una VLAN può raggiungere i server, un’altra solo Internet e una terza non deve accedere a servizi locali del firewall, la separazione va modellata consapevolmente.

Uno schema utile:

Creare una nuova zona

Aprire Network > Zones e cliccare Add.

1. Assegnare un nome breve e chiaro, per esempio Server, Guest, Management o MPLS.
2. Scegliere LAN o DMZ come tipo.
3. In Device Access, definire consapevolmente quali servizi locali del firewall devono essere raggiungibili da questa zona.
4. Salvare.

LAN o DMZ come tipo di zona?

Per le zone personalizzate, Sophos Firewall permette normalmente di scegliere tra LAN e DMZ. Entrambi i tipi raggruppano interfacce per usarle poi in modo pulito in regole, Device Access e policies. La differenza è soprattutto nell’idea di sicurezza dietro la zona.

LAN si usa per reti interne e generalmente affidabili, per esempio reti client, reti server interne, management, VoIP, stampanti o VLAN interne. Anche con una zona LAN, il traffico tra interfacce non è automaticamente consentito. Se due zone LAN o due interfacce all’interno di una zona LAN devono comunicare, servono regole firewall adatte.

DMZ si usa per reti con rischio maggiore o isolamento chiaro. Esempi tipici sono server web pubblici, reverse proxy, mail gateway, jump host o sistemi che devono essere raggiungibili da più aree di sicurezza. Una DMZ dovrebbe essere pianificata in modo da consentire verso l’interno solo le connessioni necessarie. Se un server nella DMZ viene compromesso, non deve derivarne un accesso ampio alla LAN interna.

Regola pratica:

Anche le interfacce HA devono stare in una zona DMZ. Per reti admin o client normali, LAN è di solito il tipo più adatto.

Per una rete admin interna, HTTPS può avere senso. Per reti client o ospiti, l’accesso di management va evitato. Ping/ping6 è spesso utile per troubleshooting, ma va attivato consapevolmente. DNS serve solo se i client in questa zona usano il firewall come server DNS.

⚠️ Device Access non è la stessa cosa di una regola firewall. Gli accessi ai servizi locali del firewall, per esempio WebAdmin, SSH, User Portal, DNS o Ping, sono controllati tramite Administration > Device access ed eccezioni ACL locali.

Configurare un’interfaccia

Le interfacce si trovano in Network > Interfaces. Un port fisico può essere usato per esempio come LAN, WAN o DMZ. Interfacce virtuali come VLAN, Bridge, LAG, RED o XFRM vengono create separatamente.

Per un’interfaccia fisica sono particolarmente importanti questi punti:

Solo le interfacce nella zona WAN ricevono una configurazione gateway. Le interfacce interne sono di solito statiche. Per collegamenti provider possono avere senso DHCP o PPPoE.

Nomi descrittivi sono importanti. PortD dopo sei mesi dice poco. Server VLAN, MPLS Provider, Guest WiFi o Core Switch Trunk aiutano molto di più nell’operatività.

Creare un’interfaccia VLAN

Un’interfaccia VLAN si crea in Network > Interfaces > Add interface > Add VLAN. Sono fondamentali Parent Interface, Zone, VLAN ID e configurazione IP.

Il Parent Interface è il port fisico o LAG su cui arriva la VLAN taggata. Se lo switch invia la VLAN su un altro port, untagged o con VLAN ID errato, il firewall può mostrare l’interfaccia VLAN, ma i client non la raggiungono in modo affidabile.

Per VLAN interne si usa di solito un indirizzo IP statico sul firewall, per esempio come default gateway della VLAN. La zona decide poi quali regole firewall, web policies e impostazioni Device Access si applicano. Per questo, quando si crea una VLAN non bisogna inserire solo l’indirizzo IP, ma anche decidere se la VLAN appartiene a Client, Server, Management, Guest, DMZ o un’altra zona.

Leggere correttamente lo stato dell’interfaccia

In Network > Interfaces, Sophos Firewall mostra messaggi di stato. Sono molto utili nel troubleshooting perché indicano rapidamente se un’interfaccia è solo configurata male o se manca davvero il link.

Se un’interfaccia mostra inaspettatamente Not configured o Unplugged, non bisogna cercare subito nelle regole firewall. Prima si controllano zone binding, link, SFP/transceiver, cavo, porta switch e, con DHCP/PPPoE, assegnazione dell’indirizzo.

Inquadrare VLAN, Bridge, LAG, Alias e RED

Sophos Firewall supporta diversi tipi di interfaccia. Per chi inizia, è importante soprattutto capire quando usare quale tipo.

Per nuove installazioni, VLAN su un uplink ben definito verso lo switch sono di solito più pulite di un grande bridge su molti port. Un bridge può essere pratico per migrazioni o setup molto semplici, perché più port vengono trattati come un unico segmento Layer 2. Ma questo è anche lo svantaggio: confini di sicurezza, domini broadcast e fonti di errore diventano meno visibili.

Raccomandiamo quindi i bridge solo in modo mirato, non come design standard. In pratica hanno diversi svantaggi:

• Più port condividono lo stesso segmento Layer 2, quindi broadcast e disturbi possono coinvolgere più dispositivi.
• Le regole firewall diventano meno leggibili, perché la separazione non è più visibile tramite interfacce, VLAN e zone dedicate.
• Il troubleshooting diventa più difficile perché packet flow, MAC learning, STP e configurazione switch vanno analizzati insieme.
• La segmentazione successiva diventa più complessa se da un bridge semplice devono nascere reti client, server, ospiti o management separate.
• Design HA, VLAN, DHCP o Device Access diventano rapidamente poco chiari se troppe funzioni passano da un bridge.

I bridge in Sophos Firewall possono essere creati su interfacce fisiche, RED, VLAN o LAG. Possono funzionare con o senza un proprio indirizzo IP. Qui nascono spesso equivoci:

• Senza indirizzo IP, il bridge lavora in modo trasparente, ma non può essere usato come una normale interfaccia routed.
• Se serve routing su un bridge, bisogna assegnargli un indirizzo IP.
• Il traffico tra membri del bridge richiede comunque regole firewall adatte tra le zone coinvolte, per esempio LAN verso LAN.
• STP può essere utile se esistono percorsi ridondanti e bisogna evitare loop.
• Filtri VLAN ed EtherType possono aiutare a limitare il traffico Layer 2 che attraversa il bridge.
• Sophos indica che il traffico su bridge senza IP può essere scartato se incontra una regola firewall con Web Proxy Filtering o una regola NAT. Questi drop non vengono loggati. Con NAT bisogna prestare attenzione a Source Translation o Override Source Translation.

Questo ultimo punto è importante: se tramite un bridge non si vedono log anche se il traffico non funziona, il problema non è sempre il Log Viewer. Può dipendere dal modo bridge, dal NAT o da Web Proxy Filtering.

Se sullo switch esistono già VLAN, il firewall dovrebbe riprenderle consapevolmente come interfacce VLAN dedicate. Questo crea zone più chiare, regole firewall più pulite e una migliore manutenzione a lungo termine.

RED Bridge: estendere una rete tra sedi

È tecnicamente possibile inserire interfacce RED in un bridge e quindi estendere una rete Layer 2 tra più sedi. Può servire in casi speciali, per esempio se un’applicazione deve restare nello stesso subnet o se una migrazione deve avvenire senza cambi IP immediati.

Raccomanderemmo questo design solo con molta prudenza. Un bridge su RED prolunga il dominio Layer 2 attraverso il tunnel. Broadcast, ARP, pacchetti unicast sconosciuti e altri effetti Layer 2 passano così su una connessione WAN o Internet. Questo può peggiorare la performance e rendere gli errori più difficili da capire. Se il tunnel RED è instabile, la rete estesa ne risente direttamente.

Nella maggior parte dei casi è meglio un design routed: ogni sede ha subnet propri, il firewall instrada tra le reti e le regole firewall definiscono esattamente cosa è permesso. È più pulito, più scalabile e molto più piacevole nel troubleshooting.

LAG: pianificare correttamente ridondanza e banda

Una Link Aggregation Group (LAG) combina più port fisici in un’interfaccia logica. È utile quando serve ridondanza verso il core switch o più banda tra firewall e switch. LAG non sostituisce una zonizzazione pulita. L’interfaccia LAG resta un’interfaccia su cui si possono usare VLAN o assegnare una zona.

Sophos Firewall supporta soprattutto due modalità comuni:

Importante: LACP funziona bene solo se il lato opposto è configurato correttamente. Sullo switch, i port devono essere nello stesso gruppo LAG, usare stessa velocità e stesso duplex e corrispondere alla configurazione del firewall. Se si crea un LAG solo sul firewall ma non sullo switch, spesso compaiono perdite di pacchetti o problemi asimmetrici difficili da capire.

Per i LAG valgono alcuni limiti pratici:

• Un LAG in Sophos Firewall è composto da due a quattro interfacce fisiche.
• Possono essere membri solo interfacce fisiche non assegnate con configurazione statica.
• Interfacce PPPoE, Cellular WAN e WLAN non possono essere membri LAG.
• Con LACP (802.3ad), i port membri devono avere stesso tipo e stessa velocità.
• La xmit-hash-policy decide come le sessioni vengono distribuite sui link. Una singola sessione TCP normalmente non diventa improvvisamente più veloce, perché di solito resta su un link.

Per piccoli ambienti, un trunk port pulito è spesso sufficiente. LAG conviene soprattutto quando il core switch deve essere collegato in modo ridondante, molti VLAN passano dallo stesso uplink o il firewall ha davvero bisogno di più throughput verso lo switch.

XFRM: capire IPsec route-based come interfaccia

Un’interfaccia XFRM appartiene al route-based IPsec VPN. Non viene pianificata come una VLAN o un port fisico normale, ma nasce nel contesto di una connessione IPsec. Sophos Firewall crea automaticamente un’interfaccia XFRM quando, in una connessione IPsec, sia i subnet locali sia quelli remoti sono impostati su Any.

È una differenza importante rispetto ai tunnel IPsec policy-based classici. Con route-based VPN non conta solo la IPsec Policy, ma anche routing, regole firewall e interfaccia XFRM. Questo rende più flessibili collegamenti tra sedi complessi, ma richiede pianificazione pulita:

• L’interfaccia XFRM si trova nella zona VPN.
• In Administration > Device access, IPsec deve essere consentito per la zona WAN affinché la connessione possa essere stabilita.
• Se subnet locali o remoti non sono Any, non viene creata alcuna interfaccia XFRM.
• MTU e MSS sono particolarmente importanti con route-based VPN, perché IPsec aggiunge overhead.
• Un’interfaccia XFRM non si disattiva direttamente in Network > Interfaces, ma tramite la connessione IPsec associata in Site-to-site VPN > IPsec.

Per gli admin, XFRM è rilevante soprattutto quando SD-WAN routing, routing dinamico o più reti su un tunnel tra sedi devono essere gestiti in modo pulito. Se serve solo una connessione Site-to-Site molto semplice con due reti fisse, un tunnel policy-based classico è spesso più facile da capire.

RED: sedi remote come concetto di interfaccia separato

Le interfacce RED non sono normali port switch. RED significa Remote Ethernet Device e viene usato per collegare una sede remota a Sophos Firewall tramite un tunnel cifrato. Si può realizzare con hardware SD-RED dedicato o con connessioni RED firewall-to-firewall.

Prima della pianificazione deve essere chiaro quale modalità serve:

Per molte aziende, Standard/Unified è la variante più pulita se la sede deve essere protetta completamente dal firewall centrale. Lo svantaggio è chiaro: se il tunnel RED cade, la sede può perdere anche l’accesso Internet gestito centralmente, a seconda del design. Standard/Split riduce questa dipendenza, ma significa anche che il traffico Internet locale non viene più filtrato e loggato completamente dal Sophos Firewall centrale.

Con RED conviene verificare presto questi punti:

• Il servizio RED deve essere attivato in System services > RED.
• La connessione richiede tipicamente TCP 3400, UDP 3410 e NTP 123.
• I dispositivi SD-RED hanno bisogno dell’ora corretta, altrimenti TLS handshake e tunnel setup possono fallire.
• Durante la prima messa in servizio, DHCP sull’uplink è di solito più semplice perché il dispositivo deve raggiungere il provisioning.
• I VLAN non sono ugualmente sensati in ogni modalità RED. Standard/Split e Transparent/Split non sono pensati per VLAN-tagged frames. Se servono VLAN dietro una SD-RED, la modalità va scelta con molta cura.
• Se un dispositivo RED è dietro un router provider, connessioni in uscita e DNS/NTP devono funzionare.

RED è molto pratico per piccole sedi, ma non va trattato come un normale cavo LAN. La decisione chiave è se la sede deve essere protetta centralmente, autonoma localmente o collegata solo in parte tramite tunnel. Questa decisione influenza DHCP, DNS, VLAN, routing, regole firewall, logging e troubleshooting.

Limitare correttamente Device Access

In Administration > Device access si vede quali servizi locali del firewall sono raggiungibili da quali zone. Tra questi:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

In ambienti produttivi vale: meno servizi locali sono raggiungibili da una zona, meglio è. In particolare HTTPS e SSH dovrebbero essere consentiti solo da reti di management fidate o tramite una Local service ACL exception rule.

Se serve SSH, questa guida aiuta: Connettersi a Sophos Firewall tramite SSH.

Tenere presenti le dipendenze

Le modifiche alle interfacce sono raramente isolate. Sophos indica che possono influenzare configurazioni dipendenti, per esempio:

• Zone Binding
• DNS
• gateways
• SD-WAN routes
• host basati su interfaccia
• interfacce VLAN
• Dynamic DNS
• regole firewall
• regole NAT

Prima di modifiche importanti, bisogna controllare in Object usage dove un’interfaccia, una zona o un oggetto host è già usato. Sophos Firewall mostra l’uso degli oggetti e collega direttamente a molte configurazioni dipendenti.

Quando si disattiva o elimina, bisogna fare particolare attenzione:

• Se un’interfaccia viene disattivata, la configurazione resta e lo stato è ancora visibile.
• I tunnel Site-to-site IPsec in cui il firewall è initiator vengono disconnessi immediatamente.
• I tunnel Site-to-site IPsec come responder e le connessioni Remote Access si disconnettono al più tardi per inattività o Dead Peer Detection.
• Interfacce Alias e XFRM non si disattivano direttamente come interfacce normali. Gli Alias seguono l’interfaccia fisica, le XFRM si disattivano tramite Site-to-site VPN > IPsec.
• Se viene eliminata un’interfaccia virtuale, possono essere rimosse anche regole firewall, configurazioni DHCP, voci ARP, route, interface host e altri riferimenti dipendenti.

Per questo, prima di eliminare bisogna sempre verificare se l’interfaccia è usata in regole firewall, regole NAT, DHCP, routing, SD-WAN, Dynamic DNS o oggetti host. Una cancellazione non attenta può rimuovere più della sola interfaccia.

Errori frequenti

Interface unbound o disabled: controllare se è assegnata una zona. Un’interfaccia fisica non può essere eliminata, ma la sua configurazione può essere rimossa impostando la zona su None.

VLAN non funziona: controllare VLAN ID, porta switch, configurazione tagged/untagged, native VLAN e parent interface corretto.

I client non raggiungono il firewall con Ping o HTTPS: non controllare prima le normali regole firewall. Verificare Administration > Device access ed eccezioni ACL locali.

Il traffico tra due reti interne non funziona: controllare Source zone, Destination zone, oggetti di rete, routing e posizione della regola firewall.

Il WAN gateway non diventa attivo: controllare configurazione IP, gateway IP, link status, credenziali PPPoE, DNS ed eventualmente WAN link manager.

Più interfacce WAN nello stesso subnet: se più interfacce WAN usano indirizzi IP dello stesso subnet, possono verificarsi problemi ARP e i gateway potrebbero non essere raggiungibili. Se un provider fornisce più IP pubblici nello stesso subnet, alias o LAG sono di solito più puliti di più interfacce WAN separate nella stessa rete.

SFP, port speed o breakout non corrispondono: la velocità di porta su switch, router, transceiver e firewall deve combaciare. Un port 25 Gbit/s non può essere collegato direttamente a un port 40 Gbit/s senza tecnologia adatta. Su modelli con porte 40G o 100G, i cavi breakout possono essere rilevanti se una porta deve essere divisa in più porte più piccole.

Problemi MTU con VPN o PPPoE: controllare MTU e MSS. Con traffico VPN, un valore MTU troppo alto può causare perdita di pacchetti che nella pratica sembra un problema di connessione casuale.

Troubleshooting

Per la ricerca guasti è pratico questo ordine:

1. Network > Interfaces: controllare link status, indirizzo IP, zona e gateway.
2. Network > Zones: controllare Device Access e tipo di zona.
3. Hosts and services: verificare che oggetti host e service siano corretti.
4. Rules and policies > Firewall rules: controllare Source zone, Destination zone, Services e ordine.
5. Rules and policies > NAT rules: se c’è NAT, confrontare attentamente Original e Translated.
6. Log viewer: verificare quale regola o drop viene applicato.
7. Diagnostics > Tools > Packet capture: verificare se i pacchetti arrivano e dove vengono inoltrati.

Quando zone e interfacce sono pulite, il passo successivo è più semplice: Capire e configurare correttamente le regole Sophos Firewall. Se il traffico non funziona nonostante una zona apparentemente corretta, aiuta la checklist La regola firewall non viene applicata: controllare ordine, matching e log. Per analisi più profonde si può anche usare Packet Capture nel WebAdmin e, per traduzioni o port forwarding, consultare Capire NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Ulteriori informazioni

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface