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 in modo mirato la cache ARP oppure si esegue un ARP Ping tramite la Device Console. Per la migrazione hardware in generale, è utile anche Confrontare Sophos XG e XGS.

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.

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 gli indirizzi alias appartengono a una subnet diversa, verificare che l’upstream sia raggiungibile in tale subnet come gateway del firewall. Più interfacce WAN separate nella stessa subnet non sono una soluzione corretta e possono causare a loro volta problemi ARP; a seconda del design, si devono utilizzare interfacce alias o LAG.
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, acquisire il traffico sull’interfaccia WAN. Per il controllo di livello 2, filtrare per interfaccia e Ethernet type: ARP; successivamente, per il servizio, filtrare in base all’IP di destinazione interessato e al protocollo.
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 sulla WAN: controllare ARP upstream, routing del provider, CPE o switch upstream.
I pacchetti arrivano e vengono scartati: controllare regola firewall, DNAT, zona e servizio.
I pacchetti vengono inoltrati internamente, 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 in modo mirato l’associazione ARP

Svuotare la cache 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, anche il riavvio del router responsabile può aggiornare la cache. L’operazione deve avvenire durante una finestra di manutenzione, perché interrompe anche altre connessioni. Se si tratta di un dispositivo del provider, è preferibile comunicare al provider l’IP interessato, il vecchio e il nuovo indirizzo MAC e il CPE coinvolto, anziché riavviare indiscriminatamente l’intero percorso.

Eseguire un ARP Ping tramite la Device Console

Sophos Firewall offre una funzione diagnostica ARP nella Device Console. Utilizzando l’IP sorgente interessato e l’interfaccia WAN, l’ARP Ping può stimolare un aggiornamento sull’upstream direttamente connesso.

Dopo aver effettuato l’accesso dalla console o tramite SSH, aprire Option 4: Device Console ed eseguire il comando con i valori reali:

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Esempio con indirizzi riservati alla documentazione:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

In questo esempio, 198.51.100.21 è l’IP alias interessato su Port2, mentre 198.51.100.1 è l’upstream direttamente raggiungibile nello stesso segmento di livello 2. IP sorgente, interfaccia e destinazione devono essere coerenti. Se sono interessati più IP alias, testare ogni indirizzo separatamente per poter valutare con precisione l’effetto.

Il comando non corregge una configurazione alias errata né sostituisce la correzione di una voce ARP statica presso il provider. Se il provider instrada gli indirizzi anziché risolverli localmente tramite ARP, anche l’ARP Ping non è la soluzione appropriata. Connettersi a Sophos Firewall tramite SSH descrive come accedere in modo sicuro alla Device Console.

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, è previsto l’indirizzo MAC virtuale o fisico errato.

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 dell’ARP Ping,
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 ARP Ping eseguito con i parametri corretti.
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.

L'ARP Ping richiede l'Advanced Shell?

No. system diagnostics utilities arp ping viene eseguito nella Device Console. L’Advanced Shell non è necessaria.