Vai al contenuto
Avanet

Configurare una VPN SSL Site-to-Site su Sophos Firewall

Sophos Firewall

Una VPN SSL Site-to-Site collega le reti interne di due Sophos Firewall tramite un tunnel cifrato. A differenza di IPsec, entrambi i lati hanno un ruolo fisso: il firewall client avvia sempre la connessione, mentre il firewall server la accetta.

Questa soluzione è particolarmente adatta quando una filiale dispone di un indirizzo IP pubblico dinamico o quando IPsec incontra difficoltà in una rete a monte. La sede centrale con indirizzo statico o FQDN stabile assume il ruolo di server, mentre la filiale diventa il client. Per reti in crescita, routing dinamico, ridondanza o un peer di terze parti, IPsec route-based è generalmente più flessibile; per una piccola connessione tra due Sophos Firewall, SSL Site-to-Site può essere più semplice.

Questa guida utilizza un esempio concreto:

  • Sede centrale, server: vpn.example.com, rete locale 10.10.0.0/24
  • Filiale, client: IP pubblico dinamico, rete locale 10.20.0.0/24
  • Connessione: HQ-to-Branch
  • Porta SSL VPN: 8443

vpn.example.com, i nomi degli oggetti e le due reti sono segnaposto e devono essere sostituiti con i valori dell’ambiente reale. 8443 è la porta predefinita; va mantenuta solo se l’assegnazione delle porte e il design di sicurezza lo consentono.

La procedura rapida è la seguente: assegnare ruoli e reti, verificare le impostazioni globali SSL VPN, consentire SSL VPN nella zona WAN del server, creare la connessione server, esportare il file .apc, importarlo sul firewall client e infine verificare route, regole e traffico applicativo reale.

⚠️ Le impostazioni globali SSL VPN sono utilizzate anche da Remote Access SSL VPN. Non modificare porta, protocollo, certificato, intervallo di indirizzi o impostazioni crittografiche solo per questo tunnel. Prima valutare gli effetti sulle connessioni e sui profili utente esistenti.

Pianificare ruoli, reti e accesso pubblico

Il firewall server dovrebbe essere l’appliance più stabile e, se i modelli sono diversi, quella più potente. Se solo un lato dispone di un indirizzo IP pubblico statico, tale lato deve assumere il ruolo di server. Il client può trovarsi dietro NAT o utilizzare una connessione con indirizzo dinamico, purché riesca a raggiungere il server.

Prima della configurazione devono essere definiti i seguenti punti:

  • indirizzo IP pubblico o FQDN del firewall server;
  • protocollo e porta per SSL VPN;
  • rete locale della sede centrale e rete locale della filiale;
  • intervalli di indirizzi univoci e non sovrapposti;
  • servizi necessari e direzioni di connessione consentite;
  • percorso di ritorno su entrambi i lati;
  • accesso amministrativo alternativo per la modifica;
  • versioni SFOS aggiornate su entrambi i firewall.

Se le reti si sovrappongono, questa configurazione standard non è sufficiente. È quindi necessario un design consapevole di traduzione e routing; nella pratica, IPsec con NAT pianificato è generalmente più adatto.

Verificare la compatibilità prima della modifica

Da SFOS 20.0 MR1, Sophos utilizza un componente OpenVPN più recente. I tunnel SSL Site-to-Site da SFOS 20.0 MR1 o versioni successive non si connettono a SFOS 18.5 o versioni precedenti né a UTM 9. In una combinazione di questo tipo, occorre aggiornare entrambi i Sophos Firewall oppure utilizzare IPsec o un tunnel RED.

Verificare le impostazioni globali SSL VPN

Le impostazioni condivise si trovano sul futuro firewall server in:

Remote access VPN > SSL VPN > SSL VPN global settings

Per l’esempio, verificare in particolare i seguenti valori:

  • Protocol: UDP è generalmente la scelta iniziale più efficiente; TCP può essere utile nelle reti restrittive.
  • SSL server certificate: deve essere valido e importato con la chiave privata e la catena di certificati completa. Se si utilizza un FQDN pubblico, il certificato dovrebbe corrispondere a tale nome.
  • Override hostname: vpn.example.com se i client devono utilizzare esattamente questo FQDN.
  • Port: 8443, salvo che sia stato pianificato consapevolmente un design di porte diverso.
  • Assign IPv4 addresses: non deve sovrapporsi alle due reti delle sedi né ad altri pool VPN.
  • Cryptographic settings: non modificare i valori esistenti senza test di compatibilità e funzionamento.

Se il firewall server si trova dietro un router a monte, il router deve inoltrare al firewall la porta e il protocollo scelti. In questo caso il FQDN punta all’indirizzo pubblico del router. WAF e SSL VPN non devono utilizzare la stessa combinazione di IP WAN, porta e protocollo.

Se in seguito cambiano Port, Protocol, SSL server certificate o Override hostname, scaricare nuovamente la configurazione server e reimportarla sul firewall client. L’esportazione .apc esistente non contiene i nuovi valori.

SSL VPN Remote Access su Sophos Firewall descrive tutte le dipendenze delle impostazioni globali. Le modifiche devono essere pianificate considerando i profili utente esistenti, gli intervalli di indirizzi, DNS e i servizi accessibili pubblicamente.

Consentire SSL VPN per la zona WAN del server

Sul firewall server si consente il servizio SSL VPN locale per la zona in ingresso:

Administration > Device access

Se il firewall client ha un indirizzo pubblico dinamico o che non può essere limitato in modo utile, attivare SSL VPN per WAN in VPN services. Ciò consente solo l’instaurazione del tunnel verso il firewall; non sostituisce una regola firewall per il traffico applicativo tra le sedi.

Se le reti di origine pubbliche del lato client sono stabili e note, lasciare SSL VPN disattivato nella matrice WAN. Creare invece una Local Service ACL Exception mirata con azione Accept, Source zone WAN, le Source Networks/Hosts note, l’indirizzo WAN del server come Destination host e SSL VPN come Service. Un’eccezione Accept non restringe un’autorizzazione già attiva nella matrice WAN. Configurare Device Access in modo sicuro su Sophos Firewall descrive la pianificazione.

Creare la connessione server nella sede centrale

Creare innanzitutto entrambe le reti come oggetti IP host sul firewall server:

Hosts and services > IP host
  • HQ-LAN: 10.10.0.0/24
  • Branch-LAN: 10.20.0.0/24

Creare quindi la connessione server:

  1. Aprire Site-to-site VPN > SSL VPN.
  2. Nella sezione Server, selezionare Add.
  3. Inserire HQ-to-Branch come nome.
  4. In Local networks, selezionare HQ-LAN.
  5. In Remote networks, selezionare Branch-LAN.
  6. Attivare Use static virtual IP address solo in presenza di una necessità motivata e scegliere un indirizzo libero al di fuori degli intervalli SSL VPN statici e dinamici globali.
  7. Salvare con Save.

Dal punto di vista del firewall server, Local networks indica le reti della sede centrale. Remote networks indica le reti situate dietro il firewall client. Questa prospettiva è importante: se gli oggetti vengono scambiati, il tunnel può diventare verde anche se le route e le regole non corrispondono alla connessione desiderata.

Esportare la configurazione server in modo sicuro

Nell’elenco dei server, selezionare Download per HQ-to-Branch. L’esportazione utilizza il formato .apc e contiene i dati di connessione per il firewall client.

Per un trasferimento sicuro, attivare Encrypt configuration file e impostare una password temporanea robusta. Trasmettere file e password tramite canali separati. Il file .apc non deve essere inserito in un ticket pubblico, in una chat non protetta o in una directory di download permanente.

Importare la configurazione sul firewall client

Importare la configurazione sul firewall della filiale dallo stesso percorso di menu:

  1. Aprire Site-to-site VPN > SSL VPN.
  2. Nella sezione Client, selezionare Add.
  3. Inserire Branch-to-HQ come nome.
  4. In Configuration file, selezionare il file .apc esportato.
  5. Se l’esportazione è cifrata, inserire la password.
  6. Attivare Use HTTP proxy server solo se la filiale raggiunge effettivamente il server tramite un proxy HTTP esplicito.
  7. Impostare Override peer hostname solo se l’indirizzo del server contenuto nell’esportazione non è instradabile o risolvibile dalla rete client. Nell’esempio il campo rimane vuoto perché vpn.example.com è già esportato tramite l’impostazione globale.
  8. Salvare con Save e attivare la connessione.

Lo stato diventa verde quando il firewall client raggiunge il server e stabilisce il tunnel. Uno stato verde conferma solo il tunnel stesso, non l’accesso a server, DNS o applicazioni.

Verificare route e regole firewall

Le reti selezionate in Local networks e Remote networks vengono utilizzate per il routing del tunnel. Appartengono alla classe di routing static e devono essere coerenti con il resto della configurazione di routing. In caso contrario, una route statica, SD-WAN o VPN più specifica può produrre un percorso diverso da quello previsto. Comprendere e modificare la priorità di routing su Sophos Firewall descrive l’ordine.

Le regole firewall per il traffico applicativo devono essere create consapevolmente su entrambi i firewall oppure vanno verificate regole esistenti adeguate. Nell’esempio, in cui la filiale avvia le connessioni verso la sede centrale, è necessario almeno quanto segue:

  • sul firewall della filiale, una regola restrittiva da LAN a VPN per Branch-LAN verso le destinazioni necessarie in HQ-LAN;
  • sul firewall server, una regola corrispondente da VPN a LAN per Branch-LAN verso tali destinazioni;
  • solo i servizi necessari, ad esempio DNS, RDP e HTTPS;
  • Log firewall traffic durante i test di accettazione;
  • nessuna regola SNAT o MASQ che modifichi il traffico tra le sedi senza una valida ragione tecnica.

Se anche la sede centrale deve avviare nuove connessioni verso la filiale, consentire separatamente le direzioni inverse. Una regola Any ampia non rappresenta un design di sicurezza completo. Verificare una regola firewall descrive come interagiscono posizione della regola, Rule ID e Packet Capture.

Validare il tunnel e il traffico applicativo

Iniziare il test con un client specifico e una destinazione specifica. Nell’esempio, un dispositivo in 10.20.0.0/24 accede a un server consentito in 10.10.0.0/24.

  1. Su entrambi i firewall, verificare lo stato verde e l’aumento dei contatori di byte.
  2. Provare la destinazione prima tramite indirizzo IP e poi tramite hostname.
  3. Aprire un servizio effettivamente consentito, ad esempio HTTPS o RDP.
  4. In Log Viewer, verificare la Firewall Rule ID prevista e gli indirizzi di origine e destinazione invariati.
  5. Provare un servizio o una destinazione non consentiti e confermare il drop.
  6. Verificare separatamente la direzione inversa, se deve essere consentita.
  7. Dopo un riavvio o una modifica WAN, verificare che il firewall client ristabilisca il tunnel.

Un ping riuscito non è sufficiente. Non dimostra né il funzionamento del DNS né quello del servizio applicativo richiesto. Per una destinazione interna, la regola firewall, il percorso di ritorno e il firewall dell’endpoint devono consentire il test; Device Access è rilevante solo quando si esegue il ping di un indirizzo della Sophos Firewall stessa.

Leggere i log in caso di errore

Aprire direttamente i log SSL VPN in Site-to-site VPN > SSL VPN > Logs. Per un controllo più approfondito, collegarsi tramite SSH, selezionare 5. Device Management > 3. Advanced Shell e leggere il log di servizio corrente:

tail -n 200 /log/sslvpn.log

Il comando non modifica la configurazione. Documentare insieme ora, nome della connessione e lato server/client. In base al numero di processi, possono esistere ulteriori file di stato OpenVPN come openvpn-status0.log, openvpn-status1.log e altri file; i log di servizio di Sophos Firewall ne spiegano l’associazione.

Individuare gli errori comuni

  • Il tunnel rimane rosso: Verificare FQDN pubblico, DNS, port forwarding, protocollo, certificato e SSL VPN in Device Access per la zona WAN del server. Leggere quindi sslvpn.log per lo stesso orario.
  • Il tunnel non si attiva più dopo una modifica globale: Esportare nuovamente la configurazione server e reimportarla sul client. In particolare, porta, protocollo, certificato e Override hostname dipendono dall’esportazione.
  • Il tunnel è verde, ma non passa traffico: Verificare routing del tunnel, priorità di routing, regole su entrambi i firewall, Rule ID, percorso di ritorno, NAT e firewall dell’endpoint. Seguire quindi un singolo flusso con Packet Capture.
  • Non funzionano solo gli hostname: Provare l’accesso tramite IP, verificare i server DNS e il dominio di ricerca e assicurarsi che il server DNS sia raggiungibile e consentito attraverso il tunnel.
  • Un oggetto FQDN host punta ancora al vecchio indirizzo: FQDN hosts e groups sono supportati come reti locali e remote. Dopo una modifica DNS, disconnettere e riconnettere il tunnel in modo controllato, quindi verificare la route e il traffico applicativo verso il nuovo IP risolto. Una mancata risoluzione è innanzitutto un problema di traffico o routing, non automaticamente un problema di instaurazione del tunnel.
  • Il client raggiunge il server solo tramite un proxy: Utilizzare Use HTTP proxy server con i valori proxy approvati; non inserire valori proxy casuali come soluzione generica.
  • Un lato esegue SFOS 18.5 o UTM 9: Non continuare a cercare il problema nella porta o nel certificato. Questa combinazione è incompatibile con un peer attuale; aggiornare entrambi i lati oppure utilizzare IPsec o RED.

Se il tunnel rimane poco chiaro dopo un test controllato, raccogliere la versione e la build SFOS di entrambi i firewall, l’ora con il fuso orario, il nome della connessione, sslvpn.log, le Rule IDs e un breve Packet Capture. Solo in seguito devono essere modificate ulteriormente le regole, le reti o le impostazioni globali SSL VPN.