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 numero massimo di zone dipende dalla versione: SFOS 22.0 consente fino a 100 zone, SFOS 23.0 fino a 248 zone.

Configurare un’interfaccia fisica

Il numero di porte fisiche disponibili dipende dal modello di appliance. Durante la pianificazione, verificare quindi innanzitutto quali connessioni offre il dispositivo specifico; le interfacce virtuali non sostituiscono le porte fisiche aggiuntive necessarie.

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

1. Assegnare un Name descrittivo di massimo 58 caratteri, 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.

La zona WAN è destinata alle connessioni con un default gateway. Le interfacce interne utilizzano normalmente indirizzi statici; per IPv4, le interfacce fisiche offrono i metodi Static, DHCP e PPPoE. Le procedure sui campi riportate di seguito distinguono questi metodi. La presenza dei campi gateway in tali procedure non è, da sola, un motivo per assegnare un’interfaccia interna alla zona WAN: zona, indirizzamento e routing devono essere coerenti con il design della rete e con il modulo effettivamente visualizzato.

Se sull’interfaccia fisica è già presente una VLAN, SFOS non consente di cambiare l’assegnazione IPv4 da Static a DHCP o PPPoE. Per IPv6 è bloccato anche il passaggio da Static a DHCP o Delegated. Prima della modifica, registrare le dipendenze VLAN in Object usage. Spostare quindi le interfacce VLAN interessate su un’altra Parent Interface oppure rimuoverle durante una finestra di manutenzione. Solo a quel punto cambiare il metodo di assegnazione, quindi ripristinare la configurazione VLAN e verificare la connettività.

IPv4 sulla porta fisica: Static o DHCP

⚠️ Prima di modificare l’indirizzo o il metodo di assegnazione, eseguire Object usage > Refresh, documentare indirizzo, maschera, zona e gateway precedenti e predisporre backup, finestra di manutenzione e accesso amministrativo indipendente. La modifica può interrompere i percorsi attuali di gestione e dei dati. Gestire prima le dipendenze VLAN esistenti come descritto sopra. Il percorso di recovery tramite console illustrato più avanti non sostituisce la normale configurazione tramite WebAdmin.

Static: inserire valori IPv4 fissi

1. In Network > Interfaces, aprire la porta fisica corretta tramite Menu > Edit interface e verificare Hardware. Questo collegamento fisico non può essere modificato qui.
2. Selezionare IPv4 configuration e scegliere il metodo di assegnazione Static.
3. Inserire l’indirizzo IPv4 previsto per questa interfaccia. Se necessario, adattare la maschera di sottorete alla rete pianificata.
4. Compilare Gateway name e Gateway IP address in base al modulo visualizzato e ai valori approvati della rete o del provider. Il nome serve a identificare univocamente il gateway; l’IP del gateway è l’indirizzo del dispositivo remoto previsto, non un ulteriore indirizzo del firewall.
5. Confrontare nuovamente i valori e l’ID della porta, quindi salvare con Save. Verificare poi IP e maschera salvati, link, eventuale stato del gateway, routing, DNS, Device Access e percorsi effettivi dei dati e di gestione.

Una connessione WAN statica puramente illustrativa utilizza, ad esempio, l’indirizzo IPv4 192.0.2.2, la maschera 255.255.255.0, Gateway name ISP-Static e Gateway IP address 192.0.2.1. Questi indirizzi appartengono a una rete riservata alla documentazione e non sono valori del provider utilizzabili in produzione. Sostituire indirizzo, maschera e gateway con i dati corrispondenti forniti dal proprio provider; scegliere un nome che permetta di riconoscere la linea durante l’esercizio.

DHCP: distinguere l’assegnazione dinamica dai campi documentati

1. Aprire la porta fisica in Network > Interfaces > Menu > Edit interface, verificare Hardware e zona e selezionare IPv4 configuration.
2. Scegliere DHCP. Questo metodo ottiene l’indirizzo dell’interfaccia da un server DHCP; non configura un server DHCP per i client.
3. La procedura documentata per i campi DHCP indica anche l’inserimento di un indirizzo IPv4, una modifica facoltativa della maschera di sottorete e i campi Gateway name e Gateway IP address. La descrizione, tuttavia, non spiega come questi dati interagiscano con l’indirizzo ottenuto dal server DHCP. Non dedurne un indirizzo sostitutivo manuale, un fallback o una sovrascrittura del lease DHCP.
4. Prima di salvare, verificare i campi effettivamente visibili o modificabili nel build installato e confrontarli con la configurazione DHCP o del provider approvata. Non copiare valori statici di esempio nei campi DHCP. Se il ruolo di un campo obbligatorio non è chiaro, non salvare la modifica e chiarire il punto con il provider o il supporto.
5. Una volta chiarita la configurazione, salvare con Save e verificare che venga ottenuto un indirizzo adatto. Connecting indica che l’acquisizione del lease è ancora in corso; se lo stato persiste, controllare prima link, raggiungibilità del server DHCP e requisiti del provider. Verificare quindi IP, maschera, gateway, DNS, routing e percorsi reali di gestione e dei dati.

Se dopo una di queste modifiche il percorso previsto non è disponibile, ripristinare tramite l’accesso indipendente il metodo originale documentato e i relativi valori, quindi ripetere i test. PPPoE utilizza invece le credenziali del provider; la procedura completa è descritta in Configurare e verificare una WAN PPPoE.

IPv6 sulla porta fisica: metodo e modalità di ricezione

In IPv6 configuration, le interfacce WAN offrono Static o DHCP; le interfacce interne offrono Static, DHCP o Delegated. Delegated utilizza per le interfacce interne un prefisso delegato dal provider. La procedura completa con DHCP sulla WAN, Upstream Interface e distribuzione interna è descritta in IPv6 Prefix Delegation su Sophos Firewall. Si tratta di un’attività distinta, che non sostituisce la configurazione statica o la scelta della modalità di ricezione illustrate di seguito.

Static: indirizzo IPv6, prefisso e campi gateway

1. Aprire la porta fisica in Network > Interfaces > Menu > Edit interface e selezionare IPv6 configuration.
2. Scegliere Static. Gli indirizzi IPv6 statici sono previsti sia per le interfacce WAN sia per quelle interne.
3. Inserire l’indirizzo IPv6 pianificato e, se necessario, adattare il prefisso alla rete assegnata.
4. Compilare i campi Gateway name e Gateway IP address indicati nella procedura Static in base al modulo effettivamente visualizzato e al design della rete. Le istruzioni generali per Static riportano questi campi anche nella sezione relativa alle interfacce WAN e interne; non dedurne né l’obbligo di un default gateway interno né una regola generale che riservi questi campi alle sole interfacce WAN. Chiarire eventuali campi obbligatori poco chiari o inattesi prima di una modifica in produzione.
5. Salvare con Save e verificare indirizzo IPv6 e prefisso salvati, eventuale gateway, routing IPv6, DNS e connessioni consentite. Mantenere l’accesso amministrativo indipendente; se il percorso è errato, ripristinare i valori IPv6 documentati in precedenza.

Le precauzioni previste prima della procedura IPv4 valgono anche per IPv6: documentare metodo e valori precedenti, verificare le dipendenze VLAN e non utilizzare il percorso di gestione attuale come unica via di ripristino.

DHCPv6: Auto, Manual e Stateless

Dopo aver selezionato DHCP in IPv6 configuration, Mode determina come il firewall stesso riceve l’indirizzo della propria interfaccia. Non è la stessa impostazione di un server Router Advertisement per i client interni:

• Auto: l’indirizzo dell’interfaccia viene assegnato automaticamente in base al metodo di configurazione utilizzato, che può essere DHCP only o Stateless. Non dedurne una regola di selezione fissa non documentata qui.
• Manual > DHCP only: il firewall assegna all’interfaccia l’indirizzo e gli altri parametri forniti dal server DHCPv6.
• Manual > Stateless: il firewall genera l’indirizzo dell’interfaccia tramite Stateless Address Auto-Configuration (SLAAC), in base ai flag Managed e Other (M/O) annunciati nei Router Advertisement. Con Accept other configuration from DHCP è possibile ottenere altri parametri dal server DHCPv6. Questo non trasforma la modalità di ricezione in DHCP only.

La funzionalità opzionale DHCP rapid commit utilizza uno scambio di due messaggi (solicit e reply) anziché quattro (solicit, advertise, request e reply). Attivala solo se Rapid Commit è attivato anche sul server DHCPv6 ed è compatibile con la configurazione approvata. Non usarla come soluzione generale ai problemi o come promessa di maggiore velocità.

La procedura DHCPv6 riporta Gateway name e Gateway IP address. Tuttavia, con Mode impostato su Manual e Stateless, non è possibile impostare Gateway IP address. Questa limitazione riguarda la modalità Stateless e non deve essere estesa a Manual > DHCP only. Prima di salvare, confrontare modalità di ricezione e campi gateway con il design RA/DHCPv6 previsto e con il modulo visualizzato; non forzare un IP del gateway se la modalità scelta non lo consente.

Dopo Save, verificare l’indirizzo IPv6 effettivamente assegnato, il prefisso e gli altri parametri, oltre a routing, DNS e un percorso dati IPv6 consentito. Se l’indirizzo è errato o assente, confrontare prima con il dispositivo remoto la modalità scelta, i flag RA ricevuti e la raggiungibilità del server DHCPv6; non cambiare modalità senza aver eseguito le verifiche. Se il percorso di gestione è interrotto, ripristinare la configurazione precedente tramite l’accesso indipendente.

Allineare le impostazioni di porta e link

In Advanced settings, allineare Link mode, Auto-negotiation for media type, Forward Error Correction (FEC) in base al modello, MTU e MSS al dispositivo remoto. Per le porte da 25, 50 e 100 Gbit/s, salvare prima Link mode, riaprire l’interfaccia e quindi caricare la configurazione consigliata. Su XGS 2100, 2300, 3100 e 3300, tutte le porte SFP+ dei moduli FleXi Port devono essere configurate con la stessa velocità. La procedura completa con Show recommended settings, Load recommended configuration, entrambi i passaggi di salvataggio e la diversa visualizzazione per le altre porte, incluse quelle da 40 Gbit/s, è descritta in Configurare interfacce breakout e impostazioni delle porte.

SFOS non supporta la marcatura DSCP per il traffico DHCP e ARP generato dal sistema, anche quando il firewall opera come client, relay o server DHCP. Una policy non deve quindi fare affidamento sulla prioritizzazione basata su DSCP per questi pacchetti. Questa limitazione riguarda DSCP; non significa che sia esclusa ogni altra possibile forma di prioritizzazione.

In Advanced settings > Interface settings, Use default MAC address utilizza l’indirizzo MAC predefinito dell’interfaccia. Nel caso di un’interfaccia con porte membro, questo MAC predefinito è fornito dalla prima porta aggiunta come membro. Override default MAC address consente di utilizzare un indirizzo MAC diverso; un ripristino alle impostazioni di fabbrica ripristina il MAC predefinito. Questo non è un invito a eseguire il ripristino né un requisito per una porta fisica PPPoE indipendente. Prima di un override motivato, verificare le dipendenze e il percorso di ripristino descritti di seguito.

Le velocità delle porte sul firewall e sul dispositivo remoto devono essere compatibili. Ad esempio, una porta da 25 Gbit/s non può essere collegata a una porta da 40 Gbit/s tramite cavi breakout senza un’adeguata conversione. Le porte del firewall da 40 e 100 Gbit/s che supportano il breakout possono essere suddivise in due o quattro porte mediante cavi breakout appropriati. Questo non garantisce la compatibilità di ogni appliance o combinazione di cavi; prima della pianificazione, verificare il supporto delle porte specifiche, dei transceiver e del dispositivo remoto.

Impostare un indirizzo IPv4 nel menu di recovery interattivo

In 1. Network Configuration > Interface Configuration, la CLI mostra indirizzo IPv4 e netmask, indirizzo IPv6 e prefisso, zona, gateway e alias configurati delle porte fisiche. Le interfacce VLAN e WLAN non appaiono in questa vista.

y avvia la modifica IPv4. SFOS mostra in sequenza indirizzo, netmask e zona correnti di ogni porta; Enter senza nuovo valore conserva il campo. Questo percorso vale solo per Gateway mode e valori IPv4 statici. Non configura VLAN, DHCP, PPPoE, WLAN o WWAN, e il dialogo IPv6 è diverso.

Prima della modifica, salvare tutti i valori, ID porta, zona, gateway, alias e un accesso di management indipendente. Dopo il salvataggio verificare link, nuova IP e netmask, gateway, Device Access, routing, DNS e percorso di management reale. Se l’accesso si interrompe o il percorso dati è errato, ripristinare i valori originali via console o accesso indipendente.

Correggere i valori di link e MAC nella Device Console

WebAdmin resta il percorso di configurazione normale. La Device Console è destinata a una correzione o recovery documentata, perché un valore di link errato può interrompere immediatamente l’unico accesso di gestione. Prima si registrano Port ID, peer, Link mode, autonegotiation, FEC, accesso amministrativo indipendente e rollback.

La sintassi ufficiale di SFOS 22 accetta 1000fd, 100fd, 100hd, 10fd, 10hd o auto per i valori copper elencati:

Gli esempi seguenti sono alternative, non una sequenza di comandi. Sostituire Port2 con la porta fisica verificata e scegliere esattamente una variante coerente con la configurazione approvata della porta e del peer; non eseguirle entrambe in successione. Registrare prima su entrambi i lati i valori originali di Link mode, autonegotiation e, se applicabile, FEC, insieme allo stato del link, alla velocità e al duplex effettivi. Predisporre l’accesso indipendente e chiarire il ripristino esatto tramite WebAdmin oppure una procedura confermata dal supporto per il build installato. Se i valori originali o il percorso di recovery non sono noti, fermarsi prima della modifica CLI e contattare il supporto.

Alternativa 1: velocità e duplex automatici, con autonegotiation aggiuntiva attivata:

set network interface-link Port2 linkmode auto autoneg on

Alternativa 2: 1000 Mbps full-duplex, con autonegotiation aggiuntiva disattivata:

set network interface-link Port2 linkmode 1000fd autoneg off

autoneg controlla parametri di link diversi da velocità e duplex. Le modalità FEC dipendono dal modello e Sophos non ne fornisce un elenco universale in questo comando CLI. Per porte da 25, 50 o 100 Gbps si usa la configurazione consigliata per appliance e transceiver specifici, senza copiare valori da un altro modello.

Subito dopo la modifica scelta, confrontare i valori salvati di Link mode, autonegotiation e, se applicabile, FEC in WebAdmin e sul peer con i valori di destinazione approvati. Verificare su entrambi i lati lo stato del link, la velocità e il duplex effettivi, oltre al normale accesso di gestione e ai percorsi dati reali necessari. Se un percorso è assente, instabile o peggiorato, ripristinare tramite l’accesso indipendente gli esatti valori originali registrati della porta e tutte le impostazioni del peer adattate per la modifica, incluso FEC se modificato. Utilizzare il percorso di ripristino chiarito in precedenza e ripetere le stesse verifiche; la configurazione di ciascun lato deve nuovamente corrispondere al proprio stato iniziale. Nessuno degli esempi, nemmeno auto con autoneg on, è un rollback universale.

Un indirizzo MAC viene sovrascritto solo per una dipendenza di design comprovata. Prima di qualsiasi modifica, registrare come stato iniziale il MAC effettivo e la modalità configurata (default o override, compreso un eventuale indirizzo personalizzato preesistente). Verificare Port Security, binding DHCP, allowlist del provider, HA, LAG e associazioni MAC/ARP del peer. Devono essere disponibili un accesso amministrativo indipendente e una finestra di manutenzione.

Le descrizioni CLI di SFOS 22.0 e 23.0 indicano che default mantiene il MAC esistente. Questo non dimostra l’interpretazione secondo cui ripristina il MAC predefinito dopo un override. Non usare default come comando inverso o rollback universale: la descrizione non ne conferma questa funzione. Prima dell’override, verificare come ripristinare esattamente sia l’indirizzo sia la modalità sul build installato. Se lo stato iniziale o la procedura di ripristino non sono verificabili, non effettuare la modifica e chiarire con Sophos Support.

Il seguente esempio modifica il MAC e può interrompere le connessioni di amministrazione e dati. Sostituire Port2 con la porta verificata e l’indirizzo di esempio, amministrato localmente, con l’indirizzo di destinazione approvato e univoco nella propria rete. Non è un valore di ripristino:

set network macaddr Port2 override 02:00:5e:10:00:02

Per il ripristino verificato:

• Se prima era configurato override con un MAC personalizzato, reimpostare l’esatto indirizzo registrato tramite il ramo override documentato, non l’indirizzo di esempio. La procedura deve essere confermata per il build installato.
• Se prima era configurato default, utilizzare Use default MAC address in Network > Interfaces > Edit interface > Advanced settings > Interface settings solo se quel controllo e il ripristino dello stato iniziale registrato sono confermati sul build installato. Altrimenti, ottenere una procedura specifica del build confermata da Sophos Support; non provare CLI default o un ripristino di fabbrica come sostituti.

Dopo la modifica e dopo il ripristino, confrontare modalità configurata e indirizzo effettivo con i valori previsti; per il rollback, entrambi devono corrispondere allo stato iniziale registrato. Verificare anche l’accesso amministrativo normale, l’apprendimento MAC/ARP del peer e il flusso dati reale interessato. In caso di differenze, interrompere la procedura tramite l’accesso indipendente e chiarire con il supporto, senza sperimentare altri valori MAC.

Sophos documenta MTU 1500 e MSS 1460 come valori predefiniti; modificarli solo con la procedura controllata in Verificare MTU e MSS per problemi VPN.

Per IPv6, DAD attempts determina quanti messaggi Neighbor Solicitation consecutivi il firewall invia durante la Duplicate Address Detection su un indirizzo provvisorio (tentative). In Allowed RA servers si inseriscono gli indirizzi MAC o IPv6 dei server Router Advertisement dai quali questa interfaccia può accettare una configurazione stateless. IPv6 Prefix Delegation su Sophos Firewall spiega il prefisso del provider e la distribuzione interna; Configurare IPv6 Router Advertisement descrive i flag dei client e i prefissi annunciati.

Per attività specifiche sono disponibili guide dedicate:

• Configurare e verificare un’interfaccia VLAN
• Configurare e testare una rete Wi-Fi gestita da SFOS
• Collegare APX esistenti con Wireless Mesh
• Configurare un’interfaccia LAG
• Configurare e testare un tunnel GRE
• Trasportare IPv6 su IPv4 o IPv4 su IPv6 con un tunnel IP
• Inoltrare multicast tra interfacce con una route multicast statica
• Pianificare e verificare il routing multicast dinamico con PIM-SM
• Configurare e verificare una WAN PPPoE
• Configurare il failover WAN con una seconda connessione Internet
• 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

La zona WiFi si applica alle reti wireless che utilizzano una zona dedicata. Con Bridge to AP LAN e Bridge to VLAN, invece, non viene creata un’interfaccia WiFi dedicata; il percorso del traffico segue l’assegnazione bridge selezionata.

Una Wireless Network definisce impostazioni comuni per i client WLAN: SSID, modalità di sicurezza e trattamento del traffico dei client. Con il Traffic Mode Separate zone, il firewall crea un tunnel VXLAN associato. La scelta del Traffic Mode determina quindi anche come la WLAN viene collegata al firewall; non è soltanto un’etichetta per la rete.

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 costituisce un dominio broadcast isolato: i broadcast rimangono all’interno di quella VLAN. L’assegnazione di più VLAN alla stessa zona di sicurezza non elimina questa separazione Layer 2; la zona determina il contesto per le regole firewall e Device Access.

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 XGS Appliances. 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

Le interfacce virtuali e gli alias vengono creati in Network > Interfaces tramite Add interface. Selezionare il tipo desiderato e aprirne la configurazione. Le sezioni seguenti aiutano a scegliere il tipo; un alias integra un’interfaccia esistente, mentre, ad esempio, VLAN, Bridge e LAG rappresentano collegamenti logici differenti.

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.

Configurare e testare un IP alias su Sophos Firewall spiega come associare l’indirizzo aggiuntivo, usarlo come oggetto host nelle regole e nel NAT e verificare ARP e traffico di sistema.

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.

La procedura completa con Member, STP, filtri VLAN ed EtherType, regole e verifica è descritta in Configurare un’interfaccia Bridge su Sophos Firewall.

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.

Sophos documenta NC-177630 per SFOS 22.0.0 GA-Respin Build 411. Il problema può verificarsi quando il traffico instradato tramite un Bridge viene tradotto con SNAT o MASQ e l’ingresso e l’uscita utilizzano lo stesso Bridge Member fisico. I pacchetti di risposta vengono quindi scartati dal filtro hairpin senza comparire in drppkt. Ciò vale anche quando è attivo un solo Bridge Member. Il traffico tramite Member fisici diversi o senza SNAT/MASQ non è interessato.

Sophos indica SFOS 22.0.1 MR1 Build 490 come versione corretta. Su GA-Respin Build 411, SNAT o MASQ deve essere rimosso per il flusso interessato solo se la traduzione non è necessaria ed esiste un percorso di ritorno verso l’indirizzo IP originale del client. In alternativa, il traffico viene instradato tramite un’interfaccia fisica dedicata invece che tramite il Bridge. Se manca uno dei fattori scatenanti descritti o il problema si verifica su MR1 Build 490 o una versione successiva, occorre cercare un’altra causa. 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.

LAG e failover WAN svolgono funzioni diverse: un LAG aggrega link fisici in un’unica connessione logica. Le connessioni Internet indipendenti vengono invece utilizzate tramite i rispettivi gateway WAN in Network > WAN link manager. Più gateway attivi consentono di distribuire il carico tra le connessioni disponibili; un gateway di backup può subentrare quando viene rilevato un guasto. Questo non garantisce né la continuità senza interruzioni delle sessioni esistenti né una maggiore larghezza di banda per una singola connessione. Configurare il failover WAN con una seconda connessione Internet spiega la procedura e come verificarne il funzionamento.

Cellular WAN e WWAN1

Quando si attiva Cellular WAN, SFOS crea l’interfaccia WWAN1. Questa fa parte della connessione cellulare e non è equivalente a una VLAN o a un alias creati liberamente. Restano da rispettare le limitazioni per HA descritte di seguito e l’esclusione come membro di un LAG.

In SFOS 23.0, Network > Interfaces offre nel Menu dell’interfaccia WWAN le azioni Connect e Disconnect per connettere o disconnettere il modem Cellular WAN. Reset riavvia il modem ed è disponibile solo per i modelli 5G di Quectel e Sierra Wireless, non per altri modelli o dongle USB. Non si deve presumere che queste azioni, descritte per SFOS 23.0, siano disponibili tramite lo stesso percorso di clic in SFOS 22.0.

Prima di usare Disconnect o Reset, assicurarsi di disporre di un accesso amministrativo indipendente e di una finestra di manutenzione se la connessione cellulare trasporta traffico di produzione o fornisce l’accesso di gestione. Un riavvio hardware che comporta l’arresto del firewall interrompe tutto il traffico del firewall; anche per questa operazione, predisporre un accesso amministrativo indipendente e una finestra di manutenzione. Per riavviare l’hardware di un modello non supportato, arrestare prima il firewall, scollegare e ricollegare il modem, quindi avviare nuovamente il firewall; non apportare modifiche fisiche all’hardware WWAN mentre il firewall è in funzione. Successivamente, verificare lo stato dell’interfaccia e i percorsi effettivi dei dati e di gestione necessari. Il riavvio del modem non è una soluzione garantita per un errore di connessione la cui causa non è stata chiarita.

TAP / Discover Mode

Una porta fisica in Discover Mode riceve una copia del traffico replicata dallo switch. Non è inline e non può bloccare il traffico osservato né controllarlo con policy di sicurezza. È utile per un inventario o una proof of concept, ma non costituisce un percorso di protezione in produzione.

Nella panoramica delle interfacce, questa porta è elencata come Discover, physical (TAP). In questo modo è possibile distinguerla da una normale interfaccia nel percorso del traffico di produzione.

Configurare Discover Mode con TAP e SPAN spiega la configurazione completa con porta SPAN, comandi Device Console, Packet Capture, Security Audit Report e limiti HA.

XFRM per IPsec route-based

Per IPsec route-based si distingue tra connessioni Any-to-any e connessioni con Traffic Selectors specifici. Quando entrambe le subnet sono impostate su Any, SFOS crea automaticamente un’interfaccia XFRM nella zona VPN:

• 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 automaticamente una route statica all’avvio del tunnel. Se compare un’interfaccia XFRM, non assegnarle un indirizzo IP né route manuali.

La documentazione ufficiale di SFOS 22 e SFOS 23 si contraddice sulla creazione di XFRM per subnet specifiche: «Configure an XFRM interface» indica che non viene creata alcuna XFRM, mentre «Route-based VPN» descrive la creazione di una XFRM per configurazione. Non dare quindi per scontato che l’interfaccia sia sempre presente o sempre assente. Espandere la Listening interface in Network > Interfaces e verificarne la visibilità effettiva nel build installato. La sezione Traffic Selectors di Configurare una VPN IPsec site-to-site spiega i controlli esistenti di visibilità e traffico.

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 verso un indirizzo locale del firewall dalla zona VPN viene consentito separatamente tramite Ping/Ping6 in Administration > Device access. Il ping tra host attraverso il tunnel VPN è invece traffico in transito e richiede route e regole firewall adatte; l’autorizzazione di Device Access non consente questo traffico.

Un XFRM non si disattiva direttamente in Network > Interfaces, ma tramite la connessione in Site-to-site VPN > IPsec. Se SSL/TLS Decryption viene applicata al traffico IPsec, Sophos richiede che la MTU XFRM sia inferiore di almeno 113 byte rispetto alla MTU della Listening Interface. Con una MTU di 1400 sulla Listening Interface, la MTU XFRM non può quindi superare 1287. Questo limite specifico del prodotto riguarda FastPath Offload e non è un valore generale per ogni tunnel. La procedura completa è 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. Scegliere la modalità operativa corretta di Sophos RED spiega DHCP, gateway, percorso internet e comportamento in caso di guasto delle quattro 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. Non tutti i riferimenti possono essere modificati nel pop-up. I gateway WAN e le configurazioni CLI devono essere modificati nella rispettiva pagina di configurazione o nella CLI.

Per i riferimenti modificabili nelle regole o nelle policy, si passa dal contatore alla configurazione specifica:

1. Nella colonna Usage, fare clic sul numero di utilizzi dell’oggetto interessato. Il pop-up mostra quali configurazioni utilizzano l’oggetto.
2. Espandere la categoria pertinente tramite l’icona più per visualizzare le relative regole o policy.
3. Fare clic sulla regola o policy interessata per modificarla. Rimuovere lì il riferimento all’oggetto oppure sostituirlo con l’oggetto sostitutivo previsto.

Dopo la verifica delle dipendenze, l’attivazione o la disattivazione si esegue in Network > Interfaces, nel Menu dell’interfaccia interessata, tramite on o off rispettivamente. Prima di usare off, assicurarsi di disporre di un accesso amministrativo indipendente e di un percorso di ripristino; l’azione può interrompere il percorso dati attualmente utilizzato. Alias e XFRM non possono essere disattivati indipendentemente da qui.

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.

Un’interfaccia virtuale viene eliminata in Network > Interfaces tramite Menu > Delete interface. Eseguire questa azione solo dopo aver selezionato Refresh in Object usage, documentato la verifica delle dipendenze e preparato un backup e un percorso di ripristino; l’azione non rimuove soltanto la voce visibile dell’interfaccia.

Quando si elimina un’interfaccia virtuale, SFOS elimina tutte le regole firewall che la utilizzano, anche se la regola contiene altre interfacce. Rimuove inoltre i Zone Binding dipendenti, i server o relay DHCP, le voci ARP statiche e proxy ARP, i Protected Server e le regole firewall basate su di essi, gli Interface Host e i relativi riferimenti nei gruppi, nonché le route unicast e multicast. Le interfacce Alias seguono la propria interfaccia padre; le interfacce XFRM sono gestite tramite la connessione IPsec.

Anche una semplice modifica può influire su Zone Binding, DNS, gateway, route e profili SD-WAN, Interface Host, VLAN e Dynamic DNS. Dopo una modifica o un’eliminazione, le connessioni possono temporaneamente non rispondere o interrompersi. Dopo ogni cambiamento, verificare quindi i percorsi effettivi dei dati e di gestione, non solo la voce dell’interfaccia salvata.

Rimuovere deliberatamente la configurazione di una porta fisica

Una porta fisica rimane presente sull’appliance; è possibile rimuovere solo la sua configurazione. off e Network zone None non sono equivalenti: off mantiene la configurazione, mentre None rimuove la configurazione IP. Questa azione serve a liberare deliberatamente una porta non più necessaria, non come primo intervento di riparazione in caso di Unplugged o di un gateway non raggiungibile.

⚠️ Prima della rimozione, eseguire Object usage > Refresh, documentare e migrare le dipendenze e verificare il backup e l’accesso amministrativo indipendente. Annotare indirizzi IP, maschere o prefissi, zona, gateway e alias per il ripristino. Non reimpostare la porta tramite l’unico percorso di accesso di gestione.

1. In Network > Interfaces, aprire la porta fisica interessata.
2. Impostare Network zone su None. La configurazione IP scompare già nel modulo; verificare nuovamente l’ID della porta prima del passaggio successivo.
3. Salvare con Save.
4. Nella panoramica devono comparire Unbound, lo stato Disabled e l’indirizzo IP N/A. Verificare quindi tramite l’accesso indipendente che gli altri percorsi necessari dei dati e di gestione continuino a funzionare.

Se è stata reimpostata la porta sbagliata, ripristinarne la zona e la configurazione IP precedenti tramite l’accesso indipendente o la console. Ripristinare le configurazioni dipendenti rimosse utilizzando l’inventario precedente o il backup; la riassegnazione di una zona non sostituisce questa operazione. Infine, verificare nuovamente il collegamento, il gateway, DHCP, DNS, il routing, le regole e Device Access.

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 Fusion (in precedenza 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: Verificare innanzitutto se la porta è stata deliberatamente lasciata senza una zona o se l’interfaccia è stata disattivata. Se la porta era precedentemente in produzione, confrontare la zona e la configurazione IP previste con la configurazione documentata e ripristinarle tramite un accesso indipendente. None non è una riparazione, ma rimuove la configurazione IP; la procedura deliberata è spiegata sopra in Rimuovere deliberatamente la configurazione di una porta fisica.
• 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: Verificare sistematicamente SFP e SFP+ e 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