Creare e verificare un Custom Gateway su Sophos Firewall

Un Custom Gateway descrive su Sophos Firewall un next hop su un’interfaccia esistente. L’oggetto è particolarmente utile per percorsi MPLS, RED, GRE e XFRM indirizzati, perché può avere un Health Check e una zona propri ed essere poi utilizzato in una route SD-WAN.

Risposta rapida

Il Custom Gateway si crea qui:

Routing > Gateways > Add

Per un percorso MPLS tramite Port4, ad esempio, si inseriscono questi valori:

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING verso 10.20.0.10

Il gateway deve quindi essere selezionato in una route SD-WAN appropriata e verificato con la regola firewall, il percorso di ritorno, Log viewer e traffico reale. Un’icona di stato verde conferma solo l’Health Check, non il funzionamento dell’intera connessione.

⚠️ Un Custom Gateway non è un gateway WAN fisico aggiuntivo. Non compare in Network > WAN link manager e non partecipa al Load Balancing WAN, nemmeno se gli viene assegnata la zona WAN.

Distinguere Custom Gateway, route e interfaccia

In un percorso funzionante, diversi oggetti svolgono compiti differenti:

• L’interfaccia collega il firewall alla rete di transito, ad esempio Port4, RED o XFRM.
• Il Gateway IP è il router successivo direttamente raggiungibile su questo percorso.
• Il Custom Gateway combina Gateway IP, interfaccia, zona e Health Check opzionale in un oggetto riutilizzabile.
• La route SD-WAN decide quale traffico utilizza questo gateway.
• La regola firewall consente le zone, le reti e i servizi pianificati.
• Il lato remoto necessita di un percorso di ritorno adeguato.

Una normale route statica può contenere direttamente il Gateway IP e non richiede un oggetto gateway separato. Un Custom Gateway diventa utile quando SFOS deve monitorare il percorso, selezionarlo in una route SD-WAN o classificarlo tramite una zona del gateway.

I gateway WAN fisici, invece, vengono creati automaticamente quando si configura un’interfaccia WAN e sono gestiti come Active o Backup nel WAN link manager. Questa separazione evita di trattare per errore un percorso MPLS interno o un tunnel come una connessione Internet.

Pianificare la topologia di esempio

L’esempio continuativo collega una rete client a una rete server remota tramite un router MPLS:

• Rete client locale: 10.10.0.0/24
• Client di test: 10.10.0.10
• Interfaccia firewall: Port4 con 192.0.2.1/30
• Router MPLS: 192.0.2.2
• Rete remota: 10.20.0.0/24
• Host stabile per monitoraggio e test: 10.20.0.10
• Servizio di test: TCP 443
• Zona personalizzata: MPLS di tipo LAN

192.0.2.0/24 è una rete di documentazione e non viene utilizzata in produzione. Nell’ambiente reale, l’IP dell’interfaccia e il Gateway IP devono essere sostituiti insieme con la rete di transito effettiva. La rete remota e l’host di monitoraggio devono trovarsi realmente dietro questo gateway. La zona MPLS viene creata in anticipo in Network > Zones e protetta in base al livello di attendibilità del percorso; zone e interfacce su Sophos Firewall ne spiega le basi.

Prima della modifica si documentano la route esistente, le regole firewall, il comportamento NAT previsto e il percorso di ritorno. Una modifica da remoto richiede inoltre un backup della configurazione, una finestra di manutenzione e un accesso di gestione indipendente.

Creare il Custom Gateway

Inserire i valori di base del gateway

1. Aprire Routing > Gateways.
2. In IPv4, fare clic su Add.
3. Inserire MPLS_Zurich_GW come Name. Il nome è liberamente selezionabile, ma dovrebbe identificare sede e percorso.
4. Inserire 192.0.2.2 come Gateway IP. Si tratta del router MPLS direttamente raggiungibile, non della rete di destinazione remota.
5. Selezionare Port4-192.0.2.1 come Interface. Il Gateway IP e l’interfaccia devono appartenere allo stesso percorso di transito raggiungibile.
6. Selezionare MPLS come Zone.

Sophos Firewall assegna priorità alla zona del gateway rispetto alla zona dell’interfaccia. Tuttavia, la applica al traffico solo quando il gateway è selezionato in una SD-WAN policy route corrispondente. Con una sola route statica, quindi, il comportamento della zona va verificato separatamente. La zona VPN non può essere assegnata a un Custom Gateway.

La zona del gateway non si applica alle SD-WAN policy route migrate da SFOS 18.0 MR1 o versioni precedenti. In questo caso, il solo campo zona visibile non dimostra che una regola esistente sia corretta. Route, corrispondenza della zona e traffico reale vanno prima verificati in una finestra di manutenzione.

Scegliere un Health Check rappresentativo del percorso

Health check è disattivato per impostazione predefinita. Per un percorso MPLS, RED o XFRM monitorato, va attivato iniziando con i valori predefiniti documentati:

• Interval: 60 secondi
• Time-out: 2 secondi
• Retries: 3
• Protocol: PING
• IP address: 10.20.0.10

L’host di monitoraggio si trova volutamente dietro il gateway. Se venisse controllato solo il Gateway IP direttamente adiacente, il router potrebbe rispondere anche con il percorso MPLS o il tunnel a valle interrotto. Per i Custom Gateway su route-based VPN, RED e MPLS, Sophos indica espressamente come destinazione di verifica un host dietro il gateway.

In alternativa si può utilizzare TCP con una porta specifica. È utile quando la verifica deve coprire non solo la raggiungibilità IP, ma anche un servizio che risponde in modo stabile. Tuttavia, una verifica TCP sulla porta 443 dichiara il gateway non disponibile se il servizio web si interrompe, anche quando il routing funziona ancora. La destinazione e il protocollo di verifica devono quindi rappresentare il segnale di failover desiderato.

Con più Monitoring Conditions:

• AND: Tutte le condizioni devono essere soddisfatte. È una modalità rigorosa, ma una sola destinazione non disponibile può provocare una commutazione inutile.
• OR: SFOS verifica le condizioni dall’alto verso il basso finché una non è soddisfatta. Riduce i falsi allarmi, ma può nascondere un’interruzione parziale.

Interval, Time-out e Retries non vanno ridotti senza dati. Prima si misurano la latenza normale e le perdite temporanee di pacchetti sul percorso reale. Valori troppo aggressivi possono far oscillare lo stato tra attivo e inattivo.

Dopo il salvataggio, Routing > Gateways mostra tramite un’icona se l’Health Check considera il gateway attivo o inattivo.

Utilizzare il gateway nel design di routing

Creare una route SD-WAN per il traffico di esempio

Un oggetto gateway non inoltra traffico da solo. Per l’esempio si crea una route SD-WAN:

1. Aprire Routing > SD-WAN routes > IPv4 > Add.
2. Inserire Clients_to_Branch_MPLS come Name.
3. Selezionare l’interfaccia interna come Incoming interface.
4. Impostare Source networks su 10.10.0.0/24.
5. Impostare Destination networks su 10.20.0.0/24.
6. Inizialmente selezionare solo HTTPS, ossia TCP 443, in Services.
7. In Link selection settings, utilizzare Primary and backup gateways.
8. Selezionare MPLS_Zurich_GW come Primary gateway.
9. Inserire un vero percorso di backup solo se è completamente configurato e testato.
10. Impostare consapevolmente Route only through specified gateways: se l’opzione è attiva, SFOS scarta il traffico quando nessuno dei percorsi indicati è disponibile; se è disattivata, può subentrare un’altra route SD-WAN o la route predefinita.
11. Salvare la route e controllarne la posizione. Prevale la prima route SD-WAN corrispondente.

Le reti e il servizio sono valori specifici dell’ambiente. Una route ampia con Any come origine, destinazione e servizio può intercettare molto più traffico del previsto. Per il primo test la corrispondenza rimane restrittiva e viene ampliata consapevolmente solo dopo una verifica riuscita.

Aggiungere la regola firewall e il percorso di ritorno

Per il flusso inoltrato si crea una regola con logging dalla zona di origine della rete client alla zona gateway MPLS. Origine, destinazione e servizio corrispondono alla route SD-WAN:

• Source zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: attivo

La zona del gateway non sostituisce una regola firewall. Viceversa, una regola da sola non impone il percorso MPLS. Entrambe devono corrispondere alla route SD-WAN. Creare e verificare in sicurezza le regole Sophos Firewall spiega il design generale delle regole.

Il router dietro la rete remota necessita di un percorso di ritorno verso 10.10.0.0/24. In una normale interconnessione tra sedi, l’IP originale del client viene generalmente mantenuto. Una regola MASQ ampia lo nasconderebbe e potrebbe sembrare risolvere il ritorno, peggiorando però il design di routing.

Distinguere XFRM, GRE e gli altri percorsi di tunnel

Con route-based IPsec in modalità Any-to-Any, l’interfaccia XFRM riceve un IP di trasferimento. Un Custom Gateway utilizza quindi l’IP XFRM del peer come Gateway IP, l’XFRM locale come Interface e un host stabile nella rete remota come Monitoring Target. La configurazione completa del tunnel rimane nell’articolo Configurare una VPN IPsec site-to-site.

Route-based IPsec con traffic selector specifici funziona diversamente: SFOS crea automaticamente la route e l’XFRM non riceve un proprio IP né una route manuale. Una procedura gateway Any-to-Any non va applicata a questa variante senza verificarla.

Anche un percorso GRE non inizia dall’oggetto gateway. Prima si verificano gli endpoint esterni, gli IP del tunnel e il funzionamento di GRE seguendo Configurare e testare un tunnel GRE su Sophos Firewall. Se il design del provider richiede poi una selezione SD-WAN, il Custom Gateway utilizza l’IP del tunnel del peer come Gateway IP. Zona, Health Check e match della regola devono essere adatti al design specifico; la zona VPN rimane non selezionabile per i Custom Gateway.

Verificare il gateway e il traffico

Controllare stato e utilizzo

1. In Routing > Gateways, MPLS_Zurich_GW deve apparire attivo.
2. Aggiornare Object usage e verificare che la route SD-WAN prevista utilizzi il gateway.
3. Ricontrollare i criteri di corrispondenza, la posizione e il gateway nella route SD-WAN.
4. In Log viewer, controllare nel modulo SD-WAN gli eventi relativi a gateway, Health Check e route.
5. Per una diagnosi più approfondita, utilizzare dgd.log come log di Dead Gateway Detection; servizi e file di log di Sophos Firewall ne spiega il contesto.

Lo stato attivo del gateway dimostra solo che l’host di monitoraggio risponde in base alla condizione scelta. Object Usage dimostra solo il riferimento di configurazione. Solo il test reale successivo conferma il percorso dati.

Testare un flusso di traffico reale

1. Dal client di test 10.10.0.10, avviare una nuova connessione HTTPS verso 10.20.0.10.

2. In Log viewer, controllare origine, destinazione, servizio, Firewall Rule ID, un eventuale NAT Rule ID e il gateway utilizzato.

3. Controllare il Traffic Count della route SD-WAN.

4. In Diagnostics > Packet capture, utilizzare un filtro BPF restrittivo:

   host 10.20.0.10 and tcp port 443
   

5. Verificare che le richieste escano da Port4 e che le risposte tornino tramite lo stesso percorso previsto.

6. Sul sistema di destinazione, controllare l’IP sorgente effettivo e il percorso di ritorno.

Il Policy tester non considera le route SD-WAN. Può verificare la corrispondenza di una regola firewall, ma non il gateway effettivamente utilizzato. Verificare una regola Sophos Firewall con Log Viewer e Packet Capture copre la verifica combinata.

Un test di failover va eseguito solo con un percorso di backup verificato separatamente, in una finestra di manutenzione e con un accesso di gestione indipendente. Il gateway di produzione referenziato non deve essere eliminato come metodo di test. Dopo l’interruzione controllata del percorso, si verificano nuovamente una nuova connessione, lo stato del gateway, l’IP sorgente pubblico o privato, il ritorno e il failback. Non si presume una transizione senza interruzioni.

Circoscrivere sistematicamente gli errori

Il gateway rimane inattivo

• Gateway IP e interfaccia devono descrivere lo stesso percorso di transito direttamente raggiungibile.
• L’host di monitoraggio deve trovarsi realmente dietro il gateway e rispondere in modo affidabile.
• Con PING, verificare che ICMP sia consentito lungo l’intero percorso.
• Con TCP, controllare la porta corretta e un servizio effettivamente attivo.
• Utilizzare Packet Capture per verificare che la sonda e la risposta usino l’interfaccia prevista.
• Modificare Interval, Time-out e Retries solo dopo aver controllato il percorso.

Il gateway è attivo, ma il traffico applicativo non funziona

• La route SD-WAN può mancare, essere posizionata troppo in basso o corrispondere a valori diversi di origine, destinazione o servizio.
• La Source zone e la zona gateway della regola firewall devono corrispondere al flusso reale.
• Controllare separatamente Route Precedence, NAT e il percorso di ritorno.
• L’host di monitoraggio può essere raggiungibile anche quando un altro host o servizio di destinazione non è disponibile.
• Un gateway XFRM attivo non dimostra automaticamente che SA IPsec, regola firewall e route remota siano corretti.

La zona del gateway sembra ignorata

• Verificare che il gateway sia realmente selezionato nella SD-WAN policy route corrispondente.
• Con una sola route statica, controllare la zona dell’interfaccia e la regola firewall che corrisponde effettivamente.
• La zona gateway non si applica a una route SD-WAN migrata da SFOS 18.0 MR1 o versioni precedenti. Non mascherare il percorso con una regola ampia, ma modernizzare in modo controllato la route e il modello delle zone.
• La zona VPN non è selezionabile per un Custom Gateway. Un’interfaccia XFRM resta comunque un’interfaccia VPN e richiede un design consapevole di regole e routing.

Lo stato oscilla inutilmente tra attivo e inattivo

• Controllare la reale disponibilità e gli eventuali rate limit del Probe Target.
• Misurare latenza normale e perdita di pacchetti prima di modificare i valori.
• Con AND, una sola destinazione può rendere inattivo l’intero gateway.
• Con OR, una destinazione alternativa raggiungibile può nascondere un’interruzione parziale.
• Non utilizzare intervalli o Time-out più brevi come soluzione generale di stabilità.

Eseguire un rollback sicuro e gestire il gateway

Prima del rollback si documentano Object Usage, la route originale e le regole firewall originali. Quindi:

1. Disattivare la nuova route SD-WAN o ripristinare il percorso precedente.
2. Verificare con una nuova connessione client che il percorso originale funzioni nuovamente.
3. Rimuovere le regole firewall o NAT create solo per il test quando non rimangono dipendenze.
4. Aggiornare Object Usage.
5. Eliminare il Custom Gateway solo quando nessuna route o nessun profilo lo utilizza più.

Durante l’esercizio si documentano responsabile, Gateway IP, interfaccia, zona, Probe Target, protocollo, Interval, Time-out, Retries, route che utilizzano il gateway e ultimo test di failover. Dopo modifiche a MPLS, RED, XFRM, zone, SD-WAN o host di monitoraggio, si verificano nuovamente sia lo stato sia il traffico reale.

FAQ