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 e XFRM indirizzati, perché può avere un Health Check e una zona propri ed essere poi utilizzato in una route SD-WAN. SFOS supporta i Custom Gateway per IPv4 e IPv6; l’esempio dell’articolo utilizza IPv4.

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.

Per questi gateway creati automaticamente, la zona non può essere modificata in Routing > Gateways. Il gateway predefinito è assegnato in modo fisso alla zona WAN. La zona del gateway selezionabile nella procedura seguente si applica ai Custom Gateway, non al gateway predefinito.

Le regole di failover di un gateway Cellular WAN si configurano in Network > WAN link manager. Cellular WAN e failover 4G/5G spiega configurazione, destinazioni di verifica del percorso mobile e test di commutazione.

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, la zona del gateway non viene applicata; sono le zone effettive delle interfacce e la regola firewall corrispondente a determinare il match delle zone. 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.

I Custom Gateway esistenti possono anche essere modificati, clonati ed eliminati in Routing > Gateways. Prima dell’eliminazione, verificare le dipendenze come descritto nella procedura di rollback più avanti.

Scegliere un Health Check rappresentativo del percorso

Health check è disattivato per impostazione predefinita. SFOS documenta i seguenti valori temporali predefiniti:

• Interval: Tempo tra le sonde dell’Health Check; valore predefinito: 60 secondi.
• Time-out: Tempo entro cui una sonda deve ricevere risposta affinché il gateway sia considerato attivo; valore predefinito: 2 secondi.
• Retries: 3

Retries definisce il numero di tentativi di verifica consecutivi. Se nessuno di questi tentativi riceve risposta, SFOS considera il gateway irraggiungibile. Sophos non fornisce una formula completa per calcolare il tempo esatto di rilevamento del guasto; Interval, Time-out e Retries vanno quindi considerati insieme. Protocol e IP address sono invece scelte progettuali. In questo esempio si usa PING verso 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. In generale, Sophos richiede come destinazione un host sempre disponibile dietro il gateway. Anche l’esempio XFRM Any-to-Any ufficiale segue questo principio.

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.

Per aggiungere un’altra Monitoring Condition, selezionare AND o OR in Operator e fare clic sull’icona di aggiunta. Impostare quindi protocollo, IP di destinazione e, per TCP, porta della condizione aggiuntiva. Gli operatori funzionano così:

• 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 Service.
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.

Il valore predefinito di SFOS 22 per Route Precedence è static, SD-WAN, VPN. Se SD-WAN precede Static e una route SD-WAN usa Any come destinazione, può intercettare anche traffico interno o direttamente connesso e interrompere l’accesso di gestione. La destinazione restrittiva dell’esempio evita questo problema. Se il design richiede più di un gateway Primary e uno Backup, è possibile usare un SD-WAN Profile con un massimo di otto gateway.

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 zones: LAN
• Source networks and devices: 10.10.0.0/24
• Destination zones: MPLS
• Destination networks: 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 dagli 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.

Inoltrare un IP virtuale via IPsec a più server mostra come una sede remota raggiunge un IP virtuale tramite un gateway XFRM di questo tipo e route SD-WAN speculari, mentre il DNAT distribuisce le connessioni tra più server interni.

Route-based IPsec con traffic selector specifici funziona diversamente: per questi traffic selector non viene creata una route manuale aggiuntiva e l’XFRM non riceve un proprio IP. Una procedura gateway Any-to-Any non va applicata a questa variante.

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 System services > Log settings, verificare che il modulo SD-WAN sia registrato. Controllare quindi in Log viewer 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. OUT conta le richieste e IN le risposte, purché ciascuna direzione corrisponda a Source e Destination della route; un contatore unidirezionale, da solo, non indica quindi un errore del percorso.

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. Quando il gateway Primary torna disponibile, le nuove connessioni lo utilizzano di nuovo; quelle esistenti rimangono inizialmente sul Backup.

Per impostazione predefinita, SFOS 22 reindirizza le connessioni senza SNAT quando cambia il gateway o lo SLA. Per le connessioni SNAT non avviene automaticamente. Il reindirizzamento con SNAT richiede lo stesso IP sorgente tradotto su entrambi i percorsi e l’opzione separata reroute-snat-connection; MASQ o IP sorgente diversi impediscono quindi spesso una commutazione trasparente. Nel test di accettazione 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.

XML API su SFOS 23: Per Add Gateway Object e Update Gateway Object, lo stato API 505 è documentato con l’identificativo del messaggio Message.GatewayIpNotInInterfaceIpRange. Si tratta dello stato nella risposta dell’API, non di un codice di stato HTTP; l’identificativo non garantisce il testo esatto del messaggio visualizzato. Se si riceve questo risultato, verificare la rete dell’interfaccia selezionata e l’indirizzo del next hop previsto (Gateway IP) prima di riprovare. La presenza di questo stato nella documentazione di SFOS 23 non dimostra che la validazione degli indirizzi sia stata introdotta con questa versione.

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ù. Se si elimina un gateway Backup, SFOS imposta il Backup della route su None. Se si elimina il gateway Primary o il SD-WAN Profile selezionato, SFOS elimina la route SD-WAN e usa quindi la route predefinita WAN link load balance.

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