Quando un tunnel IPsec non sale, la diagnosi parte da una domanda sola: si è fermato in fase 1 o in fase 2? Le due fasi negoziano cose diverse, falliscono per motivi diversi e si leggono con comandi diversi. Tenerle separate, e sapere cosa deve combaciare fra i peer, è il nocciolo del dominio.

Fase 1: negoziare l’IKE SA

La fase 1 costruisce un canale protetto con una singola IKE SA bidirezionale, dentro cui negoziare poi i parametri della fase 2. Chi apre è l’initiator, chi risponde il responder.

La prima scelta è il tipo di Remote Gateway, e condiziona il resto: Static IP Address per un peer con indirizzo fisso, Dialup User per client dinamici, Dynamic DNS per un peer con nome a dominio. Mode Config, che assegna ai client indirizzo, DNS e split tunnel, esiste solo con Dialup User.

Poi la versione di IKE. Con IKEv2 non c’è la scelta fra main e aggressive, XAuth non è disponibile e si può usare EAP. Con IKEv1 la scelta c’è: aggressive scambia i parametri in un unico messaggio con l’autenticazione in chiaro, main li scambia in più passaggi con autenticazione cifrata. Main è preferibile, ma aggressive è obbligatorio in un caso da ricordare: peer con indirizzo dinamico autenticato con chiave precondivisa, quando sullo stesso indirizzo di interfaccia esiste più di una fase 1 dialup. È l’unico modo di distinguerli per ID.

NAT Traversal esiste perché ESP è il protocollo IP 50 e non ha porte: dietro un NAT i pacchetti non sono demultiplexabili. Abilitandolo, ESP viene incapsulato in UDP e acquista una porta sorgente. I due lati devono avere la stessa impostazione, e il keepalive va tenuto più corto della session lifetime del NAT. Il Dead Peer Detection ha tre modalità, disable, on-idle e on-demand: su un dialup server con molti tunnel inattivi si sceglie on-demand, che sonda solo quando ci sono pacchetti in uscita senza risposta.

Le proposte: cosa deve combaciare

Una proposta è una coppia cifratura-autenticazione, accompagnata dai gruppi Diffie-Hellman. La regola è doppia: almeno una proposta deve essere in comune fra i peer, e almeno un gruppo DH deve coincidere. Se non coincide nessun gruppo la negoziazione fallisce anche con cifratura identica: è una causa frequente di tunnel che non si alza fra vendor diversi.

Tre algoritmi esistono solo in IKEv2: aes128gcm, aes256gcm e chacha20poly1305. Sono AEAD, portano cioè l’autenticazione dentro la cifratura, ma in IKEv2 serve comunque una PRF dichiarata. L’autenticazione del peer è a scelta fra chiave precondivisa e certificato: la PSK vuole formalmente sei caratteri stampabili, ma per una protezione reale ne servono almeno 16 casuali (il tetto è 128), e da sola permette di chiedere al peer al massimo un peer ID, non un certificato client.

Fase 2: le SA IPsec e i quick mode selector

La fase 2 negozia le SA che proteggono davvero il traffico, e introduce parametri che in fase 1 non esistono: la Perfect Forward Secrecy, che impone un nuovo scambio Diffie-Hellman a ogni scadenza della chiave; la replay detection, che scarta i pacchetti cifrati fuori sequenza; e una keylife in secondi, in kilobyte o in entrambi, nel qual caso vince la condizione che scatta per prima.

I quick mode selector, cioè Local Address e Remote Address, definiscono quali indirizzi possono negoziare la SA. Il default è il più largo possibile, 0.0.0.0/0 da entrambi i lati, e va ristretto quando il peer è di terze parti e usa selettori specifici. Sono un livello di difesa distinto: i selettori dicono chi può negoziare la SA, le policy chi può passare nel tunnel.

Route-based e policy-based: l’interfaccia di tunnel

In modalità route-based la fase 1 crea un’interfaccia IPsec virtuale sull’interfaccia fisica verso il peer. Da lì il tunnel è un’interfaccia qualsiasi: ci si punta con rotte e si scrivono normali policy ACCEPT, una per direzione, con l’interfaccia IPsec come destinazione in uscita e sorgente in entrata. È la modalità da preferire, ed è quella che permette di usare i tunnel come membri SD-WAN. La policy-based usa invece una policy con action IPsec, che può coprire entrambe le direzioni con una regola sola e va posizionata sopra le ACCEPT e le DENY.

Due avvertenze. Il tipo di interfaccia della fase 1 non si cambia dopo la creazione, per via del tun_id con cui le rotte sono legate al tunnel: serve una nuova interfaccia. E quando un tunnel route-based cade la sua rotta sparisce, il traffico ricade sulla default route e finisce in chiaro sulla WAN: la blackhole route serve a farlo cadere invece di instradarlo male, ed è per questo che il wizard IPsec ne crea una.

Leggere lo stato di un tunnel

diagnose vpn ike gateway list
diagnose vpn tunnel list

Il primo è la fase 1: direction (initiator o responder), status established con il tempo trascorso, la proposal davvero negoziata, lifetime e rekey, i contatori DPD. Se qui non compare established, la fase 2 non serve guardarla.

Il secondo è la fase 2: per ogni proxyid trovi src e dst, cioè i selettori realmente installati, i contatori rxp/txp e rxb/txb, e gli SPI in decifratura e cifratura. Contatori fermi in una sola direzione con la fase 2 attiva indicano un problema di policy o di routing, non di negoziazione. Lo stesso quadro sta nel widget IPsec del dashboard Network, da cui si forzano anche bring up e bring down.