Configurare Site-to-Site RED tra due Sophos Firewall

Un tunnel Site-to-Site RED collega direttamente due Sophos Firewall senza installare un’appliance SD-RED in nessuna delle due sedi. Una firewall opera come Firewall RED server e accetta la connessione. L’altra opera come Firewall RED client e stabilisce il tunnel verso il server.

Questo flusso attuale di SFOS 22 non va confuso con una modalità operativa RED come Standard/Unified o Standard/Split. Tali modalità riguardano un dispositivo SD-RED fisico. Un’architettura firewall-to-firewall utilizza invece interfacce RED, route statiche e regole firewall corrispondenti su entrambe le firewall.

⚠️ Prima della modifica servono un backup aggiornato di entrambe le firewall, un accesso amministrativo indipendente e un percorso di ripristino documentato. Se possibile, l’indirizzo pubblico del Firewall RED server non dovrebbe essere tradotto tramite NAT, perché la traduzione può interferire con le connessioni RED in ingresso.

Il processo in otto passaggi

1. Pianificare ruoli, IP RED, reti delle sedi e indirizzo raggiungibile del server.
2. Attivare il RED provisioning service su entrambe le firewall e consentire il percorso di controllo RED.
3. Creare nella sede centrale l’interfaccia Firewall RED server.
4. Trasferire in modo sicuro alla controparte il file di provisioning generato.
5. Creare nella filiale l’interfaccia Firewall RED client e importare il file.
6. Aggiungere su entrambi i lati una route statica verso la LAN remota, usando l’IP RED del peer come gateway e senza selezionare un’interfaccia.
7. Consentire il traffico dati su entrambe le firewall con regole ristrette e registrate; non creare una regola NAT collegata.
8. Verificare separatamente tunnel, route, corrispondenza delle regole e traffico bidirezionale reale.

Un’interfaccia RED verde conferma soltanto che il tunnel è stato stabilito. Non dimostra che routing, regole firewall e percorso di ritorno funzionino.

Pianificazione e design

Quando Site-to-Site RED è adatto

Site-to-Site RED è un modo semplice per collegare due Sophos Firewall. Il provisioning RED gestisce una parte della negoziazione VPN classica, mentre le LAN remote continuano a utilizzare routing e regole firewall normali.

Per i nuovi progetti occorre comunque scegliere consapevolmente tra RED e Site-to-Site IPsec. IPsec offre più opzioni per profili, routing, interoperabilità e ridondanza. Site-to-Site RED è interessante quando entrambe le estremità sono Sophos Firewall e basta un semplice tunnel specifico di Sophos.

Un dispositivo SD-RED fisico viene configurato con Configurare e risolvere i problemi di Sophos SD-RED. Le modalità operative RED non si applicano al tunnel firewall-to-firewall descritto qui.

Pianificare la topologia di esempio

L’esempio seguente utilizza intenzionalmente indirizzi di documentazione. Vanno sostituiti integralmente con le reti e gli indirizzi reali delle due sedi:

• Sede centrale, ruolo Firewall RED server: indirizzo pubblico 198.51.100.10, LAN 10.10.0.0/16
• Filiale, ruolo Firewall RED client: indirizzo pubblico 203.0.113.20, LAN 10.20.0.0/16
• IP RED della sede centrale: 10.255.100.1
• IP RED della filiale: 10.255.100.2

I due IP RED formano la coppia di indirizzi tra le firewall. Non devono entrare in conflitto con una LAN di sede né con un’altra rete di interfaccia o VPN. La firewall client deve poter raggiungere in modo affidabile l’indirizzo IP pubblico o il FQDN del server.

L’esempio usa 255.255.255.252 (/30) come RED netmask. Questa piccola rete di transito contiene esattamente la coppia necessaria. Se si sceglie un’altra rete libera, occorre sostituire coerentemente entrambi gli IP RED e la netmask. RED non risolve LAN sovrapposte: il piano di indirizzamento o NAT va definito prima del tunnel.

Sophos descrive esplicitamente le interfacce RED come tunnel sicuri e cifrati. Durante la registrazione del RED provisioning service, SFOS usa i dati di registrazione per generare un certificato destinato alla comunicazione RED sicura. Nel flusso firewall-to-firewall documentato, quindi, nell’interfaccia non si selezionano manualmente PSK o certificati: il server genera un Provisioning file con i dati di configurazione del client. Il file deve essere trasferito esclusivamente tramite un canale protetto.

Configurare il tunnel e il percorso dati

Creare il Firewall RED server

Per prima cosa si crea il server sulla firewall con un indirizzo pubblico stabilmente raggiungibile:

1. In System services > RED, attivare il RED provisioning service.
2. Aprire Network > Interfaces.
3. Selezionare Add interface > Add RED.
4. In Branch name, inserire ad esempio RED-HQ-Branch.
5. Impostare Type su Firewall RED server.
6. Lasciare Tunnel ID su Automatic.
7. Inserire 10.255.100.1 come RED IP.
8. Inserire 255.255.255.252 come RED netmask.
9. Assegnare una zona scelta consapevolmente, nell’esempio RED-S2S.
10. Lasciare inizialmente invariati Tunnel compression e MTU, quindi salvare.
11. In Network > Interfaces, scegliere Download provisioning file dal menu della nuova interfaccia.

Il file di provisioning appartiene a questo tunnel e va trattato come un elemento di configurazione sensibile. Viene trasferito alla filiale tramite un canale protetto e, dopo l’importazione, non deve rimanere in una cartella di download o condivisa accessibile a tutti.

La zona influenzerà in seguito le corrispondenze delle regole e di Device Access. È possibile usare LAN, ma in presenza di più sedi una zona dedicata crea in genere un confine di sicurezza più chiaro. Configurare zone e interfacce su Sophos Firewall spiega le relazioni generali.

Automatic evita il riutilizzo accidentale di una Tunnel ID. Se deve essere impostata manualmente, Sophos richiede che non sia già in uso su nessuno dei due dispositivi. Nel flusso client documentato non si inserisce una seconda Tunnel ID: l’associazione proviene dal file di provisioning del server. Tunnel compression può aumentare il throughput su collegamenti lenti, ma usa risorse: modificarla solo dopo misure prima/dopo riproducibili. La MTU dell’interfaccia RED influisce sulla frammentazione; un problema di MTU o frammentazione può quindi bloccare i flussi con pacchetti più grandi anche se il tunnel è attivo. Una MTU minore va testata solo in presenza di frammentazione o problemi Path MTU dimostrati.

Creare il Firewall RED client

Nella sede remota si crea il client con il file generato dal server:

1. Anche qui, in System services > RED, attivare il RED provisioning service.
2. Creare una nuova interfaccia in Network > Interfaces > Add interface > Add RED.
3. Usare un Branch name come RED-Branch-HQ.
4. Impostare Type su Firewall RED client.
5. In Firewall IP/hostname, inserire l’indirizzo pubblico o il FQDN del server.
6. In Provisioning file, selezionare il file della firewall server.
7. Inserire 10.255.100.2 come RED IP.
8. Inserire la stessa RED netmask 255.255.255.252.
9. Assegnare la zona RED-S2S, lasciare invariati Tunnel compression e MTU, quindi salvare.

Se il client può raggiungere il server solo tramite un indirizzo tradotto o variabile, DNS, NAT a monte e percorso di ritorno richiedono test particolarmente accurati. Sophos consiglia, ove possibile, di rendere il server direttamente raggiungibile senza NAT.

Il client avvia la connessione in uscita, quindi la filiale non necessita di una pubblicazione in ingresso equivalente.

Aggiungere route statiche senza interfaccia

Dopo l’attivazione, il tunnel non conosce automaticamente le reti LAN dietro le firewall. Si crea una route unicast IPv4 su entrambi i lati:

• Sede centrale: destinazione 10.20.0.0/16, gateway 10.255.100.2
• Filiale: destinazione 10.10.0.0/16, gateway 10.255.100.1

L’eccezione RED determinante è che per queste due route non viene selezionata alcuna interfaccia. La firewall invia richieste ARP per individuare l’interfaccia RED raggiungibile per l’indirizzo del peer. Selezionare successivamente un’interfaccia può interferire con questo meccanismo e non rappresenta un miglioramento.

La route viene creata in Routing > Static routes > IPv4 unicast route > Add. Administrative Distance e Metric vengono scelti consapevolmente in base al resto dell’architettura di routing. Configurare e testare una route statica su Sophos Firewall spiega la logica generale dei campi e la verifica con Route Lookup.

Limitare il servizio RED e le regole firewall

Prima consentire al servizio RED locale di accettare la connessione. In Administration > Device access, attivare RED solo per la zona di arrivo effettiva. Se gli indirizzi pubblici sorgente sono stabili, creare invece in Local service ACL exception rule > Add una regola Accept ristretta con Source zone, Source Network / Host, interfaccia WAN come Destination host e Services: RED. Le regole firewall normali non controllano i servizi locali. Device Access e Local Service ACL spiega questa distinzione.

Il traffico inoltrato richiede poi regole in Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule. Per un flusso avviato dalla centrale: centrale con Source zones LAN, sorgente 10.10.0.0/16, Destination zones RED-S2S, destinazione 10.20.0.0/16; filiale con Source zones RED-S2S, sorgente 10.10.0.0/16, Destination zones LAN, destinazione 10.20.0.0/16. Limitare Services alle necessità reali.

Per connessioni avviate dalla filiale, aggiungere la coppia con reti e zone invertite. Attivare Log firewall traffic, verificare la posizione e lasciare Create linked NAT rule disattivato. Il collegamento instradato deve conservare gli indirizzi reali e il percorso di ritorno; non sovrascrivere eccezioni NAT intenzionali senza revisione. Comprendere e configurare le regole Sophos Firewall approfondisce la logica.

Verifica, troubleshooting e rollback

Verificare il tunnel in modo controllato

La verifica inizia con un singolo flusso di test di cui viene registrato l’orario esatto. Prima si controlla che entrambe le interfacce RED siano attive e che Route Lookup mostri il percorso previsto per un indirizzo nella LAN remota. Quindi il flusso deve corrispondere alla Rule ID prevista su entrambe le firewall.

Un Packet Capture su Sophos Firewall mostra se il pacchetto entra nell’interfaccia RED dal lato di origine, arriva al peer e viene inoltrato alla LAN di destinazione. Il percorso di ritorno viene testato separatamente. Un ping da solo non basta se l’applicazione di produzione utilizza TCP o UDP su porte diverse.

Il successo significa quindi che tutti questi punti sono soddisfatti contemporaneamente:

• Le interfacce RED sono attive su entrambi i lati.
• Route Lookup mostra il percorso pianificato in entrambe le direzioni.
• La regola firewall prevista corrisponde su entrambe le firewall.
• Un flusso applicativo reale funziona in entrambe le direzioni.
• Gli indirizzi di origine e destinazione compaiono senza NAT indesiderato.
• Dopo un riavvio controllato, un nuovo flusso viene ristabilito; un cluster HA richiede inoltre un test di failover separato.

Per HA, Sophos documenta un ritardo nella riconnessione dei tunnel RED all’Auxiliary Firewall dopo il failover. Dipende dal numero di interfacce e da altre impostazioni e riguarda anche Site-to-Site RED. Non va promessa una ripresa immediata: registrare ora del failover, stato dell’interfaccia e tempo di riconnessione, poi ripetere il test applicativo.

Circoscrivere gli errori in modo sistematico

Il client non stabilisce il tunnel: controllare RED provisioning service, indirizzo del server, DNS, raggiungibilità, Device Access e il file di provisioning appartenente al tunnel. Non combinare alla cieca un nuovo file con una vecchia configurazione client.

Il file di provisioning viene rifiutato: verificare che provenga dall’interfaccia server attuale e non sia stato alterato. Conservare prima lo stato iniziale; se necessario scaricare un nuovo file e ricreare il client in una finestra di manutenzione.

Il tunnel è attivo, ma la LAN remota non è raggiungibile: controllare su entrambi i lati la rete di destinazione e l’IP RED del peer della route statica. Per questa speciale route RED non deve essere selezionata alcuna interfaccia. Quindi verificare la corrispondenza della regola e la route di ritorno.

Funziona una sola direzione: in genere manca una regola o route adeguata su una firewall, oppure una rete della sede è già raggiunta tramite un percorso più specifico o con priorità maggiore. Route Lookup, Packet Capture e traffico di ritorno reale devono essere coerenti.

La connessione è instabile: correlare latenza, perdita di pacchetti, raggiungibilità pubblica del server, NAT davanti al server e modifiche del percorso WAN. Salvare i log locali del nodo per l’ora esatta del test. Trovare e analizzare i log di servizio di Sophos Firewall spiega i file di log e i percorsi di supporto.

Il tunnel è attivo, ma i flussi con pacchetti più grandi si bloccano: nel Packet Capture, esaminare entrambe le direzioni per individuare frammentazione e messaggi ICMP Path MTU. Confrontare i valori MTU delle due interfacce RED e provare diverse dimensioni dei pacchetti. Solo con queste evidenze testare gradualmente la stessa MTU su entrambe le interfacce. Non modificare insieme compression e MTU.

Nessuna regola Any ampia, autorizzazione WAN generale, riavvio di servizi o modifica casuale di IP RED e route sostituisce questa correlazione. Se l’errore resta poco chiaro nonostante un’architettura corretta, si raccolgono per Sophos Support backup, build SFOS, timestamp, stato delle interfacce, route, Rule IDs, Packet Capture e log pertinenti.

Eseguire un rollback sicuro

Se il pilota fallisce, disattivare prima le regole aggiunte e rimuovere le route, poi l’interfaccia client e infine quella server. Ripristinare Device Access/Local Service ACL e i valori MTU o compression; eliminare i nuovi oggetti host/rete solo se non usati altrove.

Un percorso di gestione esistente che utilizza proprio questo tunnel non viene rimosso finché non è stato testato con successo un accesso alternativo. Dopo il rollback si verificano nuovamente il routing normale, le regole precedenti e la raggiungibilità di entrambe le firewall.

FAQ