L’autenticazione dei peer avviene nella fase 1 di IKE, e le strade sono due: certificati o pre-shared secret. La guida R82 dichiara la preferenza senza giri di parole — una VPN con PKI e certificati è più sicura di una con segreti condivisi — ma il pre-shared secret resta la scelta pratica verso un apparato che non condivide la stessa PKI.

Con i certificati il punto è quale CA firma che cosa. Ogni Security Management Server ha la sua Internal Certificate Authority (ICA), che rilascia i certificati ai gateway che gestisce: due gateway sotto lo stesso Management Server condividono la stessa ICA e si fidano senza altro lavoro. Sotto Management Server diversi le ICA sono due, e ciascun lato va messo in condizione di fidarsi della CA dell’altro, oppure serve una CA esterna comune.

Il peer va rappresentato con un oggetto: un apparato non Check Point come Interoperable Device, un gateway Check Point gestito altrove come Externally Managed VPN Gateway. In entrambi i casi indirizzo del peer e VPN domain si dichiarano a mano: non si rilevano automaticamente.

Il pre-shared secret non si configura sull’oggetto del peer ma sulla community: nella pagina Shared Secret si seleziona Use only Shared Secret for all external members e si inserisce il segreto per ciascun membro esterno. R82 aggiunge qui una casella da riconoscere: Quantum Safe Key Exchange, nella scheda Encryption dell’oggetto community. Attiva le estensioni IKEv2 che ammettono scambi multipli, inclusi algoritmi post-quantum come Kyber e ML-KEM; richiede gateway R82 e peer che la supportino, e non è supportata in Traditional Mode.

Link Selection stabilisce quale interfaccia e quale indirizzo IP portano il traffico VPN, in entrata e in uscita. In R82 i meccanismi sono due: Enhanced Link Selection, novità della release, e Legacy Link Selection, quello di sempre, rinominato per distinguerli.

Nel Legacy si configurano tre cose distinte. IP Selection by Remote Peer dice con quale indirizzo il peer deve raggiungere il gateway: «Always use this IP Address», con le varianti «Main address», «Selected address from topology table» e «Statically NATed IP», oppure «Calculate IP based on network topology», «Using DNS resolving» per gli indirizzi dinamici, o «Using probing» con modalità di ridondanza High Availability o Load Sharing. Outgoing Route Selection decide l’uscita: «Operating system routing table», che segue la metrica più bassa, oppure «Route based probing», che prima verifica il percorso. Resta il Source IP address setting, automatico o manuale.

Enhanced Link Selection permette invece di configurare più interfacce esterne per la VPN, con ridondanza e Load Sharing, senza il protocollo proprietario RDP: nasce per l’interoperabilità con terze parti e cloud. Si configura nell’oggetto community, per gateway o per community, indicando per ogni link interfaccia esterna, next hop, indirizzo NAT e modalità di ridondanza; lo stato si monitora con DPD. Le esclusioni contano quanto la funzione: non vale con DAIP, Spark, Large Scale VPN, Remote Access VPN, ElasticXL e interfacce con più indirizzi IPv6, e si ricade sul Legacy quando un gateway usa solo IPv4 o solo IPv6.

ISP Redundancy: quando il collegamento cade

ISP Redundancy tiene in piedi la connettività quando un collegamento verso un ISP viene meno, e può farlo anche per la VPN. Si configura in Other > ISP Redundancy dell’oggetto gateway, spuntando Apply settings to VPN traffic; in IPsec VPN > Link Selection va attivato Use ongoing probing, e la modalità rispecchia quella di ISP Redundancy: High Availability con primario e backup, oppure Load Sharing.

La frase da ricordare è una sola, ed è quella che le domande amano rigirare: ISP Redundancy prevale su Link Selection. Quando è attiva per la VPN, il probing interroga solo i link dichiarati in ISP Redundancy, non tutti quelli disponibili.

Con un peer non Check Point la guida avverte che può non riconoscere il traffico dal link secondario, o continuare a cifrare verso un link caduto: la mitigazione è spegnere Probing e Load Sharing e affidarsi alle metriche di routing.

Trappole tipiche d’esame

  • Algoritmi e metodo di autenticazione che non coincidono. Primo errore dichiarato dal vendore, e vale anche per l’autenticazione: un lato su certificati e l’altro su pre-shared secret non chiude la fase 1, e due ICA diverse fanno fallire il tunnel anche con algoritmi identici. Stessa famiglia: Quantum Safe Key Exchange verso un peer che non la supporta, o su una community in Traditional Mode.
  • VPN domain definiti male. Secondo errore dichiarato, in una forma precisa: l’indirizzo esterno con cui il gateway si presenta — «Statically NATed IP», o quello di un link secondario — deve comparire nell’encryption domain del peer. Con un apparato di terze parti la guida chiede proprio di includervi l’indirizzo dell’interfaccia esterna Check Point.
  • Esenzioni NAT mancanti. Terzo errore dichiarato, e la confusione è fra due NAT diversi: «Statically NATed IP» riguarda come il peer ti raggiunge, non esenta il traffico interno dalla traduzione. L’esenzione del traffico VPN dal NAT resta un’impostazione a parte.
  • ISP Redundancy che scavalca Link Selection. La domanda racconta una Link Selection configurata con cura che «non viene rispettata». Se Apply settings to VPN traffic è attivo, ISP Redundancy vince.
  • Enhanced Link Selection dato per disponibile. DAIP, Spark, Large Scale VPN, Remote Access VPN ed ElasticXL sono fuori: lì la risposta è il Legacy.