Pianificare correttamente zone e interfacce Sophos Firewall

Una zona raggruppa interfacce con un livello di attendibilità simile. L’interfaccia è il collegamento fisico o virtuale, ad esempio Port1, una VLAN oppure un’interfaccia LAG, RED o XFRM. Ogni interfaccia associata appartiene a una sola zona; le porte fisiche possono anche non essere associate.

Importante: una zona non consente automaticamente il traffico. Anche tra due interfacce nella zona LAN serve una regola firewall LAN-to-LAN adatta. L’accesso al firewall stesso, ad esempio a WebAdmin, SSH o DNS, è inoltre controllato tramite Device Access.

Configurare direttamente zone e interfacce

Creare una zona

In Network > Zones > Add si crea una zona personalizzata in quattro passaggi:

1. Assegnare un nome univoco, ad esempio Server, Management, Guest o IoT.
2. Selezionare LAN o DMZ come Type.
3. In Device Access, consentire solo i servizi locali del firewall realmente necessari da questa zona.
4. Salvare.

La zona dovrebbe quindi essere visibile in Network > Zones e selezionabile come Source zone o Destination zone in una regola firewall. Il traffico di produzione la attraversa solo dopo l’assegnazione di almeno un’interfaccia.

Le zone personalizzate possono essere solo di tipo LAN o DMZ. Non è possibile creare ulteriori zone WAN o VPN. SFOS assegna automaticamente le interfacce VPN alla zona VPN. Il firewall supporta fino a 100 zone.

Configurare un’interfaccia fisica

Una porta esistente si modifica in Network > Interfaces tramite Edit interface:

1. Assegnare un Name descrittivo, ad esempio Core Switch Trunk o MPLS Provider.
2. Selezionare la Network zone corretta.
3. Configurare IPv4 e, se necessario, IPv6.
4. Per le interfacce WAN controllare il gateway ed eventualmente MTU e MSS.
5. Salvare, quindi controllare stato del link, stato del gateway e Log Viewer.

Solo le interfacce nella zona WAN dispongono di una configurazione gateway. Le interfacce interne utilizzano normalmente indirizzi statici; le connessioni WAN possono essere statiche oppure configurate tramite DHCP o PPPoE.

Per attività specifiche sono disponibili guide dedicate:

• Configurare e verificare un’interfaccia VLAN
• Configurare un’interfaccia LAG
• Configurare Sophos SD-RED
• Proteggere Device Access
• Configurare una VPN IPsec site-to-site

Pianificare il modello delle zone

Distinguere zona, interfaccia e oggetto di rete

I tre elementi svolgono funzioni diverse:

• Zona: descrive l’area di sicurezza da cui proviene o verso cui è diretto il traffico.
• Interfaccia: collega il firewall fisicamente o virtualmente a una rete.
• Oggetto di rete: descrive l’indirizzo IP o la subnet concreta in una regola.

Una regola è precisa solo se zona e oggetto di rete sono corretti. Source zone: LAN insieme a Source networks: Any è spesso inutilmente ampio. Viceversa, un oggetto di rete corretto non aiuta se il pacchetto entra da una zona diversa da quella indicata nella regola.

Le zone predefinite hanno funzioni fisse:

• LAN per le reti interne
• WAN per provider e connessioni Internet
• DMZ per sistemi esposti o particolarmente isolati
• WiFi per i contesti WLAN
• VPN per tunnel Remote Access e site-to-site

Zone LAN personalizzate sono adatte, ad esempio, a Client, Server, Management, Guest, IoT, VoIP, Backup o OT. Una zona DMZ personalizzata è indicata per server pubblicati, reverse proxy o altri sistemi il cui accesso alla rete interna deve essere rigorosamente limitato.

Non ogni VLAN richiede una zona propria. Più VLAN possono essere raggruppate se livello di attendibilità, regole firewall e Device Access sono uguali. Se cambiano destinazioni consentite, accessi amministrativi o funzioni di protezione, una zona dedicata è normalmente più chiara.

Per utenti VPN o tunnel tra sedi non si creano tipi di zona VPN personalizzati. La separazione avviene nella zona VPN mediante oggetti di rete, utenti e regole firewall precisi.

Definire le direzioni di accesso prima delle regole

Prima della configurazione basta un breve elenco delle direzioni consentite, ad esempio:

• da Client a WAN: servizi web, DNS, NTP e applicativi necessari
• da Client a Server: solo porte applicative definite
• da Guest a WAN: accesso Internet, ma nessun accesso alle reti interne
• da IoT a Server: solo destinazioni necessarie come DNS, NTP o una piattaforma di gestione
• da Management alle zone interne: servizi amministrativi strettamente limitati e registrati
• da DMZ a LAN: bloccato per impostazione predefinita, salvo connessioni esplicitamente necessarie
• da VPN a Server: solo destinazioni e servizi autorizzati

Per ogni direzione consentita devono essere noti destinazione, servizi, necessità di NAT, logging e responsabile. Da queste informazioni derivano le regole. Struttura, ordine e matching sono descritti in Configurare correttamente le regole Sophos Firewall.

Verifiche prima di una modifica

Prima di creare o spostare un’interfaccia, chiarire almeno:

• zona e livello di attendibilità della rete
• indirizzo IP, subnet e default gateway
• origine DHCP e server DNS
• servizi locali del firewall necessari
• regole firewall e NAT
• routing e SD-WAN
• client di test, accesso previsto e voce di log prevista

Per le modifiche in produzione servono inoltre un backup recente, un percorso di ripristino e un controllo in Object usage.

Creare e collaudare una VLAN

Una VLAN si crea in Network > Interfaces > Add interface > Add VLAN. Sono determinanti:

• Interface: interfaccia fisica, RED, Bridge o LAG sulla quale arriva la VLAN taggata
• Network zone: area di sicurezza della VLAN
• VLAN ID: deve coincidere con switch ed eventualmente access point
• IPv4/IPv6 configuration: per VLAN interne, normalmente un indirizzo gateway statico

Una VLAN guest potrebbe trovarsi su Port3 con VLAN ID 20, zona Guest e gateway 192.168.20.1/24. Sullo switch, la VLAN 20 deve essere tagged sull’uplink verso Port3; una porta client o l’SSID guest assegna i dispositivi a questa VLAN.

Il firewall può mostrare correttamente l’interfaccia anche se lo switch invia la VLAN sulla porta errata, untagged o con un VLAN ID diverso. La VLAN è quindi completa solo dopo aver verificato l’intero percorso:

1. Controllare VLAN ID, Parent Interface, Zone, indirizzo IP e maschera sul firewall.
2. Configurare l’uplink verso il firewall come trunk con VLAN tagged.
3. Assegnare la porta access o l’SSID alla VLAN corretta.
4. Verificare DHCP, gateway e DNS con un client di test.
5. Provare un accesso interno consentito e uno intenzionalmente vietato.
6. Verificare l’accesso Internet e confermare nel Log Viewer la Firewall Rule ID prevista.

Per il traffico interno, NAT normalmente non è necessario. Se il client riceve un indirizzo ma non raggiunge il firewall come server DNS o tramite ping, controllare prima Device Access. La procedura completa con tagging dello switch e DHCP è disponibile in Configurare e verificare una VLAN Sophos Firewall.

Sophos non indica un numero massimo fisso di VLAN per singola Parent Port sulle appliance XGS. Tuttavia, con carico elevato, molte VLAN o design HA, più uplink o un LAG possono semplificare gestione e diagnostica.

Scegliere il tipo di interfaccia corretto

Alias

Un alias aggiunge un ulteriore indirizzo IP a un’interfaccia esistente. È particolarmente utile quando un provider fornisce più indirizzi IP pubblici nella stessa subnet.

Più interfacce WAN separate nella stessa subnet possono causare problemi ARP e gateway irraggiungibili. In questo caso, un alias sull’interfaccia WAN esistente o un LAG adeguatamente pianificato è normalmente la soluzione più pulita. Un alias segue lo stato della Parent Interface e non può essere disattivato separatamente.

Bridge

Un Bridge collega più interfacce a Layer 2. Può operare con un indirizzo IP per traffico routed oppure senza IP in modalità trasparente. Per nuove reti segmentate le VLAN sono generalmente più chiare; i Bridge sono più adatti a migrazioni o design volutamente trasparenti.

Limitazioni importanti:

• Un Bridge non supporta Dynamic DNS, DHCP client, PPPoE o IPsec VPN.
• Il traffico tra Bridge Member può comunque richiedere regole firewall, ad esempio LAN-to-LAN.
• HA non può essere attivato finché STP è attivo su un Bridge.
• Se è attivo un filtro VLAN ma nessuna VLAN è consentita, il firewall scarta tutti i frame tagged; il traffico untagged non è interessato.
• Il traffico su un Bridge senza IP può essere scartato senza log se incontra una regola Web Proxy o NAT.

Con un Bridge trasparente occorre quindi verificare se Web Proxy Filtering o Source Translation siano davvero necessari.

La Sophos Known Issues List descrive inoltre un problema specifico delle build SFOS 22.0 GA Build 411 e MR1 Build 490: se il traffico su un Bridge viene tradotto con SNAT o MASQ e origine e destinazione si trovano dietro lo stesso Bridge Member fisico, i pacchetti di risposta possono essere scartati dal filtro hairpin senza comparire in drppkt. Ciò vale anche quando viene usato attivamente un solo Bridge Member. Non è interessato il traffico tra Member fisici diversi o senza SNAT/MASQ. Build più recenti come 22.0 MR2 Build 546 non sono elencate come interessate nell’attuale Known Issues List.

Se falliscono solo alcune connessioni Bridge, controllare insieme topologia e NAT, provare senza Source Translation o adottare un design routed. Il caso separato di SFOS 22 relativo al traffico VLAN verso il firewall è descritto in Controllare le Bridge VLAN dopo SFOS 22.

Un Bridge tramite RED può estendere una rete Layer 2 tra sedi, ma dovrebbe restare un’eccezione motivata.

Broadcast, ARP e traffico unicast sconosciuto attraversano la connessione WAN. Un design routed con subnet dedicate per le sedi e regole firewall mirate è più stabile, scalabile e facile da analizzare.

LAG

Un Link Aggregation Group raggruppa da due a quattro interfacce fisiche in un uplink logico, sul quale possono essere utilizzate anche VLAN.

Le modalità comuni sono:

• Active-Backup: un link è attivo, l’altro subentra in caso di guasto.
• LACP (802.3ad): più link possono essere utilizzati in parallelo; firewall e switch devono avere configurazioni identiche.

Come Member sono ammesse interfacce fisiche non associate e configurate staticamente. Sono escluse interfacce PPPoE, Cellular WAN e WLAN. Con LACP le porte devono avere stesso tipo e stessa velocità.

La xmit-hash-policy distribuisce le connessioni tra i link. Una singola connessione TCP normalmente non diventa più veloce perché resta su un link. LAG offre soprattutto ridondanza e maggiore larghezza di banda complessiva per più connessioni parallele.

XFRM per IPsec route-based

Con una connessione IPsec route-based, SFOS crea automaticamente un’interfaccia XFRM nella zona VPN. Ciò vale sia per Any-to-any sia per connessioni con Traffic Selectors:

• Any-to-any: assegnare un indirizzo IP all’XFRM creato automaticamente in Network > Interfaces. Il traffico del tunnel è poi determinato da route statiche, SD-WAN o dinamiche.
• Traffic Selectors: SFOS crea l’XFRM e, all’avvio del tunnel, una route statica automatica. Non è possibile assegnare un indirizzo IP a questo XFRM né aggiungere una route propria.

In entrambi i casi il traffico VPN richiede regole firewall adatte. In Administration > Device access, IPsec nella zona WAN consente richieste di connessione IPsec in ingresso. Il ping sul tunnel viene consentito separatamente per VPN.

Un XFRM non si disattiva direttamente in Network > Interfaces, ma tramite la connessione in Site-to-site VPN > IPsec. In caso di frammentazione sono rilevanti MTU e MSS; la procedura è descritta in Controllare MTU e MSS per problemi VPN.

RED

Un’interfaccia RED collega una sede remota tramite un tunnel cifrato. La modalità operativa determina quanto traffico attraversa la sede centrale:

• Standard/Unified: il firewall centrale gestisce e filtra tutto il traffico della sede. Se il tunnel cade, può interrompersi anche l’accesso Internet.
• Standard/Split: solo le reti di destinazione definite attraversano il tunnel; il traffico Internet esce localmente e non viene filtrato centralmente.
• Transparent/Split: RED opera in modo trasparente in una rete esistente. È flessibile, ma più difficile da pianificare e analizzare.
• Manual/Split: la configurazione di rete è maggiormente manuale e può offrire autonomia locale.

Il servizio RED deve essere attivo in System services > RED. La connessione richiede normalmente TCP 3400, UDP 3410 e NTP su UDP 123. DNS, ora di sistema corretta e accesso Internet in uscita devono funzionare.

Il comportamento VLAN dipende da modello RED, modalità operativa, modalità delle porte LAN e configurazione WLAN. Sophos consiglia Standard/Unified per VLAN dietro RED; con SD-RED 60 il VLAN tagging è possibile solo in questa modalità. WLAN con Bridge to VLAN segue regole proprie. Scelta della modalità, provisioning, stato LED e diagnostica sono descritti in Configurare Sophos SD-RED.

Controllare stato e Device Access

Stato dell’interfaccia

In Network > Interfaces i valori di stato indicano se esaminare prima il link o la policy:

• Not configured: nessuna zona assegnata
• Connected: configurata e connessa
• Connecting: sta ottenendo un indirizzo, ad esempio tramite DHCP
• Disconnected: indirizzo rilasciato
• Disconnecting: rilascio dell’indirizzo in corso
• Unplugged: nessun collegamento fisico; con WiFi, eventualmente nessun Access Point o Wireless Network
• Not available: FleXi Port configurata senza modulo FleXi Port presente

Con Not configured o Unplugged, le regole firewall non sono ancora il primo punto da controllare. Verificare prima Zone Binding, cavo, SFP, velocità della porta, porta switch e DHCP o PPPoE.

Servizi locali del firewall

In Administration > Device access si definisce per ogni zona se sono raggiungibili servizi locali quali HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO o Wireless Protection.

Queste autorizzazioni riguardano il firewall stesso. Il traffico in transito tra reti è controllato dalle regole firewall. HTTPS e SSH dovrebbero essere consentiti solo da una rete di management o tramite una specifica Local service ACL exception rule. DNS è necessario se i client usano il firewall come server DNS.

⚠️ Se i client possono utilizzare il Web Proxy del firewall, SFOS tratta le richieste HTTP e HTTPS come richieste proxy interne. WebAdmin, Captive Portal, VPN Portal o User Portal possono quindi risultare raggiungibili anche se il servizio è disattivato per la zona client. In questo design, accesso proxy e portali locali devono essere verificati separatamente.

Gestire in sicurezza dipendenze e modifiche

Object Usage prima di modificare o eliminare

Zone Binding, DNS, gateway, SD-WAN, Interface Host, VLAN, Dynamic DNS, DHCP, regole firewall, NAT e VPN possono dipendere dalla stessa interfaccia. Object usage mostra questi riferimenti.

Il contatore visualizzato viene aggiornato automaticamente solo una volta al giorno. Prima di una modifica o eliminazione, selezionare quindi Refresh e documentare le dipendenze importanti.

La disattivazione conserva la configurazione dell’interfaccia. I tunnel IPsec per i quali il firewall è Initiator vengono disconnessi immediatamente. I tunnel Responder e le connessioni Remote Access terminano al più tardi per inattività o Dead Peer Detection.

Eliminando un’interfaccia virtuale, SFOS può rimuovere regole firewall, configurazioni DHCP, voci ARP, route, Interface Host e altri riferimenti dipendenti. Le interfacce alias seguono la Parent Interface; le interfacce XFRM sono gestite tramite la connessione IPsec.

HA e modifiche remote

Le interfacce dedicate al link HA appartengono a una zona DMZ. Altre interfacce monitorate o usate per l’amministrazione possono trovarsi in zone diverse.

Active-Active HA richiede interfacce configurate staticamente. Cellular WAN viene disattivato con HA. Active-Passive può usare interfacce WAN con indirizzo dinamico, ma connessioni come PPPoE non vengono necessariamente trasferite con la sessione durante un failover.

Prima di una modifica in produzione:

1. Documentare configurazione e dipendenze.
2. Preparare finestra di manutenzione, momento di rollback, backup e percorso di ripristino concreto.
3. Verificare un accesso amministrativo indipendente, ad esempio Sophos Central, una seconda WAN, una rete di management separata o una persona sul posto.
4. Preparare un client o traffico di test univoco; aggiungere e verificare il nuovo percorso o la nuova zona.
5. Controllare link, IP, gateway, DHCP, DNS, regole firewall, NAT e Device Access.
6. Eliminare i vecchi oggetti solo quando il nuovo percorso è stabile.

Per un trunk VLAN, il rollback deve includere VLAN ID precedente, Native VLAN e profilo della porta switch. Per modifiche WAN sono importanti i valori del provider e le route SD-WAN; per XFRM anche tunnel, routing ed entrambe le direzioni firewall.

Individuare sistematicamente gli errori

La causa si restringe più rapidamente partendo dal sintomo:

• L’interfaccia è unbound o disabled: controllare Zone Binding e stato. Una porta fisica non viene eliminata; la sua configurazione può essere rimossa impostando Zone su None.
• La VLAN non funziona: confrontare VLAN ID, Parent Interface, trunk, Tagged/Untagged e Native VLAN.
• Il firewall non è raggiungibile via ping, HTTPS o DNS: controllare Device Access e Local Service ACL, non innanzitutto una normale regola firewall.
• Il traffico interno è bloccato: controllare Source zone, Destination zone, oggetti di rete, routing, Services e ordine delle regole.
• Il gateway WAN resta inattivo: controllare link, IP, gateway, credenziali PPPoE e WAN Link Manager.
• Più porte WAN sono nella stessa subnet: evitare problemi ARP e valutare alias o LAG.
• SFP o Port Speed non coincidono: confrontare transceiver, cavo, breakout e velocità su entrambi i lati.
• VPN o PPPoE è instabile: controllare MTU e MSS.

Per la diagnostica è utile questo ordine:

1. Network > Interfaces: link, IP, zona e gateway
2. Network > Zones: tipo di zona e Device Access
3. Hosts and services: oggetti di rete e servizi
4. Firewall rules: direzione, ordine, servizi e logging
5. NAT rules: Original e Translation
6. Log viewer: Rule ID o motivo del drop
7. Diagnostics > Tools > Packet capture: ingresso e inoltro del pacchetto

Se la regola sembra corretta ma non effettua il matching, consultare La regola firewall non viene applicata. Il flusso dei pacchetti è descritto in Usare Packet Capture in WebAdmin.

Checklist operativa

• Zone pianificate e documentate per livello di attendibilità
• Zona, interfaccia e oggetto di rete distinti correttamente
• VLAN ID, Parent, trunk e gateway verificati
• Device Access limitato soprattutto per HTTPS, SSH, DNS, ping e portali
• Regole firewall create con zone, reti, servizi e logging concreti
• Valutato un alias per ulteriori indirizzi IP del provider nella stessa subnet
• Verificati DHCP, DNS, NTP, routing ed eventualmente NAT
• Object Usage aggiornato e controllato prima delle modifiche
• Preparati accesso amministrativo indipendente e percorso di ripristino
• Controllati Link Status, Log Viewer e Packet Capture dopo la modifica

FAQ