Risolvere i problemi ARP dopo una migrazione Sophos Firewall

Dopo la sostituzione di un firewall, il nuovo Sophos Firewall può essere online mentre singoli indirizzi IP alias pubblici rimangono irraggiungibili. Spesso il router upstream associa ancora questi indirizzi al MAC WAN della vecchia appliance. In questo caso, i pacchetti non raggiungono affatto il nuovo firewall, anche se alias, DNAT e regola firewall sembrano configurati correttamente.

Questa guida mostra come circoscrivere il problema IPv4 controllando l’interfaccia, usando Packet Capture e verificando l’ARP upstream. Solo dopo aver dimostrato che la causa si trova al livello 2, si aggiorna la cache ARP sul dispositivo che conserva la voce obsoleta. Per la migrazione hardware in generale, è utile anche Confrontare Sophos XG e XGS Appliance.

Quando sospettare realmente un problema ARP

Il problema si manifesta in genere subito dopo la sostituzione di un’appliance, un ripristino o un cambio di produttore. L’indirizzo IP pubblico rimane invariato, mentre cambia l’indirizzo MAC dell’interfaccia WAN.

Gli indizi più significativi sono:

L’indirizzo IP principale dell’interfaccia WAN funziona, ma uno o più indirizzi IP alias no.
Un test esterno non raggiunge un servizio pubblicato su determinati indirizzi IP pubblici.
In Packet Capture non compare alcun pacchetto in ingresso per l’indirizzo IP interessato.
Il servizio torna improvvisamente a funzionare alla scadenza di una cache upstream, senza ulteriori modifiche al firewall.
Il router upstream mostra ancora l’indirizzo MAC della vecchia appliance per l’IP pubblico.

ARP non è automaticamente la causa. Se i pacchetti arrivano all’interfaccia WAN, il controllo successivo riguarda DNAT, regola firewall, zona, server interno o rotta di ritorno. Questa procedura non si applica nemmeno a IPv6, dove la risoluzione dei nodi adiacenti è gestita da Neighbor Discovery.

Per controllare invece la cache ARP o NDP locale di Sophos Firewall, consultare Controllare la cache dei nodi adiacenti ARP e NDP. L’articolo spiega anche quando svuotare la cache e quando il problema rimane presso il provider o il dispositivo upstream.

Perché gli IP alias possono smettere di funzionare dopo una sostituzione

ARP associa un indirizzo IPv4 a un indirizzo MAC nel segmento locale di livello 2. Un router memorizza questa associazione nella cache ARP. Dopo la sostituzione, l’upstream dovrebbe apprendere il MAC WAN del nuovo firewall. Se ciò non avviene per un IP alias, continua a inviare i pacchetti al vecchio hardware.

Questo spiega perché l’IP principale può funzionare mentre un IP alias non risponde: l’upstream mantiene una voce distinta per ogni indirizzo IP. Un’associazione può essere già aggiornata, mentre un’altra punta ancora al vecchio indirizzo MAC.

Prima occorre però chiarire come il provider fornisce gli indirizzi pubblici:

Rete direttamente connessa: l’upstream risolve tramite ARP sia l’IP principale sia gli IP alias. Dopo una sostituzione hardware, la presenza di vecchie voci è plausibile.
Blocco pubblico instradato: il provider instrada il blocco verso l’IP WAN principale. In questo caso non è necessariamente prevista una voce ARP distinta per ogni IP pubblico; sono più importanti la rotta del provider e la configurazione locale di alias e NAT.

Diagnosi prima dell’intervento

La diagnosi deve innanzitutto mostrare in quale punto si interrompe il flusso dei pacchetti. In questo modo si evita di modificare contemporaneamente ARP, NAT e regole firewall.

In Network > Interfaces, controllare l’interfaccia WAN fisica e gli indirizzi interessati. Un IP alias viene associato all’interfaccia fisica corretta tramite Add interface > Add alias; versione IP, indirizzo e netmask devono corrispondere al design di rete. Se sono presenti più di tre alias, SFOS mostra inizialmente solo tre indirizzi. Passare il puntatore su un indirizzo visibile e scorrere l’elenco prima di ricreare un alias che sembra mancante.
Se gli indirizzi alias appartengono a una subnet diversa, gli host interni devono usare Sophos Firewall come gateway predefinito e l’upstream deve avere, in ogni subnet degli alias, un indirizzo che funga da gateway raggiungibile dal firewall. Secondo Sophos, più interfacce WAN separate nella stessa subnet causano problemi ARP e rendono irraggiungibili i gateway; usare interfacce alias o LAG in base al design.
Da un sistema di test realmente esterno, verificare lo stesso IP pubblico e lo stesso servizio. Il solo ping non è sufficiente, perché ICMP potrebbe essere bloccato; è preferibile eseguire anche un test su una porta TCP nota.
In Diagnostics > Packet capture, attivare l’acquisizione e aprire Display filter. Per il controllo di livello 2, selezionare Interface name e Ethernet type: ARP. Per il servizio, usare Ethernet type: IPv4, il Destination IP interessato e, se necessario, Destination port. Senza Wrap capture buffer once full, l’acquisizione si arresta quando il buffer da 2048 KB è pieno; selezionare Clear e ripetere il test riproducibile. Con l’opzione attiva, l’acquisizione riparte dall’inizio del buffer e sovrascrive i pacchetti precedenti.
Solo se arrivano pacchetti IP, cercare nel Log viewer l’IP di destinazione, il servizio, la Firewall Rule ID e la NAT Rule ID. ARP si analizza con Packet Capture, non tramite un normale log delle regole firewall.

Utilizzare Packet Capture su Sophos Firewall illustra la visualizzazione in modo più dettagliato. Per controllare interfaccia, zona e assegnazione dell’alias, consultare Configurare zone e interfacce di Sophos Firewall.

Le osservazioni indicano chiaramente la direzione da seguire:

Nessun pacchetto IPv4 sulla WAN: controllare ARP upstream, routing del provider, CPE o switch upstream.
Stato Incoming o Violation: il pacchetto raggiunge il firewall. Con Violation, Reason, regola firewall, DNAT, zona e servizio forniscono gli indizi successivi.
Stato Forwarded, ma manca la risposta: controllare rotta di ritorno, server interno, SNAT e firewall del server.
È interessato solo l’IP alias: confrontare la configurazione dell’alias e la voce upstream specifica per tale IP.

Aggiornare l’associazione ARP sul dispositivo upstream

La correzione più pulita si effettua sul dispositivo che contiene la voce errata. Se si gestisce il router upstream o il CPE del provider, eliminare in modo mirato la voce ARP relativa all’IP interessato. L’upstream dovrà quindi apprendere il nuovo indirizzo MAC WAN.

Se non è possibile eliminare una singola voce, Sophos indica come alternativa il riavvio del router responsabile. L’operazione deve avvenire durante una finestra di manutenzione, perché interrompe altre connessioni e non può essere annullata. L’eliminazione di una voce dinamica non richiede un rollback della configurazione: il router la apprende nuovamente. Se si ripristina la vecchia appliance, eliminare di nuovo la voce dopo averla ricollegata, in modo che venga appreso il vecchio MAC. Per un dispositivo gestito dal provider, comunicare l’IP interessato, il vecchio e il nuovo MAC e il CPE coinvolto.

Questo intervento non richiede alcun comando aggiuntivo nella Device Console. La guida attuale di SFOS 22 indica espressamente di svuotare la cache del router o riavviare il router per le voci ARP obsolete degli alias. Se il provider instrada gli indirizzi anziché risolverli localmente tramite ARP, entrambe le operazioni sulla voce alias sono inefficaci; controllare invece la rotta del provider e la configurazione locale di alias o NAT.

Verificare la raggiungibilità dopo la correzione

Dopo una singola misura, ripetere lo stesso test. In questo modo è possibile stabilire quale intervento ha risolto il problema.

Verificare sull’upstream che l’IP interessato punti ora al nuovo indirizzo MAC WAN.
Ripetere il test esterno tramite ping o porta TCP utilizzando la stessa origine e la stessa destinazione.
Controllare in Packet Capture se i pacchetti arrivano ora all’interfaccia WAN.
Se i pacchetti arrivano, controllare Firewall Rule ID e NAT Rule ID nel Log Viewer.
Testare il servizio pubblicato fino al server interno e lungo il percorso di ritorno.

Una voce ARP aggiornata dimostra soltanto che l’upstream può inviare i pacchetti al nuovo firewall. Il funzionamento del servizio dipende ancora da DNAT, regola firewall, destinazione interna e rotta di ritorno. Pubblicare un server tramite DNAT illustra il percorso completo delle regole.

Se il problema persiste

Se l’IP rimane irraggiungibile nonostante la voce ARP aggiornata, non bisogna provare altri comandi shell, ma cambiare ipotesi.

Le alternative tipiche sono:

L’IP alias si trova sull’interfaccia fisica errata o utilizza una netmask sbagliata.
Il provider instrada il blocco pubblico in modo diverso da quanto previsto.
Una voce ARP o MAC statica nell’upstream prevale sull’apprendimento dinamico.
Uno switch upstream mantiene una vecchia associazione MAC o utilizza Port Security.
La regola DNAT fa riferimento a un altro IP pubblico.
La regola firewall non consente l’origine, il servizio o la zona.
Il server interno risponde tramite un gateway diverso.
In una configurazione HA, il dispositivo primario risponde alle richieste ARP con l’indirizzo MAC virtuale dell’interfaccia. Solo le appliance virtuali con Use host or hypervisor-assigned MAC address selezionato usano invece l’indirizzo MAC assegnato dall’host o dall’hypervisor.

Anche una perdita ARP ricorrente non deve essere gestita con un comando personalizzato eseguito periodicamente. In questo caso, provider, CPE, design di livello 2 ed eventualmente Sophos Support devono chiarire la causa.

Coinvolgere in modo mirato il provider o il team upstream

Se l’acquisizione sulla WAN non mostra pacchetti per l’IP interessato, il provider necessita di un riscontro preciso, non della generica segnalazione che il firewall non è raggiungibile.

Occorre preparare:

IP principale o alias interessato,
interfaccia WAN e nuovo indirizzo MAC,
gateway upstream o CPE,
orario del test esterno e dello svuotamento della cache o del riavvio,
risultato di Packet Capture,
modalità di fornitura prevista come rete direttamente connessa o instradata,
risultato per l’IP principale e gli altri IP alias.

Con queste informazioni, il provider può controllare la voce ARP specifica, un’associazione statica o la rotta verso il blocco pubblico. I dati di configurazione sensibili o le acquisizioni complete dei pacchetti devono essere trasmessi esclusivamente tramite un canale di supporto concordato.

Verifica finale essenziale

IP principali e alias, nonché modalità di fornitura, documentati.
Interfaccia fisica, versione IP e netmask verificate.
Test TCP esterno e Packet Capture eseguiti con destinazioni identiche.
Traffico ARP e IP analizzati separatamente durante la diagnosi.
Voce upstream eliminata in modo mirato oppure router riavviato in una finestra di manutenzione concordata.
Nuova associazione MAC confermata sull’upstream.
DNAT, Firewall Rule ID, NAT Rule ID e percorso di ritorno controllati successivamente.
Causa e intervento documentati nel change o nel verbale di migrazione.

FAQ

È necessario svuotare la cache ARP dopo ogni migrazione del firewall?

No. Normalmente l’upstream apprende automaticamente il nuovo indirizzo MAC. È necessario intervenire solo quando una voce specifica rimane obsoleta e Packet Capture mostra che l’IP interessato non raggiunge il nuovo firewall.

Perché l'IP principale funziona, ma un IP alias no?

L’upstream memorizza l’associazione per ogni indirizzo IPv4. La voce dell’IP principale può già puntare al nuovo indirizzo MAC WAN, mentre un IP alias è ancora associato al vecchio indirizzo MAC.

Si tratta di un problema ARP, NAT o di una regola firewall?

Se durante il test esterno non arriva alcun pacchetto all’interfaccia WAN, la causa si trova prima della valutazione locale di DNAT e delle regole firewall. Se il pacchetto arriva, occorre controllare NAT Rule ID, Firewall Rule ID, destinazione interna e rotta di ritorno.

Si può semplicemente riavviare il CPE del provider?

Un riavvio può aggiornare la cache ARP, ma interrompe anche altre connessioni. È preferibile eliminare in modo mirato la voce interessata; in caso contrario, il riavvio deve avvenire durante una finestra di manutenzione concordata.