Debug VPN sur Check Point / Les domaines d'encryption

Dans le cadre d'un debug de tunnel VPN, un des éléments sur lequel doit porter votre attention est le domaine d'encryption.

En fait, il y en a deux: un local et un distant. Et ces paramètres sont à configurer de part et d'autre du tunnel VPN.

Le domaine d'encryption correspond tout simplement aux plages IP qui seront amenées à transiter au travers de ce tunnel.

Prenons le cas d'un VPN reliant les plages IP 10.0.0.0/24 côté client et 192.168.0.0/16 côté prestataire de service.

Du côté client, le domaine d'encryption local est 10.0.0.0/24, le distant est 192.168.0.0/16 ... et c'est l'inverse côté prestataire.

Maintenant, le comportement de Check Point va différer en fonction de:

 . Domaines d'encryptions erronées

 . Domaine d'encryption local intégrant la plage IP locale ET distante (c'est un cas particulier et, et oui, çà m'est arrivé... :) )

 . Sens de communication des requêtes

Dans le premier cas, vous allez devoir utiliser le mode de débogage VPN ainsi que l'outil (magique ?) IKE Viewer (cf. précédent POST).

Dans les deux derniers cas, il faut comprendre le fonctionnement du firewall pour interpréter les erreurs présentes dans les logs du SmartView Tracker.

Le firewall voit arriver la requête. Les règles sont dépilées jusqu'à celle qui nous concerne. Or la plage IP cible de cette requête est intégrée au domaine d'encryption local => le firewall n'a aucune raison de faire emprunter le tunnel VPN à cette requête (pourtant conformes aux règles de sécurité établies).

Vous verrez donc la requête refusée (très certainement par la dernière règle) et vous vous tirerez les cheveux quelque temps...

Deux raisons pour lesquelles pareille situation peut vous arriver:

 . la plage IP distante fait partie intégrante d'un LAN plus large et déjà présent dans ce domaine d'encryption local.

 . vous deviez initialement translater, en source, les requêtes à destination de ce tunnel. Vous aviez donc placé ce LAN dans le domaine d'encryption local du firewall. Puis, changement de programme... plus besoin de NAT... vous reprenez l'objet, lui attribuez la plage IP cible, modifiez l'objet 'Interoparable device' afin de luis attribuer ce nouveau domaine d'encryption distant... mais qui reste placé dans votre domaine d'encryption local :(

Pour le troisième cas: en fonction du sens des requêtes, Check Point et l'autre équipement d'extrémité VPN vont négocier l'établissement du tunnel VPN différemment.

Il faut savoir que Check Point va agréger les routes (cf. Agrégation des adresses) de son domaine d'encryption local.

En prenant l'exemple plus haut, côté client, le domaine d'encryption local contient également la plage IP 10.0.1.0/24 et 10.0.2.0/24 mais les requêtes ne concernent qu'un poste appartenant à 10.0.0.0/24. La passerelle VPN du client est un Check Point.
Côté prestataire, on ne change rien à propos de son domaine d'encryption local, et sa passerelle VPN est le produit d'un autre fabriquant.

Lorsqu'une requête est à l'initiative du client, le domaine d'encryption local négocié côté Check Point est la plage IP 10.0.0.0/24.

Par contre, lorsqu'une requête va être émise côté prestataire, ce domaine  d'encryption négocié sera le fruit de cette agrégation de plage IP: 10.0.0.0/22. Pour que le tunnel fonctionne correctement, il faudra donc demander au prestataire de configurer son domaine d'encryption distant avec cette dernière plage IP.