Il wizard IPsec non è la scorciatoia per chi non sa configurare a mano: è un generatore di configurazione, e all’esame la domanda è quasi sempre «dato questo estratto, cosa succede», non «quale pulsante premi». Una phase 1 che contiene set wizard-type static-fortigate è la firma inconfondibile di un tunnel nato dal wizard, e da quella riga devi saper ricostruire tutto il resto: due oggetti indirizzo, due gruppi, due rotte statiche e due policy scritte senza chiedertelo.

Le domande del wizard e cosa decidono

Da VPN > VPN Wizard scegli un template — site-to-site, hub-and-spoke o remote access — e le domande arrivano in tre blocchi: sito remoto, tunnel, sito locale.

Nel blocco del sito remoto dichiari che dall’altra parte c’è un FortiGate e come lo raggiungi. «Accessible and static» significa peer con indirizzo pubblico fisso, ed è il caso che produce una phase 1 con remote-gw valorizzato. Le subnet remote che indichi qui non sono un dettaglio cosmetico: finiscono nei selettori di quick mode e nelle rotte.

Nel blocco del tunnel scegli autenticazione e versione IKE. Con FortiGate su entrambi i lati scegli IKEv2: sparisce la scelta fra main e aggressive mode, XAuth non è disponibile, in compenso puoi usare EAP e gli algoritmi AEAD (AES-GCM, ChaCha20-Poly1305) che con IKEv1 non esistono. Il NAT traversal incapsula ESP dentro UDP perché il dispositivo NAT in mezzo possa demultiplexare le sessioni: le due estremità devono avere la stessa impostazione, entrambe abilitate o entrambe disabilitate, e il keepalive (10 secondi nell’esempio della documentazione) deve essere più corto della vita di sessione del NAT.

Nel blocco del sito locale scegli l’interfaccia di uscita — che diventa il binding della phase 1 — e l’interfaccia interna, da cui le subnet locali si popolano da sole. Lascia spento «allow remote site’s internet traffic through this device» se non stai davvero facendo uscire in internet il sito remoto attraverso questo FortiGate.

Gli oggetti che il wizard scrive per te

Questo è l’estratto che devi saper leggere, ridotto all’osso:

config vpn ipsec phase1-interface
    edit "HQ2B2"
        set interface "port1"
        set ike-version 2
        set peertype any
        set net-device disable
        set wizard-type static-fortigate
        set remote-gw 10.100.68.5
        set psksecret ENC <chiave>
    next
end
config vpn ipsec phase2-interface
    edit "HQ2B2"
        set phase1name "HQ2B2"
        set src-addr-type name
        set dst-addr-type name
        set src-name "HQ2B2_local"
        set dst-name "HQ2B2_remote"
    next
end
config router static
    edit 14
        set device "HQ2B2"
        set dstaddr "HQ2B2_remote"
    next
    edit 16
        set distance 254
        set blackhole enable
        set dstaddr "HQ2B2_remote"
    next
end

Tre cose meritano attenzione. Primo: gli oggetti indirizzo generati hanno allow-routing enable, indispensabile per usarli come destinazione «named address» di una rotta statica, e sono raccolti in due address group. Secondo: i selettori di phase 2 sono ancorati a quei gruppi (src-addr-type name), non a subnet scritte a mano. È la trappola più frequente del wizard — quando in seguito aggiungi una LAN al sito, devi aggiungerla al gruppo, non solo alla policy: altrimenti il firewall lascia passare il traffico e il selettore lo rifiuta. Terzo: la rotta blackhole a distance 254 non è decorativa. Quando il tunnel cade la sua rotta sparisce dalla tabella e il traffico verso la LAN remota cadrebbe sulla default route, uscendo in chiaro dalla WAN o entrando nel tunnel sbagliato; la blackhole lo scarta e basta. La documentazione lo dice esplicitamente: le rotte blackhole vengono create proprio quando configuri una VPN IPsec col wizard.

Infine le due policy. Un tunnel route-based vuole una accept policy per direzione, con NAT disabilitato: l’interfaccia IPsec è destinazione nella policy in uscita e sorgente in quella in entrata.

Quando il wizard non basta più

Il vincolo da ricordare a memoria: il tipo di interfaccia della phase 1 non si cambia dopo la creazione, perché il tun_id serve ad associare le rotte ai tunnel. Se hai scelto il template sbagliato non converti nulla, crei una nuova interfaccia.

Il nome della phase 1 è al massimo 15 caratteri in interface mode (35 in policy-based) e diventa il nome dell’interfaccia virtuale: la convenzione di naming si decide prima, non dopo. E se il peer non è un FortiGate, parti dal tunnel custom: la documentazione avverte che i gruppi di indirizzi usati come selettori possono non essere supportati da un endpoint remoto di terze parti, che di solito pretende selettori espliciti.

Verificare, non sperare

In GUI il posto giusto è Dashboard > Network, widget IPsec, «Expand to Full Screen»: da lì fai Bring Up, Bring Down e Reset Statistics su una phase 2. In CLI:

diagnose vpn ike gateway list name HQ2B2

Cerca status: established, il campo direction (è normale che un lato si veda initiator e l’altro responder), proposal per sapere cosa è stato realmente negoziato — non cosa avevi configurato — e DPD sent/recv. Poi manda traffico vero e guarda i contatori: un tunnel «up» senza pacchetti decifrati non è un tunnel che funziona, è un tunnel che ha finito di negoziare.