Due FortiGate, due ISP per parte, un requisito: la VPN non deve cadere quando cade un ISP. La parte che si sbaglia non è la configurazione dei tunnel, che è meccanica, ma il routing e il rilevamento del guasto. Farli commutare in tempi utili, senza che il traffico esca in chiaro dalla WAN, vuol dire decidere tre cose: quale percorso è preferito, come si accorge il FortiGate che il preferito è morto, e cosa succede al traffico nel frattempo.

Totale, parziale, e perché deve essere route-based

Ridondanza totale: entrambe le sedi hanno due link WAN, quindi hai almeno due tunnel indipendenti. Ridondanza parziale: solo una sede ha due uscite, l’altra ne ha una sola, e i due tunnel partono da interfacce locali diverse ma puntano allo stesso indirizzo remoto.

In entrambi i casi si lavora route-based: la documentazione elenca la VPN ridondante fra le topologie supportate «using route-based approaches». Il motivo è strutturale. In interface mode ogni phase 1 crea un’interfaccia virtuale, e su un’interfaccia si ragiona con rotte, distance, priority e monitor; un tunnel policy-based non è un’interfaccia e non offre al routing nulla su cui decidere.

Una phase 1 per percorso, vincolata alla propria interfaccia di uscita e al proprio gateway remoto:

config vpn ipsec phase1-interface
    edit "toB-isp1"
        set interface "port1"
        set ike-version 2
        set remote-gw 203.0.113.10
        set dpd on-idle
        set dpd-retryinterval 15
        set dpd-retrycount 3
    next
    edit "toB-isp2"
        set interface "port2"
        set ike-version 2
        set remote-gw 198.51.100.10
        set dpd on-idle
    next
end

Tieni identici i selettori di phase 2 sui due tunnel. È l’errore silenzioso classico: il failover riesce a livello IKE, la phase 1 sale sul backup, e la phase 2 non trova un selettore che combaci perché su un tunnel c’era 0.0.0.0/0 e sull’altro le subnet esplicite.

Chi vince: distance, priority, ECMP

Il traffico sceglie il tunnel guardando la tabella di routing: la ridondanza si progetta lì.

config router static
    edit 10
        set device "toB-isp1"
        set dstaddr "SiteB-LAN"
        set distance 10
    next
    edit 11
        set device "toB-isp2"
        set dstaddr "SiteB-LAN"
        set distance 20
    next
    edit 12
        set dstaddr "SiteB-LAN"
        set blackhole enable
        set distance 254
    next
end

Tre meccanismi da tenere separati in testa:

  • Distance decide chi entra nella tabella di routing. Distance diverse significa attivo/passivo: solo la rotta migliore è installata, la seconda entra quando la prima sparisce.
  • Priority decide chi è preferito fra rotte già installate, a parità di distance: stanno in tabella entrambe, vince il valore di priority più basso.
  • Distance e priority uguali significa ECMP: il traffico è distribuito fra i due tunnel, per default in base al source IP.

Attivo/passivo con distance diverse è la scelta giusta quando i link non sono equivalenti, tipo fibra più LTE. ECMP su due tunnel è attraente ma va valutato: sessioni diverse prendono percorsi diversi, e se dall’altra parte policy, NAT o rotte di ritorno non sono simmetriche ottieni traffico che funziona a metà.

La rotta blackhole con distance alta non è opzionale: senza, quando entrambi i tunnel cadono il traffico verso la LAN remota scivola sulla default route ed esce in chiaro dalla WAN. Ricorda che l’oggetto usato come destinazione deve avere allow-routing enable.

Far accorgere il FortiGate del guasto

Una rotta legata a un’interfaccia tunnel sparisce dalla tabella quando il tunnel scende. Il punto è quando il FortiGate decide che è sceso.

Dead peer detection è il primo strumento: on-idle sonda quando il tunnel è inattivo, on-demand invia i probe solo quando esce traffico senza che rientri risposta, per non sovraccaricare un dialup server. Di default DPD sonda ogni cinque secondi; dpd-retryinterval e dpd-retrycount decidono in quanto tempo il peer è dichiarato morto. Intervalli lunghi significano failover più lento.

Il secondo strumento è il tunnel monitor: sul secondario dichiari quale primario sorvegliare.

config vpn ipsec phase1-interface
    edit "toB-isp2"
        set monitor "toB-isp1"
    next
end

Il secondario resta giù finché il primario è su e sale quando il primario cade: è pulito, ma paghi la negoziazione completa al momento del guasto. L’approccio opposto è auto-negotiate sulla phase 2, che rinegozia la SA da sola ogni cinque secondi finché non si stabilisce, invece di aspettare il pacchetto di innesco che verrebbe scartato. Su un backup che vuoi già caldo è la scelta giusta, ma non combinarlo con monitor, che quel tunnel lo vuole giù.

La trappola vera: un tunnel può essere «su» e non trasportare niente — peer che risponde a IKE ma non instrada, MTU, ESP filtrato a valle. Il routing non fallisce, perché l’interfaccia risulta attiva. Serve un controllo end-to-end: un link health monitor con update-static-route, oppure i tunnel dentro SD-WAN pilotati da una performance SLA — la documentazione presenta le rotte con distance diverse come soluzione legacy e SD-WAN come la strada normale per il dual-WAN.

Simmetria, o non è ridondanza

Ogni tunnel è un’interfaccia, quindi vuole la sua coppia di policy accept, una per direzione, con NAT disabilitato. Se le duplichi solo per il primario, al failover avrai una tabella di routing perfetta e traffico bloccato dal firewall. Lo stesso vale per le rotte di ritorno sull’altro FortiGate: se là esiste solo la rotta verso il primario, il ritorno non segue l’andata e la verifica di reverse path fa il resto.

La ridondanza si prova staccando davvero il link primario, con un ping continuo e get router info routing-table all sotto gli occhi.