Configurare e testare un IP alias su Sophos Firewall

Un IP alias associa un indirizzo IPv4 o IPv6 aggiuntivo a un’interfaccia fisica esistente di Sophos Firewall. È utile quando un provider fornisce più indirizzi pubblici tramite la stessa connessione WAN oppure quando un’interfaccia interna deve servire una seconda subnet durante una migrazione.

La distinzione importante è che un alias non è una seconda connessione Internet, una zona separata o un percorso gateway indipendente. L’indirizzo utilizza la stessa interfaccia fisica principale. Routing, regole firewall, NAT e Device Access devono quindi continuare a corrispondere al design esistente dell’interfaccia.

⚠️ Prima di aggiungere un IP alias pubblico, documentare un backup aggiornato, una connessione amministrativa indipendente, l’assegnazione del provider, lo stato ARP originale e le regole firewall e NAT pianificate. Un indirizzo aggiuntivo non pubblica da solo un server, ma può rendere raggiungibili i servizi locali del firewall in base alle regole Device Access della zona principale.

L’esempio utilizza IPv4 su un’interfaccia WAN. SFOS supporta anche alias IPv6 quando la versione IP corrisponde all’interfaccia principale. Neighbor Discovery IPv6 e NAT66 non fanno tuttavia parte di questo esempio specifico.

IP alias in otto passaggi

1. Confermare che il provider o la rete interna fornisca realmente l’indirizzo aggiuntivo tramite la stessa interfaccia fisica.
2. Documentare l’interfaccia principale, la versione IP, l’indirizzo, la maschera di subnet e lo scopo.
3. Controllare Device Access, le regole esistenti e un percorso di gestione indipendente.
4. Associare l’indirizzo all’interfaccia principale in Network > Interfaces > Add interface > Add alias.
5. Se necessario per regole e NAT, creare un IP Host con un nome chiaro e con esattamente questo indirizzo.
6. Configurare DNAT o SNAT solo per il flusso previsto; gestire separatamente il traffico di sistema.
7. Verificare percorso del provider, ARP, Firewall Rule ID, NAT Rule ID e entrambe le direzioni con una nuova connessione.
8. Testare appliance sostitutiva, failover HA e rollback in una finestra di manutenzione con lo stesso flusso.

Quando è adatto un IP alias

Un IP alias è adatto quando più indirizzi devono utilizzare lo stesso percorso fisico di livello 2 e lo stesso gateway. Casi tipici:

• più indirizzi IPv4 pubblici su una connessione WAN statica;
• un indirizzo pubblico dedicato per DNAT, WAF o un servizio di posta;
• un indirizzo sorgente fisso per traffico inoltrato selezionato;
• una seconda subnet interna sullo stesso segmento fisico durante una migrazione controllata;
• più indirizzi del provider nella stessa subnet, per i quali interfacce WAN separate causerebbero problemi ARP.

Più interfacce WAN nella stessa subnet non rappresentano una soluzione pulita. Sophos avverte che i gateway possono diventare irraggiungibili a causa di problemi ARP e indica alias o LAG come forme di interfaccia appropriate. Zone e interfacce su Sophos Firewall spiega la scelta di base tra porte fisiche, VLAN, LAG, bridge e XFRM.

Un alias non è adatto se servono una seconda linea, un gateway proprio, uno stato del link indipendente, una zona di sicurezza diversa o un vero failover. In questi casi occorre un design dedicato di interfaccia, VLAN, LAG, WAN o routing.

Se il firewall non deve possedere localmente un indirizzo IPv4 aggiuntivo, ma deve soltanto rispondere per suo conto alla richiesta ARP su un segmento collegato direttamente, si tratta di un design diverso. Configurare Proxy ARP su Sophos Firewall spiega la scelta e la procedura CLI e di test strettamente limitata.

Esempio e valori da sostituire

L’esempio pubblica un servizio HTTPS interno tramite un secondo indirizzo pubblico:

• Interfaccia principale: Port2
• Zona principale: WAN
• Indirizzo principale: 203.0.113.9/29
• Gateway del provider: 203.0.113.14
• IP alias: 203.0.113.10/29
• Oggetto host dell’alias: WAN_ALIAS_APP_203.0.113.10
• Server interno: APP-DMZ_10.20.40.20
• IP del server: 10.20.40.20
• Servizio: HTTPS
• Host di test esterno: 198.51.100.25

203.0.113.0/24 e 198.51.100.0/24 sono riservati alla documentazione. Nella configurazione di produzione devono essere sostituiti con gli indirizzi assegnati dal provider e con un host di test esterno autorizzato.

La maschera /29 è solo un esempio realistico. Non deve essere copiata se il provider fornisce un blocco instradato, un singolo indirizzo /32 o una dimensione di rete diversa. Sono determinanti la documentazione del provider, il modello ARP o di routing e la versione IP utilizzata sull’interfaccia principale.

Aggiungere l’alias all’interfaccia fisica

In Network > Interfaces, l’indirizzo viene associato direttamente all’interfaccia esistente:

1. Selezionare Add interface > Add alias.
2. In Physical interface, selezionare Port2 o l’interfaccia principale effettiva.
3. Impostare IP version su IPv4.
4. In IPv4/Netmask, inserire 203.0.113.10 e la maschera confermata dal provider.
5. Salvare con Save.

Per un alias IPv6, impostare IP version su IPv6 in modo che corrisponda all’interfaccia principale selezionata. In IPv6/Prefix, inserire l’indirizzo IPv6 e il relativo prefisso assegnati al proprio ambiente al posto dei valori IPv4 dell’esempio. Quindi salvare con Save.

L’indirizzo aggiuntivo appare quindi sull’interfaccia principale. Se sono presenti più di tre alias, SFOS mostra inizialmente solo i primi tre. Portare il puntatore su uno degli indirizzi IP visibili per far apparire la barra di scorrimento. Scorrere nell’area degli indirizzi visibile per vedere le altre voci.

Un alias non può essere attivato o disattivato in modo indipendente. Se l’interfaccia fisica principale viene disattivata o perde il link, anche i suoi indirizzi alias diventano irraggiungibili. Add alias non configura un gateway indipendente né una route predefinita propria. Questo non esclude route direttamente connesse o locali associate all’indirizzo o alla sua subnet. Soprattutto per un alias in una subnet diversa, confrontare la tabella di routing prima e dopo il salvataggio; restano essenziali il percorso del provider e i requisiti per più subnet indicati di seguito.

La maschera Add alias non dispone di un campo zona separato. Per i servizi locali del firewall resta quindi rilevante la zona dell’interfaccia principale. Prima di aggiungere un IP alias pubblico, controllare in Administration > Device access quali servizi sono raggiungibili da WAN e utilizzare una Local Service ACL Exception restrittiva per fonti di gestione fisse. SSO o MFA non giustificano un accesso WebAdmin ampio.

Utilizzare l’alias nelle regole e nel NAT

L’alias associato e un IP Host hanno funzioni diverse:

• L’alias rende l’indirizzo presente localmente sull’interfaccia fisica.
• L’IP Host rende lo stesso indirizzo chiaramente selezionabile nei campi delle regole e del NAT.

Un oggetto host da solo non associa un indirizzo all’interfaccia. Viceversa, un alias da solo non pubblica un server e non consente traffico inoltrato. Utilizzare correttamente IP Host e servizi spiega in dettaglio i limiti degli oggetti.

Pubblicare un servizio in ingresso con DNAT

Per l’esempio, in Hosts and services > IP host viene creato l’oggetto WAN_ALIAS_APP_203.0.113.10 di tipo IP con l’indirizzo 203.0.113.10. Successivamente vengono create una regola DNAT restrittiva e una regola firewall corrispondente:

• Original source: reti esterne autorizzate o consapevolmente Any
• Original destination: WAN_ALIAS_APP_203.0.113.10
• Original service: HTTPS
• Translated destination (DNAT): APP-DMZ_10.20.40.20
• Translated service (PAT): Original
• Inbound interface: Port2 o l’ingresso effettivamente confermato
• Translated source (SNAT): normalmente Original
• Log firewall traffic: attivato

La regola firewall consente lo stesso servizio esterno da WAN alla zona del server interno e utilizza come Destination network l’indirizzo alias pubblico di Original destination. Sorgente, servizio e funzioni di protezione vengono limitati il più possibile. La procedura completa con posizione della regola, loopback e hardening è disponibile in Pubblicare un server con DNAT.

Inviare il traffico inoltrato tramite l’IP alias

Se solo uno specifico server interno deve apparire esternamente come 203.0.113.10, viene creata una regola SNAT dedicata esattamente a questo flusso. Translated source (SNAT) utilizza quindi l’IP Host dell’indirizzo alias. Sorgente, destinazione, servizio e interfacce restano quanto più limitati possibile in base al caso d’uso.

La regola NAT non sostituisce una regola firewall. Inoltre, le regole NAT vengono valutate solo per il primo pacchetto di una nuova connessione. Dopo una modifica occorre aprire una nuova connessione; una sessione già esistente non dimostra il nuovo percorso NAT. NAT su Sophos Firewall spiega l’elaborazione di SNAT, DNAT e PAT.

Gestire separatamente il traffico di sistema del firewall

Il traffico DNS, di autenticazione, di posta o altro traffico generato dal firewall stesso non segue automaticamente una regola SNAT per client inoltrati. Sophos documenta esplicitamente che le configurazioni di routing utilizzano l’interfaccia principale. Se un flusso specifico e giustificato di traffico di sistema deve usare l’IP alias come sorgente, è necessaria una configurazione CLI separata.

Prima della modifica, salvare lo stato iniziale nella Device Console:

show advanced-firewall

Il seguente esempio facoltativo utilizza Port2, la destinazione 198.51.100.25 e l’IP alias 203.0.113.10. Viene conservato come modello, ma non deve essere eseguito finché non sono stati confermati la sintassi e l’ambito effettivo di corrispondenza per il build installato:

⚠️ Questo comando modifica l’indirizzo sorgente del traffico del firewall. Non crea una route e non è un sostituto generale di una regola NAT. Nella sintassi documentata, destination e snatip sono parametri obbligatori; netmask e interface sono facoltativi. Tuttavia, le descrizioni pubbliche di SFOS 22/23 non spiegano quale campo di indirizzo venga delimitato da netmask né come interface limiti la corrispondenza. Prima di utilizzare questi parametri facoltativi, far confermare la sintassi e la delimitazione tramite la documentazione specifica del build o Sophos Support. Senza questa conferma, non eseguire l’esempio; non dedurre dall’elenco dei parametri una limitazione garantita all’interfaccia o alla rete di destinazione. Se la voce prevista esiste già o si sovrappone a una configurazione esistente il cui ambito non è stato chiarito, interrompere il test senza aggiungere o eliminare nulla. Dopo la modifica, testare esattamente il servizio interessato e il relativo flusso effettivo di pacchetti, quindi controllare nuovamente la voce con show advanced-firewall.

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Per il rollback, eliminare esattamente la stessa voce con delete:

⚠️ L’eliminazione ripristina l’indirizzo sorgente del traffico di sistema interessato. Prima confrontare la voce mostrata da show advanced-firewall con lo stato iniziale registrato e verificare le dipendenze. Eliminare solo la voce aggiunta per questo test; quindi ricontrollare il servizio interessato e lo stato della configurazione.

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

La maschera /32 255.255.255.255 dell’esempio è scelta deliberatamente per il singolo host di destinazione previsto, ma non è un requisito sintattico e, senza una semantica di corrispondenza confermata, non dimostra tale ambito. Anche con una maschera più ampia, non presumere in generale che venga tradotta l’intera rete di destinazione. Far confermare prima il campo di indirizzo effettivamente interessato e l’ambito risultante per il build installato; utilizzare solo un ambito intenzionale e documentato, e controllare il servizio interessato e i flussi non interessati.

IPsec tramite alias con più interfacce WAN

Quando esistono più interfacce WAN e una connessione IPsec usa un indirizzo alias come indirizzo locale, Sophos richiede la route basata sulla sorgente per gli alias. L’opzione non è uno switch generale per gli alias e non viene attivata solo per DNAT, SNAT o una seconda subnet.

Attivare per il caso IPsec descritto: Prima della modifica, documentare lo stato precedente dell’opzione, le interfacce WAN, l’alias, l’indirizzo locale del tunnel, la tabella di routing, le SA attive e il piano di rollback.

Le descrizioni ufficiali del routing per SFOS 22 e 23 documentano il setter per questa opzione, ma non un getter né un valore predefinito. Prima di impostarla, devono essere disponibili un metodo di lettura documentato per il build installato o confermato da Sophos Support, il valore iniziale effettivo rilevato con tale metodo e una procedura confermata per ripristinare esattamente quel valore. Se manca uno di questi prerequisiti, non modificare l’opzione; non tentare di indovinare un comando di lettura o ripristino. La tabella di routing, le SA attive e i test di connessione sono verifiche operative aggiuntive, non una rilettura dello stato dello switch. Se l’opzione era già attivata, lasciarla invariata e non disattivarla durante il rollback.

⚠️ Questa opzione modifica il trattamento del routing basato sulla sorgente per gli indirizzi alias. Attivarla nella Device Console solo per l’esigenza confermata, con un percorso di gestione indipendente disponibile:

set routing source-base-route-for-alias enable

enable crea il trattamento di routing basato sulla sorgente necessario per gli indirizzi alias, ma non crea un tunnel IPsec, una regola firewall o una route XFRM, statica o SD-WAN. Route-based IPsec richiede comunque una route verso l’interfaccia XFRM; policy-based IPsec continua a usare le reti locali e remote configurate.

Dopo l’attivazione, rilevare nuovamente il valore effettivo dell’opzione con lo stesso metodo di lettura confermato e confrontarlo con lo stato previsto. Inoltre, testare una nuova connessione in entrambe le direzioni e confrontare la tabella di routing e le SA attive con lo stato iniziale.

Rollback condizionale, non il passaggio di configurazione successivo: disable è il rollback solo se l’opzione era prima disattivata e nessun’altra connessione IPsec tramite alias ne dipende. Verificare prima entrambe le condizioni nella configurazione documentata.

⚠️ La disattivazione rimuove il trattamento del routing basato sulla sorgente e può influire sulle connessioni IPsec che ne dipendono. Eseguire nella Device Console solo dopo aver confermato lo stato precedente e verificato le dipendenze:

set routing source-base-route-for-alias disable

Dopo il rollback, rilevare nuovamente il valore effettivo dell’opzione con lo stesso metodo di lettura confermato e confermare la corrispondenza esatta con il valore iniziale registrato.

Quindi ricontrollare la tabella di routing, le SA attive e una nuova connessione in entrambe le direzioni. Configurare una VPN IPsec site-to-site spiega tipi di tunnel e routing; Creare una route IPsec descrive la route XFRM.

Pianificare alias di subnet diverse

Sophos consente più indirizzi alias di subnet diverse sulla stessa interfaccia fisica, ma stabilisce due condizioni:

• Sophos Firewall deve essere il default gateway degli host interni.
• I dispositivi upstream che fungono da gateway per il traffico del firewall devono disporre di un indirizzo appropriato in ogni subnet alias utilizzata.

Un alias non rende quindi automaticamente operativa una seconda subnet end-to-end. Anche gateway degli host, peer, route di ritorno, ARP o Neighbor Discovery, regole firewall e NAT devono essere corretti per quella subnet.

Per una segmentazione permanente, una VLAN o un’interfaccia fisica dedicata è generalmente più comprensibile. Un alias multi-subnet è più adatto a una transizione pianificata consapevolmente o a un’architettura del provider in cui entrambe le reti condividono realmente lo stesso percorso di livello 2.

DHCP Server e DHCP Relay non possono essere configurati su un Interface Alias. Inoltre, un alias non è un Dedicated HA link valido. Questi requisiti devono utilizzare un’interfaccia fisica o virtuale supportata.

Verificare il percorso dati e ARP

La verifica deve seguire il compito reale e non limitarsi a un ping:

1. In Network > Interfaces, controllare interfaccia principale, indirizzo alias, maschera e stato del link.
2. Sul dispositivo del provider o upstream, verificare che l’IP alias sia raggiungibile tramite l’indirizzo MAC o il neighbor previsto.
3. Da 198.51.100.25, aprire una nuova connessione HTTPS all’IP alias.
4. In Log Viewer, controllare Firewall Rule ID, NAT Rule ID, Source, Original destination e destinazione tradotta previsti.
5. Nel Packet Capture integrato, confrontare l’ingresso su Port2 con l’uscita verso il server.
6. Sul server interno, confermare che la connessione arrivi e che la risposta ritorni tramite Sophos Firewall.
7. Eseguire un test negativo con una porta volutamente non consentita e una sorgente non autorizzata.
8. In HA, ripetere un failover controllato con una nuova connessione senza presumere che una sessione esistente continui senza interruzioni.

Un ping all’IP alias è significativo solo se Ping è consapevolmente consentito per la zona principale in Device Access. Per un servizio HTTPS pubblicato, il test TCP e applicativo reale è una prova di successo migliore. Packet Capture su Sophos Firewall spiega filtri, confronto tra interfacce ed esportazione.

Circoscrivere gli errori in modo sistematico

L’alias è visibile ma non raggiungibile dall’esterno

• Confermare che il provider fornisca realmente l’indirizzo specifico tramite Port2.
• Confrontare IP, maschera e interfaccia principale con l’assegnazione del provider.
• Controllare la voce ARP o neighbor sul dispositivo upstream.
• Esaminare Device Access solo per gli accessi al firewall stesso.
• Per i servizi inoltrati, controllare Firewall Rule ID, NAT Rule ID e percorso di ritorno del server.

Per l’esempio IPv4, confrontare separatamente le voci ARP dell’indirizzo principale 203.0.113.9 e dell’IP alias 203.0.113.10 con l’attuale indirizzo MAC WAN. Se l’indirizzo principale funziona mentre l’alias punta ancora al vecchio MAC e durante il test esterno non arrivano pacchetti su Port2, una voce upstream obsoleta è un indizio concreto. Se i pacchetti arrivano già, esaminare prima il percorso firewall/NAT e la risposta del server invece di riavviare il router sulla base di un sospetto. La sola assenza di una voce non dimostra la causa; per un blocco instradato dal provider, verificare anche la route confermata e il relativo next hop. IPv6 utilizza Neighbor Discovery invece di ARP.

⚠️ Svuotare una cache o riavviare un router non garantisce una riparazione senza interruzioni. Prima coinvolgere il responsabile del dispositivo o il provider, confermare la procedura documentata e l’ambito dell’intervento, e assicurare l’accesso da console o un percorso di gestione indipendente. Anche l’accesso remoto al firewall può attraversare questo router e interrompersi. Se non si controlla il dispositivo upstream, chiedere l’intervento del provider fornendo l’IP interessato, gli indirizzi MAC vecchio/nuovo e l’esito del test. Dopo la modifica, verificare la nuova voce, ripetere lo stesso test HTTPS esterno e controllare un servizio non interessato; se il problema persiste, inoltrare i riscontri per l’escalation invece di svuotare ripetutamente l’intera cache.

Dopo la sostituzione di un firewall, il router upstream può conservare ancora il vecchio indirizzo MAC per l’IP alias. In questo caso Sophos indica di svuotare la cache del router o di riavviarlo. In pratica, aggiornare prima solo la voce ARP o neighbor interessata con la procedura documentata del dispositivo upstream; un riavvio completo deve avvenire in una finestra di manutenzione.

Il traffico in uscita continua a utilizzare l’indirizzo principale

Per il traffico inoltrato, controllare se la regola SNAT prevista corrisponde a una nuova connessione. Source, Destination, Service, Inbound interface, Outbound interface e NAT Rule ID devono coincidere.

Per il traffico di sistema del firewall, una normale regola SNAT non rappresenta la prova corretta. Controllare invece la voce sys-traffic-nat specifica, la route, la destinazione e il flusso di pacchetti effettivo. Non aggiungere una traduzione ampia sulla base di un sospetto.

Solo la seconda subnet interna non funziona

Verificare che Sophos Firewall sia realmente il default gateway degli host interessati e che il dispositivo upstream disponga di un indirizzo appropriato in questa subnet. Controllare poi separatamente route di ritorno, maschera dell’host, ARP, regola firewall e NAT. Un alias visibile non dimostra queste dipendenze.

Il tunnel IPsec tramite un alias è attivo ma non trasporta traffico

Registrare prima versione e build SFOS, modello dell’appliance, utilizzo di PPPoE, associazione dell’alias, IPsec Acceleration e percorso effettivo dei pacchetti. SFOS 22 presenta casi limite di alias e accelerazione legati a versioni specifiche che non devono essere applicati a ogni problema con alias. La procedura di diagnosi delimitata è disponibile in Troubleshooting IPsec per interfacce alias.

Operatività, appliance sostitutiva e rollback

Gli indirizzi alias devono essere documentati insieme ad assegnazione del provider, DNS, certificati, NAT, regole firewall e servizio responsabile. Prima di sostituire un firewall, gli alias pubblici e il previsto cambio ARP o neighbor devono far parte della verifica.

Per un rollback:

1. Documentare gli utilizzi attivi dell’alias e dell’IP Host associato.
2. Rimuovere in modo controllato i servizi pubblicati da DNS, monitoraggio o load balancing.
3. Disattivare prima le regole firewall e NAT associate e confermare l’interruzione del flusso previsto.
4. Utilizzare l’esatto comando delete per rimuovere solo le voci sys-traffic-nat aggiunte durante questa modifica e assenti nello stato iniziale salvato. Conservare le voci esistenti; se una voce esistente è stata modificata, ripristinare esattamente la sua configurazione precedente documentata e verificarla con show advanced-firewall e un test del servizio. La dismissione di voci già in produzione richiede una rimozione autorizzata separatamente dopo la verifica delle dipendenze.
5. Eliminare alias e oggetto host solo quando non rimane alcuna dipendenza produttiva.
6. Controllare nuovamente interfaccia principale, indirizzo principale, gateway e servizi non interessati.
7. In HA, ripetere la stessa verifica dopo un failover pianificato.

Un alias non può essere utilizzato come Dedicated HA link. HA su Sophos Firewall spiega interfacce, indirizzi di amministrazione del peer e test di failover necessari per un cluster.

Checklist

• Assegnazione del provider, interfaccia principale, versione IP, indirizzo e maschera sono confermati.
• Sono disponibili un backup e una connessione amministrativa indipendente.
• Device Access e Local Service ACL della zona principale sono stati controllati.
• Alias e IP Host con lo stesso nome non vengono confusi.
• Le regole firewall e NAT sono limitate al flusso previsto.
• Il traffico di sistema viene tradotto separatamente solo in presenza di un’esigenza giustificata.
• Firewall Rule ID, NAT Rule ID, ARP e entrambe le direzioni sono confermati.
• Una sorgente non autorizzata e un servizio non consentito sono stati testati negativamente.
• Appliance sostitutiva, failover HA e rollback sono documentati.

Domande frequenti