Configurare IPsec Site-to-Site con certificati su Sophos Firewall
Una preshared key condivisa si configura rapidamente per un singolo tunnel tra sedi. Con più firewall o requisiti PKI più rigidi, un digital certificate è spesso più semplice da controllare: ogni lato dispone della propria chiave privata, i peer considerano attendibili le CA emittenti e un singolo certificato può essere rinnovato o revocato in modo mirato.
Questa procedura mostra una connessione IPsec policy-based tra due Sophos Firewall. Completa la guida generale per configurare una VPN IPsec Site-to-Site. I design route-based richiedono anche la pianificazione del routing e di XFRM, ma la procedura di fiducia e certificati descritta qui rimane invariata.
La procedura sicura in otto passaggi
- Documentare i ruoli del tunnel, le reti, il profilo IKEv2 e i Certificate ID.
- Verificare su entrambi i firewall la disponibilità di un backup della configurazione e di un accesso amministrativo funzionante.
- Esportare la CA emittente di ciascun firewall e importarla sul peer.
- Generare su ogni firewall un certificato distinto firmato localmente con un Certificate ID univoco.
- Esportare solo il certificato pubblico e importarlo sul peer come Remote Certificate.
- Creare IPsec policy-based con Authentication type > Digital certificate su entrambi i lati.
- Verificare in modo restrittivo Device Access e le regole firewall generate automaticamente.
- Convalidare lo stato del tunnel, l’attendibilità dei certificati, i log e il traffico reale in entrambe le direzioni.
⚠️ Il file della chiave privata rimane sul firewall sul quale è stato generato il certificato. Per lo scambio della fiducia vengono trasferiti solo i certificati delle CA e i certificati pubblici dei peer. Senza un secondo accesso amministrativo testato, un backup e un percorso di ripristino documentato, non disattivare i tunnel PSK esistenti né sostituire i certificati di produzione.
Esempio e valori di pianificazione
L’esempio collega la sede centrale SF1 alla filiale SF2:
SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN
- WAN di SF1:
172.10.10.1 - WAN di SF2:
172.20.20.1 - Certificato di SF1:
SF1_Certificate - Certificato di SF2:
SF2_Certificate - Certificate ID di SF1:
172.10.10.1 - Certificate ID di SF2:
172.20.20.1
Questi indirizzi e nomi sono valori di documentazione. Nell’ambiente reale vanno utilizzati gli indirizzi WAN effettivi, gli oggetti di rete e uno schema di ID univoco per l’intera organizzazione. Il Certificate ID deve rimanere associato al rispettivo peer e non deve essere confuso con il nome visualizzato o con un SAN arbitrario.
Stabilire la fiducia reciproca delle CA
Per prima cosa, su SF1, controllare e scaricare la CA emittente in Certificates > Certificate authorities. Se l’esempio utilizza la CA locale Default, assegnare al file esportato un nome univoco come Head_Office_Default.pem. Su SF2, importarlo in Certificates > Certificate authorities > Add, ad esempio con il nome SF1_CA.
Ripetere quindi la procedura nella direzione opposta: esportare la CA da SF2, assegnarle un nome univoco come Branch_Office_Default.pem e importarla su SF1, ad esempio con il nome SF2_CA.
I nomi dei file servono solo per l’amministrazione. Sono determinanti Subject, Issuer, Fingerprint, validità e la corretta catena della CA. Prima dell’importazione confrontare questi valori tramite un canale indipendente. Gestire i certificati su Sophos Firewall spiega le attività generali relative a CA, certificati e assegnazione ai servizi.
Non rigenerare incidentalmente la CA integrata
Default. La rigenerazione modifica il Trust Anchor e può interessare altri portali, servizi TLS e peer IPsec. Per una CA aziendale, importare invece la sua intera catena attendibile.
Preparare i certificati locali e remoti
Creare il certificato locale su SF1
Su SF1, creare un certificato in Certificates > Certificates > Add > Generate locally-signed certificate. L’esempio Sophos utilizza RSA, una Key length di 2048 e SHA-256. Questi valori non sostituiscono la policy di crittografia e validità dell’organizzazione; il profilo IPsec scelto ed entrambi i peer devono supportarli.
In Subject Alternative Names (SANs) > Advanced settings, selezionare un Certificate ID. I tipi supportati sono DNS, IP address, Email e DER ASN1 DN [X.509]. L’esempio utilizza IP address con 172.10.10.1.
Con DER ASN1 DN [X.509], Sophos usa il Subject della CA emittente. In questo caso lasciare vuoti DNS names e IP address nei SAN, perché secondo Sophos valori aggiuntivi causano un conflitto durante l’autenticazione IPsec.
Dopo Save, controllare validità, Issuer, Certificate ID e presenza della chiave privata. Esportare il certificato pubblico, modificare se necessario l’estensione in .cer e importarlo su SF2 in Certificates > Certificates > Add > Upload certificate con il nome SF1_Certificate. La colonna Trusted sul peer deve confermare la fiducia tramite SF1_CA.
Creare il certificato locale su SF2
Ripetere la procedura su SF2 con una chiave privata distinta. Nell’esempio, il certificato si chiama SF2_Certificate, il Certificate ID è 172.20.20.1 e la CA emittente è la CA locale di SF2.
Importare il certificato pubblico su SF1. Qui Trusted deve essere confermato tramite la CA SF2_CA importata in precedenza. Ogni firewall ha ora esattamente due ruoli diversi:
- Local certificate: il proprio certificato con la chiave privata.
- Remote certificate: il certificato pubblico del peer, convalidato dalla relativa CA.
Un segno di spunta verde per l’attendibilità conferma la catena del certificato, ma non il funzionamento del tunnel. Validità, Certificate ID, profilo IKE, gateway e reti devono comunque corrispondere. La revoca e la distribuzione delle CRL sono un processo operativo separato; vedere Certificate Revocation Lists su Sophos Firewall.
Creare la connessione IPsec su entrambi i lati
In Site-to-site VPN > IPsec > Add, creare due connessioni corrispondenti. Nell’esempio, la sede centrale attende la filiale:
- Connection type:
Policy-based - Gateway type:
Respond only - Profile:
Head office (IKEv2)oppure un clone di profilo personalizzato coordinato - Authentication type:
Digital certificate - Local certificate:
SF1_Certificate - Remote certificate:
SF2_Certificate - Listening interface: WAN di
SF1 - Local subnet:
SF1_LAN - Gateway address: indirizzo WAN di
SF2 - Remote subnet:
SF2_LAN
Invertire i ruoli nella filiale:
- Gateway type:
Initiate the connection - Profile:
Branch office (IKEv2)oppure il profilo personalizzato corrispondente - Local certificate:
SF2_Certificate - Remote certificate:
SF1_Certificate - Local subnet:
SF2_LAN - Gateway address: indirizzo WAN di
SF1 - Remote subnet:
SF1_LAN
Pianificare i profili come coppia. Comprendere i profili IPsec su Sophos Firewall spiega come interagiscono IKEv2, fase 1, fase 2, PFS, lifetime e DPD.
Controllare Device Access e le regole firewall
Il lato con Gateway type > Respond only deve poter accettare connessioni IPsec sul percorso WAN previsto. In Administration > Device access, attivare quindi IPsec solo per la zona WAN effettivamente necessaria oppure usare un’eccezione Local Service ACL limitata agli indirizzi noti dei peer. SSO, certificati o un algoritmo IPsec robusto non giustificano un accesso WebAdmin o SSH esteso. Configurare Device Access in modo sicuro su Sophos Firewall spiega la pianificazione delle ACL.
Quando Create firewall rule è attivato, SFOS crea regole VPN automatiche. Queste regole costituiscono un punto di partenza. In Rules and policies > Firewall rules, controllare ordine, direzione, reti di origine e destinazione, servizi e logging, quindi limitarle alle necessità effettive. Creare regole firewall su Sophos Firewall spiega la verifica delle regole.
Ping/Ping6 per la zona VPN è necessario solo quando si intende usare un indirizzo del firewall stesso come destinazione del test. Non è necessario abilitare ampiamente questo servizio locale per un normale test end-to-end tra host dietro i firewall.
Convalidare il tunnel e i certificati
La convalida distingue quattro livelli:
- In Site-to-site VPN > IPsec, la connessione e il tunnel sono attivi.
- Entrambi i firewall mostrano i Local e Remote Certificate previsti, validità corrette e un Issuer attendibile.
- Un host di test reale raggiunge il servizio previsto nella rete remota, quindi viene verificata la direzione opposta.
- Firewall Rule ID, Packet Capture e log IPsec confermano lo stesso percorso e gli stessi timestamp.
strongswan.log è il principale punto di partenza per gli errori IKE e dei certificati. charon.log, ipsec_monitor.log e il log specifico della connessione in /log/ipsec_conn/ forniscono ulteriori elementi. Troubleshooting IPsec su Sophos Firewall descrive l’intera procedura diagnostica.
Circoscrivere gli errori in base al sintomo
Il tunnel rimane down
Verificare innanzitutto che Local certificate e Remote certificate siano realmente invertiti sui due lati. Controllare poi Certificate ID, Gateway address, profilo IKEv2, validità e catena di fiducia. Un certificato del peer importato senza la CA corrispondente non costituisce un’identità attendibile.
Il certificato è Trusted, ma l’autenticazione continua a non riuscire
Trusted conferma solo la catena. Con DER ASN1 DN [X.509], nessun valore SAN DNS o IP aggiuntivo deve sovrascrivere l’identificatore. Con gli altri tipi di ID, valore, tipo e peer atteso devono corrispondere esattamente. Confrontare in strongswan.log gli ID effettivamente presentati e attesi per lo stesso tentativo di connessione.
Il tunnel è verde, ma il traffico non passa
L’autenticazione tramite certificato è già riuscita. Controllare ora subnet locali e remote, regole VPN automatiche, Rule ID, NAT, route di ritorno e il reale servizio di destinazione. Rigenerare i certificati senza riscontri nasconderebbe soltanto lo stato originale in questo scenario.
Il certificato sta per scadere
Preparare in parallelo il nuovo certificato locale, trasferirne la parte pubblica al peer e confermarne l’attendibilità. Modificare Local certificate e Remote certificate su entrambi i lati in modo controllato solo durante una finestra di manutenzione. Conservare i vecchi certificati e le CA fino al completamento della convalida bidirezionale, quindi rimuoverli o revocarli.
Rollback e funzionamento
Prima della modifica, documentare entrambe le connessioni IPsec, i nomi dei certificati, i Fingerprint, i Certificate ID, i periodi di validità e l’ordine attuale delle regole. Un backup della configurazione di Sophos Firewall fa parte della preparazione, ma non sostituisce l’accesso diretto di ripristino al firewall.
Se la convalida non riesce, ripristinare le assegnazioni dei certificati usate in precedenza oppure riattivare il tunnel PSK ancora disponibile. Eliminare i certificati dei peer o le CA appena importati solo dopo aver verificato che nessun’altra connessione o servizio li utilizzi. Controllare quindi nuovamente lo stato del tunnel e un flusso di test reale.
Durante il funzionamento, i certificati richiedono un responsabile, il monitoraggio della scadenza e una finestra di rinnovo pianificata. Il primo avviso deve lasciare tempo sufficiente per emissione, distribuzione della fiducia, test in parallelo e rollback. Sostituire un certificato solo il giorno della scadenza trasforma una manutenzione pianificata in un’interruzione VPN.