Un Site-to-Site VPN è un tunnel cifrato fra due Security Gateway, tipicamente in sedi geografiche diverse. Lo reggono due protocolli: IKE negozia e rinnova le chiavi, IPsec cifra e autentica i pacchetti.

IKE lavora in due fasi. Nella fase 1 i peer si autenticano — con certificati o con un pre-shared secret — e derivano una chiave Diffie-Hellman: il risultato è la IKE SA, l’accordo su chiavi e metodi per la fase successiva. Nella fase 2, protetta dalla fase 1, si negoziano le chiavi del traffico vero e proprio: ne esce la IPsec SA. Le fasi hanno impostazioni separate, e in ciascuna i peer devono concordare lo stesso algoritmo di cifratura, lo stesso algoritmo di integrità e lo stesso gruppo Diffie-Hellman.

In R82 le due fasi offrono gli stessi algoritmi: AES-128, AES-256 e le varianti AES-GCM per la cifratura, da SHA1 (default) a SHA-512 e AES-XCBC per l’integrità. DES, 3DES, CAST e MD5 restano solo per retrocompatibilità e sono dichiarati non raccomandati. I gruppi Diffie-Hellman vanno da 1 a 21, con default Group 15 a 3072 bit; i gruppi 1, 2 e 5 sono anch’essi legacy. La Perfect Forward Secrecy, se attiva, genera una chiave DH nuova nella fase 2 a ogni scambio. I tempi di rinegoziazione differiscono: la fase 1 si rinnova per default una volta al giorno, la fase 2 ogni ora. IKEv1 ha Main Mode (sei pacchetti, default) e Aggressive Mode (tre pacchetti, per apparati di terze parti); IKEv2 è supportato nelle community in modalità Simplified e gestisce da solo IPv6, tanto che la scelta della versione riguarda solo IPv4.

La VPN Community: chi parla con chi

Una VPN Community è una collezione di VPN domain, ciascuno protetto da un VPN gateway: è l’oggetto che decide quali gateway si parlano e con quali impostazioni di cifratura e di tunnel. In una community Meshed ogni membro costruisce un tunnel con tutti gli altri. In una Star uno o più gateway fanno da center e gli altri da satellite: i satellite parlano con il center, e fra loro solo passando per il center; i center possono essere in mesh fra loro.

Il VPN domain, o encryption domain, è l’insieme delle reti che un gateway protegge e per cui cifra e decifra. Si ricava automaticamente dalla topologia del gateway oppure si definisce a mano con un gruppo di reti. È il dato che dice al gateway quali pacchetti devono entrare nel tunnel: sbagliarlo non produce un errore di configurazione, produce traffico instradato male.

Il percorso minimo è sempre lo stesso: abilitare il blade IPsec VPN sui gateway, creare la community e aggiungere i membri, scrivere le regole di Access Control fra i VPN domain, installare la policy e verificare nei log che compaiano encrypt, decrypt e l’installazione delle chiavi.

Instradare il traffico e tenere su i tunnel

Il domain-based VPN usa i VPN domain per decidere il percorso del traffico cifrato, e funziona solo fra gateway della stessa community. In una Star si sceglie fra «To center and to other Satellites through center», adatta quando i satellite hanno indirizzo dinamico, e l’opzione che aggiunge «to internet and other VPN targets», con cui anche il traffico verso Internet passa dal center. In entrambi i casi servono regole che ammettano il traffico nelle due direzioni sul center e l’opzione Accept all encrypted traffic.

I Permanent Tunnels tengono il tunnel attivo in permanenza perché se ne possa monitorare lo stato, e si configurano sull’intera community, su singoli gateway o su singole coppie. Il keep-alive di default è il tunnel test, protocollo proprietario Check Point su UDP 18234, che vale solo fra gateway Check Point; con peer di terze parti si usa DPD, basato su IKEv1 e IKEv2. Il VPN Tunnel Sharing decide invece quante SA nascono: one tunnel per host pair, per subnet pair o per Security Gateway pair. Se l’impostazione della community e quella del gateway divergono, vince la più restrittiva.

Trappole tipiche d’esame

  • Algoritmi che non coincidono fra i peer. Primo errore dichiarato dal vendore, e la versione difficile è questa: la fase 1 si conclude e la fase 2 fallisce lo stesso, perché le proposte sono separate. Chiediti di quale fase parla la domanda: cifratura, hash e gruppo DH devono coincidere in entrambe. Un peer fermo a 3DES e MD5 non negozia con i default di R82.
  • VPN domain definiti male. Secondo errore dichiarato. Se una rete manca dal domain il traffico non entra nel tunnel; se compare in due domain l’instradamento diventa ambiguo. Con un gateway esterno il domain va dichiarato a mano: non si rileva da solo.
  • Esenzioni NAT mancanti. Terzo errore dichiarato. Il Hide NAT che serve per l’uscita a Internet colpisce anche il traffico diretto al peer: gli indirizzi sorgente arrivano tradotti, non corrispondono al VPN domain e il tunnel non li riconosce. Il traffico VPN va escluso dal NAT, e la guida avverte che farlo con una regola NAT dedicata degrada le prestazioni rispetto all’opzione dell’oggetto community.
  • Star che non instrada. Creare la community non basta: senza Accept all encrypted traffic e senza regole nelle due direzioni sul center, due satellite continuano a non vedersi.