Configurare e testare un tunnel GRE su Sophos Firewall

Un tunnel GRE collega due endpoint IP e trasporta al proprio interno traffico instradato. Su Sophos Firewall viene creato nella Device Console con system gre. È adatto, ad esempio, a un on-ramp del provider, a un semplice percorso overlay o a un trasporto che richiede esplicitamente GRE.

Risposta rapida

Per una configurazione sicura, documentare prima gli endpoint WAN esterni, gli IP interni del tunnel e le reti remote. Quindi:

1. Verificare la raggiungibilità underlay tra i due endpoint WAN e il protocollo IP 47.
2. Creare il tunnel GRE in modo speculare su entrambi i firewall con system gre tunnel add.
3. Verificare nomi, endpoint, IP del tunnel e stato con system gre tunnel show.
4. Associare le reti remote al tunnel con system gre route add.
5. Creare regole firewall restrittive e con logging tra LAN e VPN.
6. Testare separatamente GRE sul percorso WAN, la route interna, la Rule ID, il traffico applicativo e il percorso di ritorno.

⚠️ GRE non offre di per sé cifratura o autenticazione. Su una rete non attendibile, GRE viene utilizzato solo se il trasporto non cifrato è espressamente accettato nel progetto di sicurezza. Se servono riservatezza o autenticazione del peer, in genere è più indicata una VPN IPsec site-to-site.

Distinguere endpoint GRE, IP del tunnel e route

Un progetto GRE è composto da più livelli:

• Local gateway: l’interfaccia WAN locale di Sophos Firewall, ad esempio Port2.
• Remote gateway: l’indirizzo IPv4 esterno del peer.
• Local IP e Remote IP: gli indirizzi point-to-point interni del tunnel GRE.
• Route GRE: associa al tunnel un host remoto o una rete di destinazione.
• Regola firewall: consente il flusso dati specifico tra zone e reti.
• Percorso di ritorno: riporta i pacchetti di risposta attraverso il tunnel speculare.

GRE su IPv4 utilizza il protocollo IP 47. Non è né TCP né UDP e non va confuso con la porta 47. Un router a monte, un filtro del provider o una security list cloud deve quindi poter trasportare questo protocollo IP tra i due endpoint esterni.

Lo stato visibile Enabled conferma che la configurazione GRE è salvata e attiva. Non dimostra ancora che il peer risponda, che la route sia corretta o che un’applicazione funzioni.

Quando usare GRE e quando è preferibile IPsec

GRE è leggero e trasporta traffico instradato tra due endpoint definiti. È adatto quando un provider o una piattaforma richiede GRE, quando serve solo l’incapsulamento o quando un percorso underlay attendibile è già protetto separatamente.

GRE non sostituisce un collegamento cifrato tra sedi. Per le normali connessioni su Internet pubblico, IPsec route-based è in genere il punto di partenza più adatto. La combinazione di GRE e IPsec richiede un progetto separato e testato su entrambi i dispositivi; questa procedura di base non crea un percorso GRE-over-IPsec non verificato.

Questo articolo tratta un tunnel IPv4 point-to-point statico. Multicast, PIM-SM, BGP su GRE e i tunnel anycast specifici di un provider sono possibili estensioni, ma vengono pianificati solo dopo il corretto funzionamento del percorso unicast di base.

Pianificare la topologia di esempio

L’esempio collega due Sophos Firewall:

• WAN della sede A: Port2 con 192.0.2.10
• LAN della sede A: 10.10.10.0/24
• IP del tunnel della sede A: 10.255.255.1
• WAN della sede B: Port2 con 198.51.100.20
• LAN della sede B: 10.20.20.0/24
• Server di test della sede B: 10.20.20.10
• IP del tunnel della sede B: 10.255.255.2
• Rete del tunnel: 10.255.255.0/30
• Servizio di test: HTTPS o TCP 443

192.0.2.0/24 e 198.51.100.0/24 sono reti di documentazione e non vengono utilizzate in produzione. I due indirizzi WAN, le interfacce, gli IP del tunnel, le reti LAN e il server di test vanno sostituiti insieme con i valori reali. Gli IP del tunnel devono formare una rete point-to-point dedicata, pianificata in modo identico su entrambi i lati, e non devono sovrapporsi alle reti esistenti.

L’esempio utilizza i nomi di tunnel gre_branch nella sede A e gre_hq nella sede B. I nomi sono liberamente selezionabili, ma l’API SFOS 22 attuale li limita a 15 caratteri.

Prima della modifica, predisporre un backup della configurazione, una finestra di manutenzione e un accesso di gestione indipendente per il ripristino. Registrare anche le route statiche e SD-WAN, le regole NAT, le regole firewall e le reti sovrapposte esistenti.

Verificare i prerequisiti del percorso esterno

I due endpoint WAN devono potersi raggiungere attraverso l’underlay. Il progetto di base utilizza indirizzi IPv4 statici su entrambi i lati. Se l’indirizzo WAN locale viene assegnato tramite PPPoE o DHCP, non proseguire con questa procedura: le precedenti istruzioni GRE ufficiali di Sophos escludono le interfacce WAN locali dinamiche, mentre l’API SFOS 22 attuale documenta DDNS solo per Remote Gateway. Occorre quindi chiarire il supporto per il build e la connessione specifici.

Prima di configurare il tunnel, verificare i punti seguenti:

• L’indirizzo WAN remoto viene instradato attraverso il gateway WAN previsto.
• I router a monte, i provider e le ACL cloud consentono il protocollo IP 47 tra i due endpoint.
• Non è presente una configurazione CGNAT o NAT il cui comportamento GRE non sia stato chiarito.
• Gli IP interni del tunnel e le reti LAN non si sovrappongono né localmente né da remoto.
• Il peer utilizza gli stessi valori esterni e interni in ordine inverso.
• È pianificato un percorso di ritorno verso entrambe le reti LAN.

Un ping verso il peer pubblico può supportare il test dell’underlay, ma non dimostra il supporto GRE. Analogamente, consentire la porta TCP o UDP 47 non serve, perché GRE non è un protocollo di trasporto basato su porte.

Creare il tunnel GRE su entrambi i firewall

La configurazione avviene nel menu CLI 4. Device Console. La pagina della guida Sophos attuale contiene frammenti di sintassi visualizzati in modo errato. Prima della modifica, utilizzare Tab o ? sul build installato per confermare che siano disponibili i parametri seguenti.

Configurare la sede A

Sul firewall A inserire la porta WAN locale Port2, il peer esterno 198.51.100.20 e la coppia interna del tunnel:

system gre tunnel add name gre_branch local-gw Port2 remote-gw 198.51.100.20 local-ip 10.255.255.1 remote-ip 10.255.255.2

Eseguire quindi questo controllo in sola lettura:

system gre tunnel show

La voce deve mostrare correttamente gre_branch, Port2, l’indirizzo WAN remoto e i due IP del tunnel. Un errore di battitura non va nascosto creando una seconda configurazione con un nome simile.

Configurare la sede B in modo speculare

Sul firewall B invertire i valori locali e remoti:

system gre tunnel add name gre_hq local-gw Port2 remote-gw 192.0.2.10 local-ip 10.255.255.2 remote-ip 10.255.255.1

Anche qui eseguire il controllo in sola lettura:

system gre tunnel show

In questa fase Enabled è solo un controllo intermedio. La convalida termina soltanto con un flusso dati LAN-to-LAN reale.

Instradare le reti remote tramite GRE

Per il semplice percorso fisso, aggiungere una route GRE su ciascun firewall. La sede A invia la LAN della sede B attraverso gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

La sede B riceve il percorso di ritorno speculare:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Leggere quindi le associazioni configurate su entrambi i dispositivi:

system gre route show

La route non deve competere con un percorso statico, SD-WAN, VPN o direttamente connesso della stessa lunghezza o più specifico. Non modificare la Route Precedence globale sulla base di un sospetto. Prima occorre dimostrare la route effettivamente utilizzata e il percorso dei pacchetti.

Custom Gateway e SD-WAN come alternativa

Alcuni progetti dei provider utilizzano un Custom Gateway sul percorso GRE invece della semplice route GRE e lo selezionano in una route SD-WAN. È una soluzione adatta quando Source, Service, failover o uno stato definito del gateway devono influire sulla decisione di routing.

L’IP remoto del tunnel è il next hop. Health Check, Zone e Probe Target devono corrispondere al progetto specifico del provider; il monitoraggio disattivato in una guida del produttore non è uno standard universale. Creare e verificare un Custom Gateway su Sophos Firewall spiega come collegare oggetto, probe e test del traffico reale. La selezione del percorso è descritta in Configurare una route SD-WAN su Sophos Firewall.

Non attivare senza controllo una route GRE e una route SD-WAN per le stesse reti. Prima del passaggio, documentare quale meccanismo deve prevalere e come tornare al percorso precedente.

Creare regole firewall senza NAT non necessario

Il tunnel GRE e la sua route non consentono ancora il traffico applicativo. Una connessione HTTPS avviata dalla sede A richiede una regola restrittiva e con logging su entrambi i firewall.

Sul firewall A:

• Source zone: LAN
• Source network: 10.10.10.0/24
• Destination zone: VPN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: attivato

Sul firewall B consentire il traffico in ingresso dal tunnel verso il server di test:

• Source zone: VPN
• Source network: 10.10.10.0/24
• Destination zone: LAN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: attivato

Queste due regole coprono la connessione avviata dalla sede A e il relativo traffico di ritorno stateful. Se gli host della sede B possono avviare nuove connessioni verso la sede A, creare inoltre la coppia di regole speculare da LAN a VPN sul firewall B e da VPN a LAN sul firewall A, utilizzando solo le reti e i servizi realmente necessari. Per la convalida non serve una regola Any estesa.

In un normale collegamento tra sedi, mantenere l’IP sorgente originale. Non attivare MASQ come apparente correzione del routing. Se manca il percorso di ritorno, correggere la route sul peer. Creare e verificare in sicurezza le regole di Sophos Firewall spiega la struttura generale delle regole.

Convalidare insieme il tunnel e il traffico applicativo

La verifica segue il percorso dei pacchetti e distingue la configurazione dal funzionamento reale:

1. Eseguire system gre tunnel show su entrambi i firewall e confrontare endpoint e IP del tunnel.

2. Utilizzare system gre route show per verificare la LAN remota corrispondente e il nome corretto del tunnel.

3. Da un client in 10.10.10.0/24, avviare una nuova connessione HTTPS verso 10.20.20.10.

4. In Log viewer su entrambi i firewall, verificare Source, Destination, Service, Firewall Rule ID, NAT Rule ID e Zone.

5. In Diagnostics > Packet capture nella sede A, filtrare il percorso GRE esterno:

   host 198.51.100.20 and ip proto 47
   

6. Filtrare separatamente il flusso di test interno:

   host 10.20.20.10 and tcp port 443
   

7. Confrontare ingresso e uscita su entrambi i firewall e verificare l’IP sorgente reale sul server di destinazione.

8. Eseguire un test di ritorno solo con un servizio consentito a tale scopo.

La cattura esterna mostra l’incapsulamento tra gli endpoint WAN. La cattura interna e la Rule ID mostrano se il pacchetto utile segue la regola e la route previste. Solo il corretto funzionamento dell’applicazione conferma l’intero percorso. La procedura combinata è descritta più in dettaglio in Testare le regole firewall e Utilizzare Packet Capture.

Individuare gli errori in base al sintomo

Nessun pacchetto GRE lascia l’interfaccia WAN

• Controllare Remote Gateway e il local-gw locale nel tunnel.
• Controllare la route underlay verso l’indirizzo WAN remoto e il gateway WAN selezionato.
• Assicurarsi che il flusso di test corrisponda effettivamente alla route GRE o alla route SD-WAN prevista.
• Confrontare nomi e associazioni con system gre tunnel show e system gre route show.
• Non creare una regola per una porta TCP o UDP in sostituzione del protocollo IP 47.

GRE lascia la sede A ma non raggiunge la sede B

• Verificare il protocollo IP 47 presso provider, router a monte, ACL cloud e possibili percorsi NAT.
• Eseguire contemporaneamente una cattura nella sede B con il filtro WAN esterno.
• Confrontare gli indirizzi sorgente e destinazione esterni con la configurazione del peer.
• In presenza di WAN dinamica, CGNAT o configurazione NAT non chiarita, fermarsi invece di nascondere il problema con regole estese.

GRE è visibile su entrambi i lati WAN, ma manca il traffico interno

• Local IP e Remote IP devono essere invertiti in modo speculare sui due firewall.
• Confrontare carattere per carattere la route GRE, la rete di destinazione e il nome del tunnel.
• Controllare la regola firewall e la Rule ID prevista su entrambi i lati.
• Escludere reti sovrapposte, NAT e un percorso di ritorno mancante.
• Non considerare Enabled una prova della route interna o dell’applicazione.

Funziona una sola direzione

• Controllare la route GRE per la rete di ritorno nella sede B.
• Stabilire se la sede B deve avviare nuove connessioni e necessita quindi di una propria regola firewall.
• Controllare il gateway predefinito, il firewall host locale e l’IP sorgente reale sul server di destinazione.
• Confrontare eventuali route SD-WAN o statiche asimmetriche sui due lati.

I pacchetti piccoli funzionano, ma le connessioni di grandi dimensioni si bloccano

GRE aggiunge un header IP esterno e un header GRE. Ciò riduce la dimensione utile dei pacchetti rispetto all’underlay. Non adottare un valore fisso di MTU o MSS senza verificarlo: misurare prima MTU dell’underlay, Path MTU Discovery, frammentazione e applicazione interessata. Verificare MTU e MSS nei problemi VPN spiega la procedura controllata.

Testare HA e l’operatività con cautela

La documentazione pubblica Sophos attuale non promette un failover HA senza interruzioni né uno stato del tunnel GRE sincronizzato. Un cambio di ruolo controllato viene quindi eseguito solo in una finestra di manutenzione con accesso di gestione indipendente.

Dopo il cambio, verificare nuovamente system gre tunnel show, system gre route show, la cattura GRE esterna, una nuova connessione client, la Rule ID e il percorso di ritorno. Una connessione TCP esistente non dimostra la continuità.

Per l’operatività, documentare il responsabile, entrambi gli endpoint WAN, gli IP e i nomi del tunnel, le reti remote, il meccanismo di routing, le regole firewall, il limite MTU previsto e l’ultimo test del traffico reale. Dopo modifiche a WAN, provider, NAT, SD-WAN, Route Precedence o peer, convalidare nuovamente l’intero percorso.

Eseguire un rollback sicuro

Coordinare il rollback su entrambi i firewall:

1. Arrestare il traffico di test e registrare l’ultimo stato con system gre tunnel show e system gre route show.

2. Disattivare le nuove regole firewall e qualsiasi route SD-WAN creata per il test.

3. Se utilizzato, rimuovere il Custom Gateway dal percorso solo dopo aver controllato Object usage.

4. Nella sede A, eliminare la route GRE specifica:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. Nella sede B, eliminare la route di ritorno:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Utilizzare system gre route show per verificare che siano scomparse solo le voci previste.

7. Eliminare quindi il tunnel nella sede A tramite il nome esatto:

   system gre tunnel del name gre_branch
   

8. Nella sede B, eliminare solo il tunnel configurato su quel dispositivo:

   system gre tunnel del name gre_hq
   

9. Concludere con system gre tunnel show e un test del percorso di routing precedente.

Non utilizzare del All. Se la sintassi o il nome di un oggetto non sono chiari sul build installato, verificarli con Tab o ? prima dell’eliminazione, senza procedere per tentativi.

Domande frequenti